Server clusters

A server cluster is a group of independent computer systems, known as nodes, running Windows 2000 Advanced Server and working together as a single system to ensure that mission-critical applications and resources remain available to clients. Every node is attached to one or more cluster storage devices. Server clusters enable users and administrators to access and manage the nodes as a single system rather than as separate computers.

  • Before creating a server cluster, see Checklists: Creating server clusters.
  • Before installing resources for a server cluster, see Checklists: Installing server cluster resources.
  • For tips about using server clusters, see Best practices.
  • For help with specific tasks, see How to.
  • For general background information, see Concepts.
  • For problem-solving instructions, see Troubleshooting.


Checklists: Creating server clusters

  • Checklist: Creating a server cluster
  • Checklist: Creating a server cluster virtual server
  • Checklist: Creating a server cluster file server
  • Checklist: Creating a server cluster print server
  • Checklist: Creating a server cluster Web server
  • Checklist: Creating a server cluster application server
  • Checklist: Validating your system for clustering
  • Checklist: Creating a new group
  • Checklist: Creating a new resource


Checklist: Creating a server cluster

Caution

  • You must carry out your installation one server at a time. Make sure that Windows 2000 Advanced Server and the Cluster service are installed and running on one server before starting the operating system on a second server in the cluster. If you start the operating system on all servers before the Cluster service is running on one server, the cluster disks can be corrupted.

Follow these steps to create a server cluster. You can use the tutorial for Cluster Service Installation at the Microsoft Web site (http://www.microsoft.com/) to help you create a server cluster.

Step | Reference

Important

    You must review important hardware and network details before creating your server cluster to prevent corruption of the cluster disks and to successfully install the Cluster service. Review information on cluster hardware, cluster disks, network adapters, IP addressing, and cluster accounts.
Planning and preparing for cluster installation
Review basic cluster concepts. You will need to understand about nodes, failover and failback, groups, and resources before planning your server cluster.

Concepts

Server clusters overview
Review limitations of server clusters. | Limitations of server clusters
Choose your cluster model. | Choosing a cluster model
Choose applications that can run on your server cluster. | Choosing applications to run on a server cluster
Organize your cluster applications and resources into groups based on resource dependencies, failover policies, and administrative convenience. | Planning your groups
After you choose a cluster model and determine how to group your applications and resources, you are ready to determine the hardware capacity required for each server in the cluster. | Determining server-capacity requirements

Choose your cluster hardware.

Microsoft supports only complete systems chosen from the Hardware Compatibility List (HCL); you cannot mix and match hardware components when building your cluster. Check that your hardware, including your cluster disks, is compatible with Windows 2000 Advanced Server.

 Windows 2000 Hardware Compatibility List at the Microsoft Web site.(http://www.microsoft.com/) Search for "Cluster."

Prepare to install and configure the Cluster service. You will need a static IP address for the cluster, IP addresses for each network adapter on each node, computer accounts for the cluster nodes, and a user account for the Cluster service.

You will also need a name for the cluster. This is the name administrators will use for connections to the cluster. (The actual applications running on the cluster will typically have different network names.) The cluster name must be different from the domain name, from all computer names on the domain, and from other cluster names on the domain.

Domain accounts and the Cluster service

The Cluster service and TCP/IP

Using additional TCP/IP services

Configure redundant network hardware.

The nodes of a cluster must be connected by one or more physically independent networks. Two networks are strongly recommended to eliminate a single point of failure.

Each cluster node should have two or more network adapters to prevent a single point of failure.

Note

  • You should set the network adapter's Media Type to the actual speed of the card. If the card's Media Type is set to Auto Select, the card will allow some frames to be lost. The Advanced tab of the network adapter's Property Page displays the Media Type.

Network configuration in a server cluster

To change network adapter settings

Install and configure your cluster disks.

Follow the manufacturer's instructions for terminating the SCSI bus and setting a unique SCSI ID for each device on the shared bus. Configure cluster disks as basic disks and format the disks using the NTFS file system. Assign drive letters to the cluster disks on the shared bus. The disks must have the same drive letter on all nodes in the cluster.

Set aside a small partition on your cluster disks for the quorum resource. The partition will need to have at least 5 MB of free space (500 MB recommended). It is recommended that you use a different partition for the quorum resource than you use for user data.

Caution

  • Once the shared bus has been connected to all computers, do not run Windows 2000 Advanced Server on all computers at the same time until the Cluster service has been installed on at least one computer.

Terminating a shared SCSI bus

General drive configuration tips for server clusters

Beginning the installation of the cluster disks

Install the Cluster service on one node at a time.

Install the Cluster service components using Add/Remove Programs. The Welcome to the Cluster Service Configuration wizard is launched to configure the Cluster service.

You can use the tutorial for Cluster Service Installation to help you complete the Cluster Service Configuration wizard.

 To install the Cluster service using Add/Remove Programs

Microsoft Web site (http://www.microsoft.com/)

Validate your system for clustering.

 Checklist: Validating your system for clustering


Checklist: Creating a server cluster virtual server

Step | Reference
Review the concepts behind virtual servers. | Virtual servers
Use the Cluster Application Configuration wizard to create your virtual server. | To start the Cluster Application wizard
Configure resource dependencies in your virtual server. | Setting resource dependencies


Checklist: Creating a server cluster file server

Step | Reference
Review server cluster components. | Server cluster components
Review cluster resources. | Server cluster resources
Review documentation on the File Share resource type. | File Share resource type
Plan your resource groups. | Planning your groups
Determine how to use the cluster file share resource. | Using a server cluster with large numbers of file shares
Install the Cluster service. | Checklist: Creating a server cluster
Create a virtual server for your file server. | Checklist: Creating a server cluster virtual server


Checklist: Creating a server cluster print server

Step | Reference
Review server cluster components. | Server cluster components
Review cluster resources. | Server cluster resources
Review documentation for the Print Spooler resource type. | Print Spooler resource type
Plan your resource groups. | Planning your groups
Install the Cluster service. | To install the Cluster service using Add/Remove Programs
Create a virtual server for your print server. | Checklist: Creating a server cluster virtual server


Checklist: Creating a server cluster Web server

You should review the information on Network Load Balancing clusters before using a server cluster to create a high-availability Web server. Depending on your needs, a Network Load Balancing cluster might be a better solution. For more information on Network Load Balancing clusters, see Network Load Balancing clusters.

For the most current information on server clusters and how they work with Network Load Balancing, see Updated technical information.

Step | Reference
Review server cluster components. | Server cluster components
Review cluster resources. | Server cluster resources
Plan your resource groups. | Planning your groups
Install the Cluster service. | To install the Cluster service using Add/Remove Programs
Create a virtual server for your Web server. | Checklist: Creating a server cluster virtual server


Checklist: Creating a server cluster application server

Step | Reference
Review server cluster components. | Server cluster components
Review cluster resources. | Server cluster resources
Review the requirements for your application. | Your application documentation Checklist: Installing a Generic Application
Plan your resource groups. | Planning your groups
Install the Cluster service. | To install the Cluster service using Add/Remove Programs
Create a virtual server for your application. | Checklist: Creating a server cluster virtual server


Checklist: Validating your system for clustering

Step | Reference
Ping the local loop-back address (127.0.0.1). | Using the ping command
Ping the IP address of each network adapter on each node. | Using the ping command
Ping each node by computer name. | Using the ping command
Verify that the remote procedure call (RPC) service is running. | To start, stop, pause, resume, or restart a service
With one node powered on, verify that the disks on the cluster storage appear in Disk Management. | To display disks and volumes in graphical or list view
Powering on one node at a time, verify that all nodes see the same number of disks on the cluster storage. | To display disks and volumes in graphical or list view
If you use SCSI, verify that each SCSI controller on each node has a different SCSI ID. | The documentation for your SCSI controller
Verify that the cluster disks are formatted using NTFS. | Best practices


Checklist: Creating a new group

Step | Reference
Review resource groups. | Groups
Determine the name you will assign to the group. |
Determine the text description for the group (optional). |
Determine the preferred owner for the group (optional). | Model A: High-availability solution with static load balancing To set group failback policy
Use the New Group wizard to create the group. | To create a new group


Checklist: Creating a new resource

Step | Reference
Review the concepts behind cluster resources. | Server cluster resources
Review resource groups and resource dependencies. | Groups
Determine the name of your resource. |
Determine the type of your resource. | Resource types
Determine the group to which your resource will belong. | Groups
Determine if the resource will run in a separate resource monitor. | Resource Monitors
List the possible owners of the resource. | Failover and failback
Determine the resource dependencies. | Resource dependencies
List parameters specific to your resource. | Checklists: Installing server cluster resources
Use the New Resource wizard to create the resource. | To create a new resource


Checklists: Installing server cluster resources

  • Checklist: Installing a DHCP Service resource
  • Checklist: Installing a Distributed Transaction Coordinator resource
  • Checklist: Installing a File Share resource
  • Checklist: Installing a Generic Application resource
  • Checklist: Installing a Generic Service resource
  • Checklist: Installing an IIS Server Instance resource
  • Checklist: Installing an IP Address resource
  • Checklist: Installing a Message Queuing resource
  • Checklist: Installing a Network Name resource
  • Checklist: Installing a Physical Disk resource
  • Checklist: Installing a Print Spooler resource
  • Checklist: Installing a WINS Service resource


Checklist: Installing a DHCP Service resource

Step | Reference
Review the concepts behind cluster resources. | Server cluster resources
Review resource groups and resource dependencies. | Groups
Review the concepts behind Dynamic Host Configuration Protocol (DHCP). | DHCP
Plan common resource settings. | Checklist: Creating a new resource
Configure location of DHCP database and backup of database files. | DHCP and WINS resource types
Use the New Resource wizard to create the resource. | To create a new resource


Checklist: Installing a Distributed Transaction Coordinator resource

Step | Reference
Review the concepts behind cluster resources. | Server cluster resources
Review resource groups and resource dependencies. | Groups
Plan common resource settings. | Checklist: Creating a new resource
Use the New Resource wizard to create the resource. | To create a new resource


Checklist: Installing a File Share resource

Step | Reference
Review the concepts behind cluster resources. | Server cluster resources
Review resource groups and resource dependencies. | Groups
Review the behavior of the file share resource type. | File Share resource type
Plan common resource settings. | Checklist: Creating a new resource
Determine if you will use the advanced properties of the File Share resource type. | File Share resource type
Use the New Resource wizard to create the resource. | To create a new resource


Checklist: Installing a Generic Application resource

Step | Reference
Review the concepts behind cluster resources. | Server cluster resources
Review resource groups and resource dependencies. | Groups
Plan common resource settings. | Checklist: Creating a new resource
Install your application on all nodes. | Generic Application resource type
Note the command line for your application. | The documentation for your application.
Determine the directory in which your application should run. | The documentation for your application.
Determine if your application can display windows on the node on which it runs. | The documentation for your application.
Use the New Resource wizard to create the resource. | To create a new resource


Checklist: Installing a Generic Service resource

Step | Reference
Review the concepts behind cluster resources. | Server cluster resources
Review resource groups and resource dependencies. | Groups
Plan common resource settings. | Checklist: Creating a new resource
Note the exact service name. | The documentation for your service.
Note the startup parameters of your service. | The documentation for your service.
Ensure that the service is installed on all nodes. |
Use the New Resource wizard to create the resource. | To create a new resource


Checklist: Installing an IIS Server Instance resource

Step | Reference
Review the concepts behind cluster resources. | Server cluster resources
Review resource groups and resource dependencies. | Groups
Review IIS concepts. | Internet Information Services
Plan common resource settings. | Checklist: Creating a new resource
Note the type of Internet service you will provide: FTP or WWW. | Setting resource properties
Decide the IIS Server that the cluster will manage. | Setting resource properties


Checklist: Installing an IP Address resource

Step | Reference
Review the concepts behind cluster resources. | Server cluster resources
Review resource groups and resource dependencies. | Groups
Review TCP/IP concepts. | Concepts
Plan common resource settings. | Checklist: Creating a new resource
Use the New Resource wizard to create the resource. | To create a new resource


Checklist: Installing a Message Queuing resource

Step | Reference
Review the concepts behind cluster resources. | Server cluster resources
Review resource groups and resource dependencies. | Groups
Review Message Queuing concepts. | Message Queuing
Plan common resource settings. | Checklist: Creating a new resource
Use the New Resource wizard to create the resource. | To create a new resource


Checklist: Installing a Network Name resource

Step | Reference
Review the concepts behind cluster resources. | Server cluster resources
Review resource groups and resource dependencies. | Groups
Review networking concepts. | Networking
Plan common resource settings. | Checklist: Creating a new resource
Note the name you want to publish on the network. |
Use the New Resource wizard to create the resource. | To create a new resource


Checklist: Installing a Physical Disk resource

Step | Reference
Review the concepts behind cluster resources. | Server cluster resources
Review resource groups and resource dependencies. | Groups
Review disk storage concepts. | Disk Management
Plan common resource settings. | Checklist: Creating a new resource
Use the New Resource wizard to create the resource. | To create a new resource


Checklist: Installing a Print Spooler resource

Step | Reference
Review the concepts behind cluster resources. | Server cluster resources
Review resource groups and resource dependencies. | Groups
Review network printing concepts. | Printing
Review print spooler resource type information. | Print Spooler resource type
Plan common resource settings. | Checklist: Creating a new resource
Use the New Resource wizard to create the resource. | To create a new resource


Checklist: Installing a WINS Service resource

Step | Reference
Review the concepts behind cluster resources. | Server cluster resources
Review resource groups and resource dependencies. | Groups
Review WINS concepts. | WINS
Plan common resource settings. | Checklist: Creating a new resource
Configure location of WINS database and backup of database files. | DHCP and WINS resource types
Use the New Resource wizard to create the resource. | To create a new resource


Best practices

The following guidelines will help you effectively use a server cluster:

  • Enabling auditing on all cluster nodes

    If you want to audit access to shared data, enable auditing on all cluster nodes. For more information on cluster security, see Securing shared data in a cluster.

  • Using two interconnects

    Although a server cluster can function with only one interconnect, two interconnects are strongly recommended to eliminate a single point of failure and are required for the verification of original equipment manufacturer (OEM) clusters.

  • Checking Windows 2000 Hardware Compatibility List

    Microsoft supports only complete systems chosen from the Windows 2000 Hardware Compatibility List at the Microsoft Web site.(http://www.microsoft.com/) Search for "Cluster." Check that your hardware, including your cluster disks, is compatible with Windows 2000 Advanced Server. It is recommended that your cluster configuration consist of identical hardware on all cluster nodes to simplify configuration and eliminate potential compatibility problems.

  • Partitioning and formatting disks before installing the Cluster service

    You should partition and format all disks on the cluster storage device before installing the Cluster service. You must format the disk that will be the quorum resource. All partitions on the cluster storage device must be formatted with NTFS (they can be either compressed or uncompressed), and all partitions on one disk are managed as one resource and move as a unit between nodes.

  • Maintaining a backup of RAID controller

    The cluster RAID controller is a single point of failure. You should always maintain a backup of the RAID controller configuration in case the RAID controller is replaced.


How to...

  • Perform common administrative tasks
  • Manage resources
  • Manage groups
  • Use Cluster Administrator
  • Manage nodes
  • Manage networks
  • Perform advanced administrative tasks
  • Manage cluster hardware
  • Test failover policies


Perform common administrative tasks

  • Create a cluster-managed printer
  • Share the subfolders of a folder


Create a cluster-managed printer

To create a cluster-managed printer

  1. Create a Print Spooler resource. For more information on creating a resource, see Related Topics.
  2. Bring the Print Spooler resource online. For more information on bringing a resource online, see Related Topics.
  3. On every node of the cluster, install printer drivers for your printer. For more information on adding printer drivers, see Related Topics.
  4. Install a printer port for your printer. You install the printer port on the virtual server that manages the printer instead of on an actual node. For more information on adding a port, see Related Topics.

Note

  • Not all printer ports may be used in a server cluster. LprMon and Standard TCP/IP Port, both provided with Windows 2000, may be used in a server cluster. Check the documentation of other printer ports to verify that they may be used in a cluster.

Related Topics


Share the subfolders of a folder

To share the subfolders of a folder

  1. Open Cluster Administrator.
  2. Create a File Share resource. For more information on creating a new resource, see Related Topics.
  3. In the the console tree (usually the left pane), double-click Groups, and then click the group that contains the File Share resource that you created in step 2.
  4. In the details pane (usually the right pane), click the File Share resource that you created. On the File menu, click Properties.
  5. Under the Parameters tab in Path, type the path to the folder for which you want to share all of its subfolders.
  6. Click Advanced, and then click Share subdirectories. If you want to prevent users from seeing the subdirectory shares when they browse the network, click Hide subdirectories shares, and then click OK.
  7. On the File menu, click Bring online.

Notes

  • To open Cluster Administrator, click Start, point to Programs, point to Administrative Tools, and then click Cluster Administrator.
  • The combo file share option permits a file share resource to share subdirectories. Subfolders of a combo file share are shared using the subfolder name. You cannot specify a name for a subfolder share. The only way to change a subfolder share name is to change the subfolder name. Changing the name of a shared subfolder will break the share. The subfolder share will be unavailable for the time specified by the File Share resource Is Alive poll interval. The subfolder will be shared again the next time the File Share resource Is Alive poll is called.

Related Topics


Manage resources

  • Specify the restart or failover policy for a resource
  • Set resource dependencies
  • Create a new resource
  • Delete a resource
  • Bring a resource online
  • Take a resource offline
  • Move a resource to another group
  • Rename a resource
  • Specify which nodes can own a resource
  • View or set resource properties
  • View or set resource type properties


Specify the restart or failover policy for a resource

To specify the restart or failover policy for a resource

  1. Open Cluster Administrator.
  2. In the console tree (usually the left pane), click the Resources folder.
  3. In the details pane (usually the right pane), click the resource you want.
  4. On the File menu, click Properties.
  5. On the Advanced tab, make the changes you want.

Note

  • To open Cluster Administrator, click Start, point to Programs, point to Administrative Tools, and then click Cluster Administrator.
  • The settings on the Advanced tab specify the restart policy for a resource.

Related Topics


Set resource dependencies

To set resource dependencies

  1. Open Cluster Administrator.
  2. In the console tree (usually the left pane), click the Resources folder.
  3. In the right pane, click the resource you want.
  4. On the File menu, click Properties.
  5. On the Dependencies tab, make the changes you want.

Note

  • To open Cluster Administrator, click Start, point to Programs, point to Administrative Tools, and then click Cluster Administrator.

Related Topics


Create a new resource

To create a new resource

  1. Open Cluster Administrator.
  2. In the console tree (usually the left pane), double-click the Groups folder.
  3. In the details pane (usually the right pane), click the group to which you want the resource to belong.
  4. On the File menu, point to New, and then click Resource.
  5. In the New Resource wizard, type appropriate information in Name and Description, and click the appropriate information in Resource type, and Group. Click Next.
  6. Add or remove possible owners of the resource, and then click Next.
  7. To add dependencies, under Available resources, click a resource, and then click Add.

    Or, to remove dependencies, under Resource dependencies, click a resource, and then click Remove.

  8. Repeat step 6 for any other resource dependencies, and then click Finish.
  9. Set resource properties. For more information on setting resource properties, see Related Topics.

Notes

  • To open Cluster Administrator, click Start, point to Programs, point to Administrative Tools, and then click Cluster Administrator.
  • Before adding a resource to your cluster, you must verify the following:
    • That the type of resource is either one of the basic types provided with Windows 2000 or a custom resource type provided by the resource manufacturer.
    • That a group already exists within the cluster to which your resource will belong.
    • That all dependent resources have been created.
  • A separate Resource Monitor is recommended for any resource that has caused problems in the past.

Related Topics


Delete a resource

To delete a resource

  1. Open Cluster Administrator.
  2. In the console tree (usually the left pane), click the Resources folder.
  3. In the details pane (usually the right pane), click the resource you want to remove.
  4. On the File menu, click Delete.

Note

  • To open Cluster Administrator, click Start, point to Programs, point to Administrative Tools, and then click Cluster Administrator.
  • When you delete a resource, Cluster Administrator also deletes all the resources that have a dependency on the deleted resource.

Related Topics


Bring a resource online

To bring a resource online

  1. Open Cluster Administrator.
  2. In the console tree (usually the left pane), click the Resources folder.
  3. In the details pane (usually the right pane), click the resource you want.
  4. On the File menu, click Bring Online.

Note

  • To open Cluster Administrator, click Start, point to Programs, point to Administrative Tools, and then click Cluster Administrator.
  • Bringing a resource online causes all resources on which the resource depends to be brought online.

Related Topics


Take a resource offline

To take a resource offline

  1. Open Cluster Administrator.
  2. In the console tree (usually the left pane), click the Resources folder.
  3. In the details pane (usually the right pane), click the resource you want.
  4. On the File menu, click Take Offline.

Note

  • To open Cluster Administrator, click Start, point to Programs, point to Administrative Tools, and then click Cluster Administrator.
  • Taking a resource offline causes all resources that depend on that resource to be taken offline.

Related Topics


Move a resource to another group

To move a resource to another group

  1. Open Cluster Administrator.
  2. In the console tree (usually the left pane), click the Resources folder.
  3. In the details pane (usually the right pane), click the resource you want to move.
  4. On the File menu, point to Change Group, and then click the name of the group to which you want to transfer ownership.

Note

  • To open Cluster Administrator, click Start, point to Programs, point to Administrative Tools, and then click Cluster Administrator.
  • When you move a resource to another group, all resources that depend on it or on which it depends are also moved.

Related Topics


Rename a resource

To rename a resource

  1. Open Cluster Administrator.
  2. In the console tree (usually the left pane), click the Resources folder.
  3. In details pane (usually the right pane), click the resource you want to rename.
  4. On the File menu, click Rename.
  5. Type a new name for the resource.

Notes

  • To open Cluster Administrator, click Start, point to Programs, point to Administrative Tools, and then click Cluster Administrator.
  • Changing the name of a resource does not affect the failover policy for that resource or the group to which it belongs.
  • The resource name must be unique.

Related Topics


Specify which nodes can own a resource

To specify which nodes can own a resource

  1. Open Cluster Administrator.
  2. In the console tree (usually the left pane), click the Resources folder.
  3. In the details pane (usually the right pane), click the appropriate resource.
  4. On the File menu, click Properties.
  5. On the General tab, next to Possible owners, click Modify.
  6. Specify which nodes you want to be possible owners.
    • To add a possible owner, under Available nodes, click a node, and then click the right arrow.
    • To remove a possible owner, under Possible owners, click a node, and then click the left arrow.

Notes

  • To open Cluster Administrator, click Start, point to Programs, point to Administrative Tools, and then click Cluster Administrator.
  • A possible owner is a node that is capable of running a resource.
  • If you want to make a group capable of failing over, it must have more than one possible owner.
  • If a resource has no possible owners, it will not come online. This can be useful if you want to keep a resource offline but you do not want to delete it and lose its configuration settings.

Related Topics


View or set resource properties

To view or set resource properties

  1. Open Cluster Administrator.
  2. In the console tree (usually the left pane), click the Resources folder.
  3. In the details pane (usually the right pane), click the appropriate resource.
  4. On the File menu, click Properties.
  5. Click each tab and set the various properties for the resource.

Note

  • To open Cluster Administrator, click Start, point to Programs, point to Administrative Tools, and then click Cluster Administrator.

Related Topics


View or set resource type properties

To view or set resource type properties

  1. Open Cluster Administrator.
  2. In the console tree (usually the left pane), double-click the Cluster Configuration folder.
  3. In the console tree, click the Resource Types folder.
  4. In the details pane (usually the right pane), click the appropriate resource type.
  5. On the File menu, click Properties, and set the various properties for the resource.

Notes

  • To open Cluster Administrator, click Start, point to Programs, point to Administrative Tools, and then click Cluster Administrator.

Related Topics


Manage groups

  • Change the properties of a group
  • Create a new group
  • Delete a group
  • Bring a group online
  • Take a group offline
  • Move a group to another node
  • Rename a group
  • Specify preferred owners of a group
  • Set group failover policy
  • Set group failback policy


Change the properties of a group

To change the properties of a group

  1. Open Cluster Administrator.
  2. In the console tree (usually the left pane), click the Groups folder.
  3. In the details pane (usually the right pane), click the group you want.
  4. On the File menu, click Properties.
  5. Click each tab and set the various properties for the group.

Notes

  • To open Cluster Administrator, click Start, point to Programs, point to Administrative Tools, and then click Cluster Administrator.
  • The settings on the tabs give general information about the group and define how it should behave during failover.
  • Every new cluster includes at least two default groups: Cluster Group and Disk Group 1. These groups contain the settings for the default cluster and some typical resources that provide generic information and failover policies.

    You can use the default groups as templates for creating your own groups. However, do not delete or rename the Cluster Group or move the resources in it.

Related Topics


Create a new group

To create a new group

  1. Open Cluster Administrator.
  2. On the File menu, point to New, and then click Group.
  3. In the New Group wizard, in Name, type a name for the new group.
  4. In Description, type any comments you want, and then click Next.
  5. Under Available nodes, not Preferred owners, click the nodes you want to be the preferred owners for the group, and then click Add.
  6. Click Move Up and Move Down as needed to change the priority of a selected owner.
  7. Repeat steps 5 and 6 as needed to add other preferred owners, and then click Finish.

Notes

  • To open Cluster Administrator, click Start, point to Programs, point to Administrative Tools, and then click Cluster Administrator.
  • The name that you give the group is only for administrative purposes. It is not the same as a network name, which is the name that clients can use to connect to the group.
  • Cluster Administrator lists the group description in the details pane, with the group name.
  • All resources within the new group fail over together. To have the group fail back to a node, specify that node as the preferred owner. You can balance groups between two nodes to maximize the performance of the cluster. However, you can choose not to have a preferred owner if the location of the group does not greatly affect performance.

Related Topics


Delete a group

To delete a group

  1. Open Cluster Administrator.
  2. In the console tree (usually the left pane), click the Groups folder.
  3. In the details pane (usually the right pane), click the group you want to remove.
  4. On the File menu, click Delete.

Note

  • To open Cluster Administrator, click Start, point to Programs, point to Administrative Tools, and then click Cluster Administrator.
  • You must delete all of the resources in a group before you delete the group.

Related Topics


Bring a group online

To bring a group online

  1. Open Cluster Administrator.
  2. In the console tree (usually the left pane), double-click the Groups folder.
  3. In the details pane (usually the right pane), click the group you want.
  4. On the File menu, click Bring Online.

Note

  • To open Cluster Administrator, click Start, point to Programs, point to Administrative Tools, and then click Cluster Administrator.
  • Resources in a group come online in the order of their dependencies.

Related Topics


Take a group offline

To take a group offline

  1. Open Cluster Administrator.
  2. In the console tree (usually the left pane), double-click the Groups folder.
  3. In the details pane, click the group you want.
  4. On the File menu, click Take Offline.

Note

  • To open Cluster Administrator, click Start, point to Programs, point to Administrative Tools, and then click Cluster Administrator.
  • Resources in a group go offline in the order of their dependencies.

Related Topics


Move a group to another node

To move a group to another node

  1. Open Cluster Administrator.
  2. In the console tree (usually the left pane), double-click the Groups folder.
  3. In the console tree, click the group you want to move.
  4. On the File menu, click Move Group.

Note

  • To open Cluster Administrator, click Start, point to Programs, point to Administrative Tools, and then click Cluster Administrator.
  • After the transfer, the new node owns all resources in the group, as the Owner column in the details pane should reflect.

Related Topics


Rename a group

To rename a group

  1. Open Cluster Administrator.
  2. In the console tree (usually the left pane), click the Groups folder.
  3. In details pane (usually the right pane), click the group you want to rename.
  4. On the File menu, click Rename.
  5. In details pane, type a new name for the group.

Note

  • To open Cluster Administrator, click Start, point to Programs, point to Administrative Tools, and then click Cluster Administrator.
  • The group name must be unique.


Specify preferred owners of a group

To specify preferred owners of a group

  1. Open Cluster Administrator.
  2. In the console tree (usually the left pane), click the Groups folder.
  3. In the details pane (usually the right pane), click the appropriate group.
  4. On the File menu, click Properties.
  5. On the General tab, next to Preferred owners, click Modify.
  6. In the Modify Preferred Owners dialog box, enter any changes you want to make:
    • To add one or more preferred owners, under Available nodes, not Preferred owners, click the nodes you want to add, and then click the right arrow.
    • To remove a preferred owner, under Preferred owners, click the nodes you want to remove, and then click the left arrow.
    • To change the priority of a preferred owner, click the node, and then click the up or down arrow.

Notes

  • To open Cluster Administrator, click Start, point to Programs, point to Administrative Tools, and then click Cluster Administrator.
  • If more than one node is listed under Preferred owners, priority is determined by the order of the list. The group always tries to fail back to the highest-priority node that is available.
  • If no preferred owners are specified, failback does not occur.

Related Topics


Set group failover policy

To set group failover policy

  1. Open Cluster Administrator.
  2. In the console tree (usually the left pane), click the Groups folder.
  3. In the details pane (usually the right pane), click the appropriate group.
  4. On the File menu, click Properties.
  5. On the Failover tab, type values for Threshold and Period.

Note

  • To open Cluster Administrator, click Start, point to Programs, point to Administrative Tools, and then click Cluster Administrator.
  • The failover policy for a group is the maximum number of times (Threshold) that the group is allowed to fail over in the specified number of hours (Period) before it is taken completely offline. If a group fails over more often than this, the Cluster service leaves it offline.

Related Topics


Set group failback policy

To set group failback policy

  1. Open Cluster Administrator.
  2. In the console tree (usually the left pane), click the Groups folder.
  3. In the details pane (usually the right pane), click the appropriate group.
  4. On the File menu, click Properties.
  5. On the Failback tab, click Prevent failback or Allow failback.

    6. If you click Allow failback, then either click Immediately, or click Failback between and set the time interval.

Notes

  • To open Cluster Administrator, click Start, point to Programs, point to Administrative Tools, and then click Cluster Administrator.
  • To set the time interval for Failback between, enter numbers between 0 and 23 for the beginning and end of the interval. If the first number is greater than the second, the interval will end on the following day. The numbers correspond to the local time of the cluster group, as read on a 24-hour clock.
  • If no preferred owners are specified for the group, then failback does not occur.

Related Topics


Use Cluster Administrator

  • Connect to a cluster with Cluster Administrator
  • Change the quorum-resource location
  • Change the maximum quorum-log size
  • Rename a cluster
  • Start the Cluster Application wizard
  • Start Cluster Administrator in Microsoft Management Console


Connect to a cluster with Cluster Administrator

To connect to a cluster with Cluster Administrator

  1. Open Cluster Administrator.
  2. On the File menu, click Open Connection.
  3. In Cluster or server name, type the network name or IP address of either the cluster or a node in the cluster.

Notes

  • To open Cluster Administrator, click Start, point to Programs, point to Administrative Tools, and then click Cluster Administrator.
  • When you start Cluster Administrator, connections left open when you closed the previous session are restored. If no connections were left open, Cluster Administrator prompts you to type a cluster name, a node, or an IP address before it displays any information. If you do not want to open old connections, you can start Cluster Administrator from the command line with the -noreconnect option.
  • You can simultaneously connect to multiple clusters, but multiple connections can affect the performance of Cluster Administrator.
  • Use the network name or IP address of either the cluster or one of its nodes to open a connection to a cluster. If Cluster Administrator cannot find the cluster by its name, type the name of an active node in the cluster. You can also connect to the cluster by opening Cluster Administrator on a cluster node and entering a PERIOD (.) in Cluster or server name.


Change the quorum-resource location

To change the quorum-resource location

  1. Open Cluster Administrator.
  2. In the console tree (usually the left pane), click the name of the cluster.
  3. On the File menu, click Properties, and then click the Quorum tab.
  4. In Quorum resource, click the disk resource you want to use as the quorum resource for the cluster.
  5. In Partition, if the disk has more than one partition, click the partition where you want the log files kept.
  6. In Root path, type the path to the folder on the partition, for example:

    7. \MSCS\

Note

  • To open Cluster Administrator, click Start, point to Programs, point to Administrative Tools, and then click Cluster Administrator.

Related Topics


Change the maximum quorum-log size

To change the maximum quorum-log size

  1. Open Cluster Administrator.
  2. In the console tree (usually the left pane), click the cluster.
  3. On the File menu, click Properties.
  4. Click the Quorum tab.
  5. In Reset quorum log at, type the maximum size (in kilobytes) that the quorum log file can be before the cluster resets it.

Note

  • To open Cluster Administrator, click Start, point to Programs, point to Administrative Tools, and then click Cluster Administrator.
  • The cluster records unsaved changes to the cluster database in the quorum log file. When the quorum log attains the specified size, the cluster saves the database and resets the log file.

Related Topics


Rename a cluster

To rename a cluster

  1. Open Cluster Administrator.
  2. In the console tree (usually the left pane), click the cluster you want to rename.
  3. On the File menu, click Rename.
  4. Type the new name for the cluster next to its icon.

Notes

  • To open Cluster Administrator, click Start, point to Programs, point to Administrative Tools, and then click Cluster Administrator.
  • The cluster name cannot be the same as the computer name of a cluster node, and it cannot conflict with any other printer, server, cluster, or domain name in use on your network.
  • The new name does not take effect until the Cluster Name resource is taken offline and brought back online. The Cluster Name resource is found in the Resources folder.

Related Topics


Start the Cluster Application wizard

To start the Cluster Application wizard

  1. Open Cluster Administrator.
  2. On the File menu, click Configure Application.
  3. Follow the instructions in the wizard.

Note

  • To open Cluster Administrator, click Start, point to Programs, point to Administrative Tools, and then click Cluster Administrator.

Related Topics


Start Cluster Administrator in Microsoft Management Console

To start Cluster Administrator in Microsoft Management Console

  1. Open Computer Management.
  2. On the Action menu, click Connect to another computer. In Name, enter the name of a cluster or a cluster node. Click OK.
  3. In the console tree (left pane), double-click to expand Services and Applications.
  4. Right-click Cluster, and then click Manage.

Notes

  • To open Computer Management, click Start, point to Programs, point to Administrative Tools, and then click Computer Management.
  • Use Windows 2000 Administration Tools to install Cluster Administrator on Windows 2000 computers that are not cluster nodes. On cluster nodes, Cluster Administrator is installed when you install the Cluster service. For more information on installing Cluster Administrator on remote computers and on cluster hardware configuration, see Related Topics.

Related Topics


Manage nodes

  • Maintain a node without evicting it from the cluster
  • Evict a node for maintenance
  • Pause a node
  • Resume a node
  • Remove a node from the cluster
  • Stop the Cluster service
  • Start the Cluster service


Maintain a node without evicting it from the cluster

To maintain a node without evicting it from the cluster

  1. Open Cluster Administrator.
  2. In the console tree (usually the left pane), click the node requiring maintenance.
  3. On the File menu, click Pause Node.
  4. In the details pane, double-click Active Groups.
  5. In the details pane, click each group, and then on the File menu, click Move Group.

    6. All the groups on the paused node move to the other node.

  6. Perform maintenance on the paused node.
  7. In Cluster Administrator, in the console tree, click the node.
  8. On the File menu, click Resume node.

Important

  • During maintenance, if you use SCSI, do not remove the server from the shared SCSI bus unless the bus is properly terminated. For more information about disconnecting a node from the cluster for maintenance, see To evict a node for maintenance.

Note

  • To open Cluster Administrator, click Start, point to Programs, point to Administrative Tools, and then click Cluster Administrator.

Related Topics


Evict a node for maintenance

To evict a node for maintenance

  1. Open Cluster Administrator.
  2. Stop the Cluster service. For more information on how to stop the Cluster service, see Related Topics.
  3. On the File menu in Cluster Administrator, click Evict Node.
  4. Uninstall the Cluster service. For more information on how to uninstall the Cluster service, see Related Topics.
  5. If you use SCSI, make sure that the SCSI bus is terminated before removing the evicted node from the SCSI bus.
  6. Perform maintenance on the server.
  7. Reconnect the node to the shared bus and turn on the computer.
  8. Install the cluster software and join the cluster.
  9. Reconfigure the preferred owners for groups in the cluster, if necessary.

Note

  • To open Cluster Administrator, click Start, point to Programs, point to Administrative Tools, and then click Cluster Administrator.

Related Topics


Pause a node

To pause a node

  1. Open Cluster Administrator.
  2. In the console tree (usually the left pane), click the node.
  3. On the File menu, click Pause Node.

Note

  • To open Cluster Administrator, click Start, point to Programs, point to Administrative Tools, and then click Cluster Administrator.
  • When you pause a node, existing groups and resources stay online, but additional groups and resources cannot be brought online. Pausing a node is used for maintenance and testing.

Related Topics


Resume a node

To resume a node

  1. Open Cluster Administrator.
  2. In the console tree (usually the left pane), click the node.
  3. On the File menu, click Resume Node.

Note

  • To open Cluster Administrator, click Start, point to Programs, point to Administrative Tools, and then click Cluster Administrator.
Related Topics


Remove a node from the cluster

To remove a node from the cluster

  1. Open Cluster Administrator.
  2. In the console tree (usually the left pane), click the node you want to remove.
  3. On the File menu, click Stop Cluster Service.
  4. On the File menu, click Evict Node.

Note

  • To open Cluster Administrator, click Start, point to Programs, point to Administrative Tools, and then click Cluster Administrator.
  • Removing a node is used for maintenance and testing.

Related Topics


Stop the Cluster service

To stop the Cluster service

  1. Open Cluster Administrator.
  2. In the console tree (usually the left pane), click the node.
  3. On the File menu, click Stop Cluster Service.

Note

  • To open Cluster Administrator, click Start, point to Programs, point to Administrative Tools, and then click Cluster Administrator.
  • When you stop the Cluster service on a node, you prevent clients from accessing cluster resources through that node. When you stop the Cluster service on a node, all groups move to the other node (if the failover policies allow it).
Related Topics


Start the Cluster service

To start the Cluster service

  1. Open Cluster Administrator.
  2. In the console tree (usually the left pane), click the node.
  3. On the File menu, click Start Cluster Service.

Note

  • To open Cluster Administrator, click Start, point to Programs, point to Administrative Tools, and then click Cluster Administrator.


Manage networks

  • Change the name or description of a network
  • Enable a network for cluster use
  • Disable a network for cluster use
  • Change how the cluster uses a network
  • Change the description of a network interface
  • Change network priority for communication between nodes
  • Troubleshoot client-to-virtual server connectivity


Change the name or description of a network

To change the name or description of a network

  1. Open Cluster Administrator.
  2. In the console tree (usually the left pane), double-click to expand Cluster Configuration, and then click Networks.
  3. In the details pane (usually the right pane), click the network.
  4. On the File menu, click Properties.
  5. To change the name of the network, in Name, type a new name.
  6. To describe the network, in Description, type a new description.

Notes

  • To open Cluster Administrator, click Start, point to Programs, point to Administrative Tools, and then click Cluster Administrator.
  • The description provides information about the network. It appears in the details pane of Cluster Administrator when you click the Networks folder. The network description is optional.

Related Topics


Enable a network for cluster use

To enable a network for cluster use

  1. Open Cluster Administrator.
  2. In the console tree (usually the left pane), double-click to expand Cluster Configuration, and then click Networks.
  3. In the details pane (usually the right pane), click the network you want to enable.
  4. On the File menu, click Properties.
  5. Select the Enable this network for cluster use check box.
  6. Specify how you want the network to be used by the cluster:
    • To use the network for communication with clients and between nodes, click All communications (mixed network).
    • To use the network only for communications between nodes, click Internal cluster communications only (private network).
    • To use the network only for communications with clients, click Client access only (public network).

Note

  • To open Cluster Administrator, click Start, point to Programs, point to Administrative Tools, and then click Cluster Administrator.

Related Topics


Disable a network for cluster use

To disable a network for cluster use

  1. Open Cluster Administrator.
  2. In the console tree (usually the left pane), double-click to expand Cluster Configuration, and then click Networks.
  3. In the details pane (usually the right pane), click the network you want to disable.
  4. On the File menu, click Properties.
  5. Clear the Enable this network for cluster use check box.

Note

  • To open Cluster Administrator, click Start, point to Programs, point to Administrative Tools, and then click Cluster Administrator.
  • After you disable a network for cluster use, the cluster cannot use the network for any communications between nodes or with clients.

Related Topics


Change how the cluster uses a network

To change how the cluster uses a network

  1. Open Cluster Administrator.
  2. In the console tree (usually the left pane), double-click to expand Cluster Configuration, and then click Networks.
  3. In the details pane (usually the right pane), click the appropriate network.
  4. On the File menu, click Properties.
  5. Under Enable this network for cluster use, specify how you want the network to be used by the cluster:
    • To use the network for communication with clients and between nodes, click All communications (mixed network).
    • To use the network only for communications between nodes, click Internal cluster communications only (private network).
    • To use the network only for communications with clients, click Client access only (public network).

Note

  • To open Cluster Administrator, click Start, point to Programs, point to Administrative Tools, and then click Cluster Administrator.

Related Topics


Change the description of a network interface

To change the description of a network interface

  1. Open Cluster Administrator.
  2. In the console tree (usually the left pane), double-click to expand Cluster Configuration, and then click Network Interfaces.
  3. In the details pane (usually the right pane), click the interface for the network on a node.
  4. On the File menu, click Properties.
  5. In Description, type information about the network interface on the node.

Note

  • To open Cluster Administrator, click Start, point to Programs, point to Administrative Tools, and then click Cluster Administrator.
  • The description can provide information about the network interface on a specific node. Your information appears in the details pane when you click the Network Interfaces folder. The description is optional.

Related Topics


Change network priority for communication between nodes

To change network priority for communication between nodes

  1. Open Cluster Administrator.
  2. In the console tree (usually the left pane), click the cluster.
  3. On the File menu, click Properties.
  4. Click the Network Priority tab.
  5. Under Networks used for internal cluster communications, click a network.
  6. Click Move Up to increase the network priority.

    Or, click Move Down to lower the network priority.

Note

  • To open Cluster Administrator, click Start, point to Programs, point to Administrative Tools, and then click Cluster Administrator.

Related Topics


Troubleshoot client-to-virtual server connectivity

To troubleshoot client-to-virtual server connectivity

  1. Try to ping the group IP address from all clients and cluster nodes.

    2. For example, on each client, and both cluster nodes, type the following at the Windows 2000 command prompt:

    ping xxx.xxx.xxx.xxx

    where xxx.xxx.xxx.xxx is the IP address of the virtual server.

    This tests for physical connectivity between the clients and cluster node, and between the two nodes.

  2. Try to ping the virtual server network name from each client and cluster node.

    3. For example, at the Windows 2000 command prompt on each client and on both cluster nodes, type the following:

    ping Netname

    where Netname is the network name for the virtual server.

    This test uses the appropriate name-resolution mechanism (DNS and/or WINS) to test for physical connectivity between the clients and cluster node, and between the two nodes.

  3. If the virtual server has a File Share resource, try to connect to the resource using net use.

    4. For example, at the Windows 2000 command prompt, type the following:

    net use * \\Virtualserver\Sharename

    where Virtualserver is the network name for the virtual server and Sharename is the share name for the File Share resource.

  4. If step 3 shows connectivity but with the wrong IP address, use nbtstat to get more information.

    5. This command displays NetBIOS name registrations with the IP address you specify. For example, type the following at the Windows 2000 command prompt:

    nbtstat -a < IP Address>

    where < IP Address> is the IP address assigned to the IP Address resource for the virtual server group.

    Use this information to isolate the IP problem.

  5. Use ipconfig /all to examine the TCP/IP configuration for all adapters. Ensure that IP addresses are registered to the correct adapters and that each adapter has a primary address.

Related Topics


Perform advanced administrative tasks

  • Change the account under which the Cluster service runs
  • Change the Cluster service account password
  • Give a user permissions to administer a cluster
  • Initiate a resource failure
  • Install the Cluster service using Add/Remove Programs
  • Uninstall the Cluster service
  • Configure the Cluster service to use a different disk for the quorum resource
  • Recover from a corrupted quorum log or quorum disk
  • Enable diagnostic logging
  • Disable diagnostic logging


Change the account under which the Cluster service runs

To change the account under which the Cluster service runs

  1. Use Active Directory Users and Computers to make sure that the new account under which the Cluster service will run has all restrictions cleared except the following:
    • User cannot change password
    • Password never expires
    For more information on modifying user account properties using Active Directory Users and Computers, see Related Topics.
  2. Ensure that the account has membership in the local Administrators group on both nodes.
  3. Grant the following rights to the account, or to the local Administrators group, on both nodes:
    • Log on as a service
    • Lock pages in memory
  4. Open Computer Management.
  5. In Computer Management, double-click Services and Applications, and then double-click Services.
  6. In the details pane, click Cluster Service.
  7. On the Action menu, click Stop.
  8. Repeat steps 4, 5, 6, and 7 on another node.
  9. In the details pane of one node, click Cluster service.
  10. On the Action menu, click Start.
  11. On the Action menu, click Properties.
  12. On the Log On tab, type the account name in This account, type the password in Password, and then confirm the password and click OK.
  13. Repeat steps 9, 10, 11, 12, and 13 on another node.
  14. Start the Cluster service on all nodes. For more information on starting a service, see Related Topics.

Notes

  • To open Computer Management, click Start, point to Programs, point to Administrative Tools, and then click Computer Management.
  • The Cluster service on all nodes must be stopped and restarted during this procedure. The Cluster service must use the same account and password at all times on all nodes within the cluster.
  • You must use Active Directory Users and Computers to view account properties if the account is in a Windows 2000 domain. You must use User Manager for the Domain to view account properties if the account is in a Windows NT 4.0 domain. User Manager for the Domain can be installed using the client-based Network Administration tools by running Setup.exe from the Windows NT Server 4.0 media in the Clients\Srvtools\Winnt\ directory or by running Usrmgr.exe from the Clients\Srvtools\Winnt\I386 or Clients\Srvtools\Winnt\Alpha directory.
  • For more information on granting account rights, see Related Topics.

Related Topics


Change the Cluster service account password

To change the Cluster service account password

  1. Log on to all nodes as a domain administrator.
  2. Open Computer Management.
  3. In the console tree (usually the left pane), double-click Services and Applications, and then double-click Services.
  4. In the details pane (usually the right pane), click Cluster Service.
  5. On the Action menu, click Stop.
  6. Repeat steps 2, 3, 4, and 5 on all nodes.
  7. Use Active Directory Users and Computers to reset the password of the Cluster service account. For more information on using Active Directory Users and Computers to reset a password, see Related Topics.
  8. In Computer Management, click Cluster Service.
  9. On the Action menu, click Properties.
  10. On the Log On tab, type the same password that you typed in step 7.
  11. Repeat steps 8, 9, and 10 for all nodes.
  12. Start the Cluster service on all nodes. For more information on starting services, see Related Topics.

Note

  • To open Computer Management, click Start, point to Programs, point to Administrative Tools, and then click Computer Management.
  • Because the Cluster service runs under the same domain user account on all nodes, you must follow special steps, including stopping the Cluster service on all nodes, when changing the account password. If you forget to change the Cluster service password settings on a node, the service will not run on that node.

Related Topics


Give a user permissions to administer a cluster

To give a user permissions to administer a cluster

  1. Open Cluster Administrator.
  2. Select the cluster.
  3. On the File menu, click Properties.
  4. On the Security tab, give users permissions to administer the cluster.

Notes

  • To open Cluster Administrator, click Start, point to Programs, point to Administrative Tools, and then click Cluster Administrator.
  • Access to the cluster can be granted or denied only to the local Administrators group on each node, domain users, and global groups. Do not attempt to grant or deny access to local users or local groups (other than the local Administrators group).
  • The local Administrator account and local system account always have access to the cluster.

Related Topics


Initiate a resource failure

To initiate a resource failure

  1. Open Cluster Administrator.
  2. In the console tree (usually the left pane), click the Resources folder.
  3. In the details pane (usually the right pane), click the resource you want.
  4. On the File menu, click Initiate Failure.

Notes

  • To open Cluster Administrator, click Start, point to Programs, point to Administrative Tools, and then click Cluster Administrator.
  • When a resource fails, it automatically restarts if a restart policy is defined for it.
  • If a resource fails repeatedly, the entire group to which the resource belongs can fail over, depending on the failover policy defined for the group.
  • This command is useful for testing the restart and failover policies of the resource and group.

Related Topics


Install the Cluster service using Add/Remove Programs

To install the Cluster service using Add/Remove Programs

  1. Open Add/Remove Programs.
  2. Click Add/Remove Windows Components.
  3. The Welcome to the Windows Components wizard will begin.
  4. In Components, select Cluster Service.
  5. Click Next.

Note

  • To open Add/Remove Programs, click Start, point to Settings, click Control Panel, and then double-click Add/Remove Programs.
  • You can safely cancel and restart the installation process.
  • Installing Cluster service is also supported by unattended setup, a feature of Windows 2000. For information about unattended setup, see Related Topics.

Related Topics


Uninstall the Cluster service

To uninstall the Cluster service

  1. Open Add/Remove Programs.
  2. Click Add/Remove Windows Components.
  3. The Welcome to the Windows Components wizard will begin.
  4. Click Next.
  5. In Components, click to clear Cluster Service, and then click Next.

Note

  • To open Add/Remove Programs, click Start, point to Settings, click Control Panel, and then double-click Add/Remove Programs.


Configure the Cluster service to use a different disk for the quorum resource

To configure the Cluster service to use a different disk for the quorum resource

  1. Open Cluster Administrator.
  2. If Cluster Administrator does not start, go to step 5.
  3. In the console tree (usually the left pane), click the cluster name. On the File menu, click Properties.
  4. On the Quorum tab, click a new Quorum resource, and then click OK. Of the default resource types, only the Physical Disk resource can be a quorum resource. However, OEM vendors can supply other storage class resource types capable of storing the quorum resource.
  5. Perform steps 6 through 12 if the Cluster service will not start and you cannot run Cluster Administrator. This may be due to a quorum resource corruption. If the Cluster service and Cluster Administrator are running, go to step 11.
  6. Bring one node online.
  7. Open Computer Management.
  8. In Computer Management, double-click Services and Applications, and then click Services.
  9. In the details pane, click Cluster Service.
  10. On the Action menu, click Properties. In Start parameters type -fixquorum, then click Start.
  11. In Computer Management, use the Services option to stop the Cluster service, and then start the Cluster service without any startup parameters. For more information on stopping and starting a service, see Related Topics.
  12. Bring another node online.

Notes

  • To open Cluster Administrator, click Start, point to Programs, point to Administrative Tools, and then click Cluster Administrator.
  • To open Computer Management, click Start, point to Programs, point to Administrative Tools, and then click Computer Management.

Related Topics


Recover from a corrupted quorum log or quorum disk

To recover from a corrupted quorum log or quorum disk

  1. If the Cluster service is running, open Computer Management.
  2. In the console tree (usually the left pane), double-click Services and Applications, and then click Services.
  3. In the details pane (usually the right pane), click Cluster Service.
  4. On the Action menu, click Stop.
  5. Repeat steps 1, 2, 3, and 4 for all nodes.
  6. On one node, on the Action menu, click Properties.
  7. Under Current status, in Start parameters, specify -noquorumlogging, then click Start.
  8. On the quorum resource disk, run Chkdsk. For more information on running Chkdsk, see Related Topics.

    9. If the disk does not show corruption, then it is likely that the log is corrupted. In this case, you must delete the \MSCS\Quolog.log file and the \MSCS\*.tmp files on the quorum resource disk.

  9. In Computer Management, use the Services option to stop the Cluster service, and then start the Cluster service without any startup parameters. For more information on stopping and starting a service, see Related Topics.

Important

  • When you configure the Cluster service to run without a quorum log, you can lose recent changes that were made to the cluster configuration. This situation occurs when one of the nodes goes offline, the cluster configuration changes, and then the quorum log gets corrupted before the changes can be communicated to the offline node.

Notes

  • To open Computer Management, click Start, point to Programs, point to Administrative Tools, and then click Computer Management.
  • The quorum disk must be formatted with the NTFS file system.
  • If both nodes are not running, or one node fails while you are changing the quorum resource, only the running node is able to form the cluster, and the second node is only able to join the cluster. After the second node has joined the cluster, both nodes are again able to form or join the cluster. This design prevents the offline node from forming the cluster using the old quorum resource.

Related Topics


Enable diagnostic logging

To enable diagnostic logging

  1. Open Control Panel.
  2. Double-click System.
  3. On the Advanced tab, click Environment Variables.
  4. Under System variables, click New.
  5. In Variable Name, specify the name of the variable. In Variable Value, specify the name of the diagnostic log file.

    6. For example, set Variable Name to Clusterlog and Variable Value to C:\Temp\Cluster.log.

  6. Click OK, and then click OK again. Close Control Panel.
  7. Stop and restart the Cluster service. For more information on starting and stopping the Cluster service, see Related Topics.

Notes

  • To open Control Panel, click Start, point to Settings, and then click Control Panel.
  • Cluster diagnostic logging is enabled by default and can be disabled. For more information on disabling diagnostic logging, see Related Topics.
  • Cluster diagnostic logging can assist you in server cluster troubleshooting. The diagnostic cluster log is limited to 8 MB.
  • You must set Clusterlog as a System variable, not a user variable.
  • The cluster.log file is stored at %windir%\cluster.
  • The cluster log records the date and time of a message. It also records the message's process ID and thread ID.

Related Topics


Disable diagnostic logging

To disable diagnostic logging

  1. Open Control Panel.
  2. Double-click System.
  3. On the Advanced tab, click Environment Variables.
  4. Under System variables, select Clusterlog.
  5. Click Delete, click OK, and then click OK again. Close Control Panel.
  6. Stop and restart the Cluster service. For more information on starting and stopping the Cluster service, see Related Topics.

Notes

  • To open Control Panel, click Start, point to Settings, and then click Control Panel.
  • Cluster diagnostic logging is enabled by default.
  • Cluster diagnostic logging can assist you in server cluster troubleshooting. The diagnostic cluster log is limited to 8 megabytes.

Related Topics


Manage cluster hardware

  • Install local SCSI buses and devices
  • Connect the shared SCSI buses and assign drive letters
  • Add drives on the shared SCSI bus
  • Install an additional shared SCSI bus
  • Replace the RAID controller
  • Start a cluster that has SCSI connection problems
  • Test for faulty cables in a cluster


Install local SCSI buses and devices

To install local SCSI buses and devices

  1. Move all groups to the node to which you are not adding the SCSI hardware.
  2. Shut down Windows 2000 Advanced Server on the node to which you want to add the SCSI hardware, and turn off the computer.
  3. Install and configure the SCSI card and devices for the new local SCSI bus, and then install the appropriate SCSI drivers.
  4. Turn on the computer and restart Windows 2000 Advanced Server on node to which you added the SCSI hardware.
  5. If you installed a new drive, partition and format it, assigning new drive letters as appropriate.
  6. Move groups from the node in step 1 to the node with the new SCSI hardware, as appropriate for your cluster configuration.

Related Topics


Connect the shared SCSI buses and assign drive letters

To connect the shared SCSI buses and assign drive letters

  1. Install Windows 2000 Advanced Server on all nodes.
  2. Prepare the SCSI controllers for the shared SCSI bus, following the instructions in your SCSI bus owner's manual.
    • Install the SCSI controllers for the shared SCSI bus, but do not connect them to the shared SCSI bus.
    • Make sure that the SCSI controllers for the shared SCSI bus are using different SCSI IDs. SCSI controller IDs are preset to 7. Reset one SCSI controller ID to 6.
  3. Connect the shared SCSI devices to the shared buses, and then connect the shared SCSI buses to all nodes.
  4. Start Windows 2000 Advanced Server on the first node on which you intend to Install the Cluster service.
  5. Assign drive letters to the disks on the cluster storage device. Make sure that the drive letters will not conflict with existing local drives on any node in the cluster.
  6. Install Cluster service on the first node.
  7. Install Cluster service on all subsequent nodes.

Important

  • Install the Cluster service on at least one node before you run Windows 2000 Advanced Server simultaneously on all nodes.

Related Topics


Add drives on the shared SCSI bus

To add drives on the shared SCSI bus

  1. Shut down Windows 2000 Advanced Server on all nodes, and turn off all computers if you must break the termination of the shared SCSI bus to add a new storage device.
  2. Add or replace drives on the shared SCSI bus.
  3. Turn on the first node if it was turned off in step 1.
  4. On the first node, use Computer Management to assign drive letters to the disks available on the new shared SCSI bus.
  5. Shut down the first node, but do not turn off the computer.
  6. Repeat steps 3 and 4 on the remaining nodes, using the same letter assignments as on the first node.
  7. Restart the first node.

Notes

  • To open Computer Management, click Start, point to Programs, point to Administrative Tools, and then click Computer Management.
  • On a Fibre Channel bus, devices can be added at any time.
  • The Cluster service uses the Plug and Play feature of Windows 2000 to detect new cluster physical disks. For more information on Plug and Play, see Related Topics.

Related Topics


Install an additional shared SCSI bus

To install an additional shared SCSI bus

  1. Shut down Windows 2000 Advanced Server and turn off one computer.
  2. Prepare one SCSI controller for the shared SCSI bus, referring to your SCSI bus owner's manual for instructions.
    • Install the SCSI controllers for the shared SCSI bus, but do not connect them to the shared SCSI bus.
    • Make sure that the SCSI controllers for the shared SCSI bus are using different SCSI IDs. SCSI controller IDs are preset to 7. Reset one SCSI controller ID to 6.
  3. Connect the shared SCSI devices to the shared bus, and then connect the shared SCSI bus to all nodes.
  4. Start Windows 2000 Advanced Server on one node. Turn on the second node, and press SPACEBAR when the operating system Loader screen appears (not allowing Windows Server to start).
  5. On the first node, use Microsoft Management Console (MMC) to assign drive letters to the disks available on the new shared SCSI bus.
  6. Shut down the first node, but do not turn off the computer.
  7. On the second node, select the Windows 2000 Advanced Server operating system and press ENTER.
  8. Assign drive letters to the disks on the shared SCSI bus, using the same letter assignments as on the first node.
  9. Restart the first node.

Note

  • Do not run Windows 2000 Advanced Server on all nodes at the same time until you have completed this procedure.

Related Topics


Replace the RAID controller

To replace the RAID controller

  1. Replacing the RAID controller and updating controller configuration is hardware dependent. Refer to your hardware vendor for information on replacing your RAID controller and the effect that removal of the controller from the shared bus will have on termination.

Related Topics


Start a cluster that has SCSI connection problems

To start a cluster that has SCSI connection problems

  1. Start the computer that does not yet have the Cluster service installed.
  2. At the Windows 2000 startup screen, press SPACEBAR to halt the startup process.
  3. Start the second computer.
  4. Verify that the second computer does not have the quorum resource locked.
  5. If, upon starting, the Cluster service automatically mounts the available quorum resource, locking its use, take the disk resource offline while the other node starts.
  6. Select an operating system to start on the first computer and press ENTER.

Notes

  • The second computer should have the Cluster service installed or be the first node to have the Cluster service installed.
  • Under normal cluster operations, the node that owns the quorum resource locks the drive storing the quorum resource.
Related Topics


Test for faulty cables in a cluster

To test for faulty cables in a cluster

  1. One at a time on each node, make sure that all drives work.
  2. Turn off one node and terminate the connection from the shared SCSI bus to that computer.
  3. On the node that is still attached to the bus, ensure that the drives function.
  4. Repeat steps 2 and 3 for the other node.

Related Topics


Test failover policies

  • Test group failover policy
  • Test group dependencies
  • Test node failure


Test group failover policy

To test group failover policy

  1. Open Cluster Administrator.
  2. In the console tree (usually the left pane), double-click the Groups folder.
  3. In the details pane (usually the right pane), click the group.
  4. On the File menu, click Properties.
  5. Under the Failover tab, set the Threshold to 0. Click OK.
  6. In the console tree of Cluster Administrator, double-click the group.
  7. In the details pane, click a resource that is configured to failover the group. For more information on viewing a resource's properties, see Related Topics.
  8. On the File menu, click Initiate Failure.

Note

  • To open Cluster Administrator, click Start, point to Programs, point to Administrative Tools, and then click Cluster Administrator.
  • Because you set the group failover threshold to 0, the group will immediately fail over.

Related Topics


Test group dependencies

To test group dependencies

  1. Open Cluster Administrator.
  2. In the console tree (usually the left pane), double-click the Groups folder.
  3. In the console tree, click the group.
  4. On the File menu, click Move Group.

    The Owner column in the details pane should reflect a change of owner for all of the group's dependencies.

Note

  • To open Cluster Administrator, click Start, point to Programs, point to Administrative Tools, and then click Cluster Administrator.

Related Topics


Test node failure

To test node failure

  1. Test node failure using one of three methods, as follows:
    • Stop the Cluster service. For more information on stopping the Cluster service, see Related Topics.
    • Press the reset button on the node.
    • Turn off the power on the node.

Related Topics


Concepts

This section provides general background information about server clusters.

  • Server clusters overview
  • Understanding server clusters
  • Planning your server cluster
  • Using server clusters
  • Resources


Server clusters overview

A server cluster is a group of independent computer systems, known as nodes, working together as a single system to ensure that mission-critical applications and resources remain available to clients. These nodes must be running Windows 2000 Advanced Server. Every node is attached to one or more cluster storage devices. Clustering allows users and administrators to access and manage the nodes as a single system rather than as separate computers. For more information about nodes, see Nodes.

A server cluster runs several pieces of software that fall into two categories: the software that makes the cluster run (clustering software) and the software that you use to administer the cluster (administrative software).

Clustering software

The clustering software enables the nodes of a cluster to exchange specific messages that trigger the transfer of resource operations at the appropriate times. There are two main pieces of clustering software: the Resource Monitor and the Cluster service. The Resource Monitor facilitates communication between the Cluster service and application resources. The Cluster service runs on each node in the cluster and controls cluster activity, communication between cluster nodes, and failure operations. When a node or application in the cluster fails, the Cluster service responds by restarting the failed application or dispersing the work from the failed system to the remaining nodes in the cluster. For more information about this process, see Failover and failback.

For more detailed information on the components of the clustering software, see the Windows 2000 Resource Kit.

Administrative software

Administrators use cluster management applications to configure, control, and monitor clusters. Windows 2000 provides Cluster Administrator for this purpose. Any computer running Windows NT 4.0 Service Pack 3 or later, regardless of whether it is a cluster node, can install Cluster Administrator. For information on remote administration, see Installing Cluster Administrator on a remote computer.

You can also administer clusters using the command, cluster. For more information, see Cluster commands overview. You can use or create custom administration tools developed using the Cluster automation interfaces. For more information on the Cluster automation interfaces, see the Microsoft Platform Software Development Kit (SDK), available separately.

Administrators organize cluster resources into functional units, called groups, and assign these groups to individual nodes. If a node fails, the Cluster service transfers the groups that were being hosted by the node to other nodes in the cluster. This transfer process is called failover. The reverse process, failback, occurs when the failed node becomes active again, and the groups that were failed over to other nodes are transferred back to the original node. For more information about resources, see Server cluster resources. For more information about groups, see Groups.


Understanding server clusters

Windows 2000 Advanced Server uses clustering to provide high-availability application support. A server cluster is a group of independent computer systems, called nodes, working together as a single system. Server clusters allow users and administrators to access and manage the nodes as a single system rather than as separate computers.

The following sections describe how Windows 2000 Advanced Server uses server clusters to provide high availability, easy manageability, and enhanced scalability:

  • Cluster application types
  • Server cluster components
  • Cluster objects
  • Server cluster networking


Cluster application types

Applications that run in a server cluster fall into one of four categories:

  1. Cluster-unaware applications

    These types of applications do not interact with the server cluster at all but can still perform well in it.

  2. Cluster-aware applications

    These types of applications achieve optimal performance by implementing awareness of the cluster environment, allowing them to react to cluster events.

  3. Cluster management applications

    These types of applications, which include Cluster Administrator and Cluster.exe allow administrators to manage and configure clusters. For more information, see Server cluster components.

  4. Custom resource types

    Resource types provide customized cluster management for applications, services, and devices. For more information, see Resource types.

For more information on the concepts in this topic, see:

  • Cluster Administrator
  • Cluster commands overview


Server cluster components

Windows 2000 Advanced Server uses the server cluster components to create server clusters that provide high availability, easy manageability, and enhanced scalability. These components work together to manage the cluster objects. The following diagram shows how the cluster components relate to applications of various types and to each other within a single cluster node:

Server Cluster Components

The diagram illustrates three types of applications. For definitions of these application types, see Cluster application types. For more information on cluster objects, see Cluster objects.

For more information on the individual server cluster components, see:

  • Cluster service
  • Resource Monitors
  • Resource DLLs
  • Cluster Administrator
  • Cluster Automation Server
  • Cluster database
  • Network and disk drivers


Cluster service

The Cluster service manages all cluster specific activity. There is one instance of the Cluster service running on every node in a cluster. The Cluster service handles the following operations:

  • Manages cluster objects and configuration.
  • Coordinates with other instances of the Cluster service in the cluster.
  • Handles event notification.
  • Facilitates communication among other software components.
  • Performs failover operations.

For more information on cluster objects, see Cluster objects.


Resource Monitors

A Resource Monitor is a cluster component that acts as an intermediary between the Cluster service and a resource DLL. When the Cluster service makes a request of a resource, the Resource Monitor transfers that request to the appropriate resource DLL. When a resource DLL must report status or notify the Cluster service of an event, the Resource Monitor ensures that the information is delivered successfully. Resource Monitors are passive communication layers; they do not initiate operations.

The Resource Monitor runs in a process separate from the Cluster service for the following reasons:

  • To protect the Cluster service from resource failures.
  • To allow the Resource Monitor to take action if the Cluster service fails. The Resource Monitor detects Cluster Service failure and responds by taking all of the resources and groups on the affected node offline.

Every cluster node runs one or more Resource Monitors. By default, the Cluster service starts only one Resource Monitor to interact with all of the resources hosted by the node. However, this default can be overridden by either an administrator using either Cluster Administrator or another management application. Potentially problematic resource DLLs should be assigned their own Resource Monitor to prevent faulty behavior from affecting other resources and other Resource Monitors.

For more information on the Cluster service, see Cluster service.

For more information on Cluster Administrator, see Cluster Administrator.

For more information on the resource DLLs, see Resource DLLs.


Resource DLLs

You use resource DLLs to manage cluster resources of a particular type. Each resource DLL can manage one or more resource types. When the Cluster service issues a request to a resource, that request is passed to the Resource Monitor. The Resource Monitor, in turn, calls an entry point function in the resource DLL responsible for the resource.

Windows 2000 Advanced Server defines several resource types and provides resource DLLs to manage them. However, a server cluster is not limited to the resource types provided with Windows 2000. Developers can create their own resource DLLs to replace or augment the resource DLLs provided with Windows 2000.


Cluster Administrator

Administrators use cluster management applications to configure, control, and monitor clusters. Cluster Administrator exists for this purpose. You can install Cluster Administrator on Windows 2000 Professional, Windows 2000 Server, and Windows 2000 Advanced Server, regardless of whether it is a cluster node.

Cluster Administrator allows you to manage cluster objects, establish groups, initiate failover, handle maintenance, and monitor cluster activity through a convenient graphical interface. Developers providing their own resource types can write an extension that enables Cluster Administrator to manage their custom types. For more information on developing extensions, see the Microsoft Platform Software Development Kit (SDK).

For more information on using Cluster Administrator to manage your server cluster, see Using Cluster Administrator.


Cluster Automation Server

The Cluster Automation Server exposes a set of 32-bit Component Object Model (COM) objects to any scripting language that supports automation, such as Visual Basic or the Windows Script Host (WSH). By enabling object-oriented design and the use of high-level languages, the Cluster Automation Server simplifies the process of creating a cluster management application.

For information on how to write scripts using the Cluster Automation Server, see the Microsoft Platform Software Development Kit (SDK). For more information on WSH, see Windows Script Host. For more information on cluster management applications, see Cluster application types.


Cluster database

The cluster database resides in the Windows 2000 registry on each cluster node. It contains information about all physical and logical elements in a cluster, including cluster objects, their properties, and configuration data.

Each node's Cluster service maintains a consistent, updated image of the cluster database through the following mechanisms:

  • Global updates. The Cluster service replicates changes to the cluster database uniformly across all nodes.
  • Periodic checkpointing. The Cluster service regularly checks each node's copy of the cluster database to ensure consistency.
  • Quorum resource. The Cluster service ensures that the quorum resource's recovery log contains the most recent cluster database information.

For more information on the concepts in this topic, see:

  • Nodes
  • Cluster objects
  • Cluster service
  • Quorum resource


Network and disk drivers

Network driver

Each node in the cluster runs an instance of the Cluster Network Driver, Clusnet.sys. The Cluster Network Driver is responsible for:

  • Monitoring the status of all network paths between nodes.
  • Routing messages.
  • Detecting communication failure. Each node's Cluster Network Driver exchanges periodic messages, called heartbeats, with the Cluster Network Driver on the other active node. If a node fails to respond to a heartbeat message, the Cluster Network Driver on the node that detects the failure notifies the Cluster service, which initiates failover. Note that failure to respond to a heartbeat message can be caused by node failure, network interface failure, or network failure.

Disk driver

Each node in the cluster runs an instance of the Cluster Disk Driver, Clusdisk.sys. The Cluster Disk Driver is responsible for placing or replacing reservations on disks for the local system.


Cluster objects

Cluster objects are the physical and logical units managed by the Cluster service. For more information on Cluster service, see Cluster service. Each object is associated with:

  • One or more properties, or attributes, that define the object and its behavior within the cluster.
  • A set of cluster control codes used to manipulate the object's properties.
  • A set of object management functions used to manage the object through the Cluster service.

This section covers:

  • Server cluster networks
  • Network interfaces
  • Nodes
  • Groups
  • Server cluster resources
  • Resource types


Server cluster networks

A network (sometimes called an interconnect) performs one of the following roles in a cluster:

  • A network that carries internal cluster communication. The Cluster service authenticates all internal communication, but administrators who are particularly concerned about security can restrict internal communication to physically secure networks.
  • A public network that provides client systems with access to cluster application services. IP Address resources are created on networks that provide clients with access to cluster services.
  • A public-and-private network that carries internal cluster communication and connects client systems to cluster application services.
  • Neither a public nor private network that carries traffic unrelated to cluster operation.

Preventing network failure

The Cluster service uses all available private and public-and-private networks for internal communication. Configure multiple networks as private or public-and-private to protect the cluster from a single network failure. If there is only one such network available and it fails, the cluster nodes stop communicating with each other. When two nodes are unable to communicate, they are said to be partitioned. After two nodes become partitioned, the Cluster service automatically shuts down on one node to guarantee the consistency of application data and the cluster configuration. This can lead to the unavailability of all cluster resources. For example, if each node has only one network adapter, and the network cable on one of the nodes fails, each node, (because it is unable to communicate with the other), attempts to take control of the quorum resource. There is no guarantee that the node with a functioning network connection will gain control of the quorum resource. If the node with the failed network cable gains control, the entire cluster is unavailable to network clients.

Note that all nodes must have at least one subnet in common.

Node-to-node communication

The Cluster service does not use public networks for internal communication, even if a public network is the only available network. For example, a cluster has Network A configured as private and Network B configured as public. Network A fails. The Cluster service does not use Network B because it is public; thus, the nodes stop communicating and the cluster breaks apart.

For more information on the concepts in this topic, see:

  • Nodes
  • Quorum resource


Network interfaces

A network interface is a card or other network adapter that connects a computer to a network. Windows 2000 keeps track of all network interfaces in a server cluster. This allows you to view the state of all cluster network interfaces from a cluster management application, such as Cluster Administrator.

Windows 2000 automatically detects the addition and removal of network interfaces. For more information on this, see Plug and Play network support.


Nodes

A server cluster node is a system that has a working installation of Windows 2000 Advanced Server and the Cluster service. By definition, a node is always a member of a server cluster. For more information on the Cluster service, see Cluster service.

Nodes have the following characteristics:

  • Every node is attached to one or more cluster storage devices. Each cluster storage device attaches one or more disks. The disks store all of the cluster's configuration and resource data. Each disk can be owned by only one node at any point in time, but ownership can be transferred between nodes. The result is that each node has access to all cluster configuration data.
  • Every node communicates with the other nodes in the cluster through one or more physically independent networks, known as interconnects. Network adapters, also called network interfaces, attach nodes to networks.
  • Every node in the cluster can detect another system joining or leaving the cluster.
  • Every node in the cluster can detect the resources that are running locally and the resources that are running on the other cluster nodes.
  • All nodes in the cluster are grouped under a common name, the cluster name, which is used when accessing and managing the cluster.

The following states describe a node's participation in server cluster operation:

State | Meaning
Down | The node is not actively participating in cluster operations.
Joining | The node is in the process of becoming an active participant in the cluster operations.
Paused | The node is actively participating in cluster operations but cannot take ownership of resource groups and cannot bring resources online.
Up | The node is actively participating in all cluster operations.
Unknown | The state cannot be determined.

An active node can host cluster groups. For more information about groups, see Groups

When the Cluster service is installed for the first time on a node, the administrator must choose whether that node forms its own cluster or joins an existing cluster. When the Cluster service is started on a node, that node searches for other active nodes on networks enabled for internal cluster communications.

Forming a new cluster

If a cluster does not already exist, the node attempts to form its own cluster by gaining control of the quorum resource. If the node gains control of the quorum resource, the node forms its own cluster and uses the recovery logs in the quorum resource to update its cluster database. The Cluster service maintains a consistent, updated copy of the cluster database on all active nodes

For more information about the quorum resource, see Quorum resource. For more information on the cluster database, see Cluster database.

Joining an existing cluster

A node can join an existing cluster if it can communicate with another cluster node. If a cluster exists and the joining node finds an active node, it attempts to join that node's cluster. If it succeeds, the Cluster service then validates the node's name and verifies version compatibility. If the validation process succeeds, the node joins the cluster. The node updates its copy of the cluster database from that on the other active node.


Groups

A group is a collection of cluster resources with the following characteristics:

  • Groups define the units of failover. That is, when one resource in a group fails and it is necessary to move the resource to an alternate node, all of the resources in the group are moved to the alternate node. For more information, see Failover and failback.
  • A group is always owned by one node at any point in time. Likewise, a resource is always owned by a single group. These relationships ensure that all of a group's members reside on the same node.

For more information on resources or nodes, see Server cluster resources or Nodes.

Groups enable resources to be combined into larger logical units. Typically a group is made up of related or dependent resources, such as applications and their associated peripherals and data. However, groups can also be established with resources that are unrelated and nondependent to balance the load or for administrative convenience. For more information on dependent resources, see Resource dependencies. For more information on setting resource dependencies, see To set resource dependencies.

Every group maintains a prioritized list of the nodes that can and should act as its host. The preferred nodes list is generated from two sources:

  • The Cluster service produces a list of preferred nodes for a group from the list of possible owners that is maintained by the group's resources. For more information on Cluster service, see Cluster service.
  • Administrators can add nodes to the list through a cluster management application, such as Cluster Administrator. For more information on using Cluster Administrator to specify the preferred owners of a group, see To specify preferred owners of a group.

To fully exploit the processing power of a cluster, administrators should establish at least as many groups as there are nodes in the cluster.

The following topics discuss important concepts related to groups:

  • Virtual servers
  • Failover and failback


Virtual servers

To access a network application or resource in a nonclustered environment, network clients must connect to a physical server (that is, a specific computer on the network identified by a unique network name and IP address). If that server fails, access to the application or resource is impossible.

Through server clusters, Windows 2000 Advanced Server enables the creation of virtual servers. Unlike a physical server, a virtual server is not associated with a specific computer and can be failed over like a group. If the node hosting the virtual server fails, clients can still access its resources using the same server name.

A virtual server is a group that contains:

  • A Network Name resource.
  • An IP Address resource.
  • The applications to be accessed by the clients of the virtual server.

For more information on groups, see Groups.

A virtual server acts like a physical server in the following ways:

  • Allows access to network resources.
  • Is published to network clients under a unique server name.
  • Is associated with a network name and an IP address.

For more information on the concepts in this topic, see:

  • Server cluster resources
  • Nodes


Failover and failback

Failover

If an individual application in a server cluster fails (but the node does not), the Cluster service will typically try to restart the application on the same node. If that fails, it moves the application's resources and restarts them on another node of the server cluster. This process is called failover. The Cluster Administrator can use a graphical console to set various recovery policies, such as dependencies between applications, whether or not to restart an application on the same server, and whether or not to automatically rebalance, or fail back, workloads when a failed server comes back online.

The Cluster service attempts to fail over a group when:

  • The node currently hosting the group becomes inactive for any reason.
  • One of the resources within the group fails, and it is configured to affect the group. For more information on configuring the failure of a resource to affect the group, see To view or set resource properties.
  • You force failover. For more information on forcing a resource to fail over, see To initiate a resource failure.

A failover attempt consists of the following steps:

  1. The Cluster service takes all the resources in the group offline in an order determined by the group's dependency hierarchy: dependent resources first, followed by the resources on which they depend. For example, if an application depends on a Physical Disk resource, the Cluster service takes the application offline first, allowing the application to write changes to the disk before the disk is taken offline.

    2. The Cluster service takes a resource offline by invoking, through a Resource Monitor, the resource DLL that manages the resource. If the resource does not shut down within a specified time limit, the Cluster service forcefully terminates the resource. For more information on setting the time-out value for a resource, see To specify the restart or failover policy for a resource.

  2. When all of the resources are offline, the Cluster service attempts to transfer the group to the node that is listed next on the group's list of preferred host nodes.
  3. If the Cluster service successfully moves the group to another node, it tries to bring all of the group's resources online. Failover is complete when all of the group's resources are online on the new node.

The Cluster service continues attempting to fail over a group until it succeeds or until a defined number of attempts have been made within a given time span. A group's failover policy specifies the maximum number of failover attempts that can occur in an interval of time. If the Cluster service exceeds this limit, it concludes that the group cannot be brought online anywhere in the cluster and stops trying to fail over the group.

Ways to control failover policy

  • Define how the Cluster service detects and responds to the failure of individual resources in the group. For information, see Resource failure.
  • Control the order in which the Cluster service takes resources offline by establishing dependency relationships between resources. For information, see Resource dependencies.
  • Specify time-out, failover threshold, and failover period for resources. The time-out controls how long the Cluster service waits for the resource to shut down. The failover threshold and period control how many times the Cluster service will attempt to fail over a resource in a particular period of time. For more information on how to set these values, see To specify the restart or failover policy for a resource.
  • Specify a possible owner list for resources. The possible owner list for a resource controls which cluster nodes are allowed to host the resource. For more information on how to set the possible owner list for a resource, see To specify which nodes can own a resource.

For more information on the Cluster service, see Cluster service.

Failback

When a node becomes inactive for any reason, the Cluster service fails over any groups hosted by the node. When the node becomes active again, the Cluster service can fail back the groups originally hosted by the node.

The Cluster service fails back a group using the same procedures it performs during failover—that is, the Cluster service takes all of the resources in the group offline, moves the group, and then brings all of the resources in the group online.

For more information on how to configure a group's failback policy, see To set group failback policy.


Server cluster resources

A cluster resource is any physical or logical component that has the following characteristics:

  • Can be brought online and taken offline.
  • Can be managed in a server cluster.
  • Can be hosted (owned) by only one node at a time.

To manage resources, the Cluster service communicates to a resource DLL through a Resource Monitor. When the Cluster service makes a request of a resource, the Resource Monitor calls the appropriate entry-point function in the resource DLL to check and control the resource's state. For more information on Resource Monitor or resource DLL, see Resource Monitors or Resource DLLs.

Dependent resources

A dependent resource is one that requires another resource to operate. For example, a network name must be associated with an IP address. Because of this requirement, a Network Name resource is dependent on an IP Address resource. Dependent resources are taken offline before the resources upon which they depend are taken offline, likewise, they are brought online after the resources on which they depend are brought online. A resource can specify one or more resources on which it is dependent.

A resource can also specify a list of nodes on which it is able to run. Preferred nodes and dependencies are important considerations when administrators organize resources into groups. For more information on preferred nodes and groups, see Groups. For more information on nodes, see Nodes.

The following topics describe important concepts related to resources:

  • Quorum resource
  • Resource failure
  • Resource dependencies
  • Cluster resource visibility


Quorum resource

In every cluster, a single resource is designated as the quorum resource. This resource maintains the configuration data necessary for recovery of the cluster. This data, in the form of recovery logs, contains details of all of the changes that have been applied to the cluster database. This provides node-independent storage for cluster configuration and state data.

Quorum resource and the cluster database

The cluster database is an integral part of the formation of a server cluster. When a node joins or forms a cluster, the Cluster service must update the node's private copy of the cluster database. When a node joins an existing cluster, the Cluster service can retrieve the data from the other active nodes. However, when a node forms a cluster, no other node is available. The Cluster service uses the quorum resource's recovery logs to update the node's cluster database. To ensure cluster unity, Windows 2000 uses the quorum resource to ensure that only one set of active, communicating nodes is allowed to operate as a cluster. A node can form a cluster only if it can gain control of the quorum resource. A node can join a cluster or remain in an existing cluster only if it can communicate with the node that controls the quorum resource.

For more information on the cluster database, see Cluster database.

For more information on cluster resources, see Server cluster resources.

Scenarios

To illustrate the importance of the quorum resource, consider these situations in a simple two-node cluster:

  • Node 1 fails. Node 2 continues operating, writing changes to the cluster database. But before node 1 can be restarted, node 2 fails. When node 1 becomes active, it must update its private copy of the cluster database with the changes made by node 2. The Cluster service uses the quorum resource's recovery logs to perform the update.
  • The networks providing communication between nodes 1 and 2 fail. Each node assumes the other node has failed and attempts to continue operating as the cluster. If both could succeed, the result would be two separate clusters using the same cluster name and competing for the same resources. Windows 2000 uses quorum resource ownership to maintain cluster unity and solve this problem. In this scenario, the node that gains control of the quorum resource is allowed to form a cluster, and the other fails over its resources and becomes inactive.

The quorum resource can be any resource with the following attributes:

  • The resource must enable a single node to gain physical control of it and defend its control. For example, SCSI disks can use their reserve and release commands for persistent arbitration.
  • The resource must provide physical storage that can be accessed by any node in the cluster.
  • The resource must use the NTFS file system.

The only type of resource that comes with Windows 2000 that can act as a quorum resource is the Physical Disk resource. However, other developers can create their own quorum resource types for any resources that meet the arbitration and storage requirements. For more information, see the Microsoft Software Development Kit (SDK).


Resource failure

The Cluster service considers a resource to be failed when the resource is not operational and cannot be restarted on the current host node. The Cluster service detects resource failure as follows:

  • At periodic intervals, the Cluster service checks to see if the resource appears operational. It does this by periodically invoking the Resource Monitor. The Resource Monitor, in turn, relies on the resource DLL for each resource to implement a procedure to detect if the resource is functioning properly. The resource DLL communicates the results back through the Resource Monitor to the Cluster service. You can specify how frequently the Cluster service checks for failed resources by setting the Looks Alive and Is Alive poll intervals. The Cluster service requests a more thorough check of the resource's state at each Is Alive interval than it does at each Looks Alive interval; therefore, the Is Alive poll interval is typically longer than the Looks Alive poll interval. For more information on how to set poll intervals, see To specify the restart or failover policy for a resource.

    • For more information on Resource Monitors, see Resource Monitors.

  • If the resource DLL reports that the resource is not operational, the Cluster service attempts to restart the resource. You can specify the number of times the Cluster service can attempt to restart a resource in a given time interval. If the Cluster service exceeds the maximum number of restart attempts within the specified time period, and the resource is still not operational, the Cluster service considers the resource to be failed. For more information, see To set group failover policy.

You can configure whether a failed resource causes the group that contains the resource to be failed over to another node. For more information, see Setting advanced resource properties.

For more information on cluster resources, see Server cluster resources.

If the failed resource is configured to cause the group that contains the resource to failover to another node, Cluster service will attempt a failover. If the number of failover attempts exceeds the group's Threshold and the resource is still in a failed state, Cluster service will attempt a restart of the resource. The restart attempt will be made after a period of time specified by the resource's Retry Period On Failure property, a property common to all resources.

The unit value of this property is in milliseconds but you should choose a value that is in the order of minutes. You should also choose a value that is greater or equal to the value of the resource's restart period property and this rule is enforced.


Resource dependencies

A dependent resource requires, or depends on, another resource to operate. For example, if a Generic Application resource requires access to clustered physical storage, it would depend on a Physical Disk resource.

The following terms describe resources in a dependency relationship:

  • A dependent resource depends on other resources (the dependencies).
  • A dependency is a resource on which another resource depends.
  • A dependency tree is a series of dependency relationships such that resource A depends on resource B, resource B depends on resource C, and so on.

Resources in a dependency tree obey the following rules:

  • A dependent resource and all of its dependencies must be in the same group.
  • The Cluster service takes a dependent resource offline before any of its dependencies are taken offline, and brings a dependent resource online after all its dependencies are online, as determined by the dependency hierarchy.

Some of the resource types provided with Windows 2000 have required dependencies. For more information, see Setting resource dependencies.

For more information on the concepts in this topic, see:

  • Server cluster resources
  • Resource types


Cluster resource visibility

When users browse the network, they can see more resources associated with a network name than you may have intended.

This happens because the browsing the network is a two-stage process. First, you locate the computer associated with a network name. Second, you ask that computer to list all of the resources that it owns. If that computer is a cluster node that hosts multiple virtual servers, you can get unintended results. For example, suppose the node called ClusterNode hosts two virtual servers, PrintServer and FileServer. In the PrintServer resource group, you have a network printer named ClusterPrinter, and in the FileServer resource group, you have a file share named ClusterFileShare. When users browse the network, all three network names (ClusterNode, PrintServer, and FileServer) are associated with the same cluster node, and that cluster node owns two resources (ClusterPrinter and ClusterFileShare). Therefore, when users browse the network, they will see ClusterPrinter and ClusterFileShare associated with all three network names.

This allows users to circumvent your intended usage of network names. In the previous example, you place PrintServer and ClusterPrinter in the same resource group because you want both the network name and the printer resource to fail over as a unit to other cluster nodes; users who connect to ClusterPrinter through the network name PrintServer can maintain the connection in the event of a failover. However, users in the previous example can connect to ClusterPrinter through the network names ClusterNode and FileServer as well. If users do this, they will lose their connection to ClusterPrinter in the event of a failover because the resource ClusterPrinter will no longer belong to the computer named by ClusterNode or FileServer.

You can minimize the potential for problems by:

  • Using cluster and node names that are easily identifiable by administrators, but not users.
  • Defining virtual-server names that are easily identifiable by users.
  • Associating the virtual server names with the resources hosted by the virtual server (for example, ClusterPrintServer is a good name for a virtual server that hosts a printer named ClusterPrinter).

For more information on virtual servers, see Virtual servers.


Resource types

Cluster resources are categorized by type. Windows 2000 defines several types of resources and provides resource DLLs to manage the types. Developers are encouraged to create new types to fit the specific needs of their cluster-aware applications and services. By creating a new resource type, developers can have more control over how the Cluster service manages their application or service.

For more information on the resource types provided with Windows 2000, see Standard resource types.

For more information on the concepts in this topic, see:

  • Server cluster resources
  • Resource DLLs


Server cluster networking

This section covers:

  • The Cluster service and TCP/IP
  • The Cluster service and name resolution
  • Server cluster network communication between nodes


The Cluster service and TCP/IP

The Cluster service requires the TCP/IP suite for its internal and client communication.

TCP/IP is an industry-standard suite of protocols, providing communications in a heterogeneous environment. While TCP/IP is best known for its access to the Internet and Internet resources, TCP/IP is also well-suited as an enterprise networking protocol because it provides interoperability between different types of computer systems. For more information on TCP/IP, see TCP/IP.

The Cluster service and DHCP

Windows 2000 supports the use of DHCP addresses as private node addresses (you configure private node addresses through the Network and Dial-up Connections folder, not through cluster management software). The Cluster service uses the Plug and Play network support to handle the events that occur when a DHCP-allocated IP address changes.

However, using short-term DHCP leases for a private node address has some disadvantages:

  • First, when the address lease expires for a network, the node cannot communicate over that network until it obtains a new address. This makes the node's availability dependent on the availability of the DHCP server; the node cannot communicate over the network until it obtains its address from the DHCP server.
  • Second, if an address lease expires on a network configured for public communication (communication between cluster nodes and clients), it may trigger failover for resource groups that used an IP Address resource on that network.

    • If possible, use either static IP addresses or a permanently leased DHCP address for private node addresses.

    The Cluster service does not support the use of IP addresses assigned from a DHCP server for the cluster administration address (which is associated with the cluster name) or any IP Address resources.


The Cluster service and name resolution

Clients use name resolution services to find network resources. Clients use these same services to find resources in a server cluster. The Cluster service also uses these services when a node joins another node to form a cluster.

In both cases, name resolution is the process of translating computer names to IP addresses. You can use the Windows Internet Name Service (WINS), the Domain Name System (DNS), or both. You can also use IP broadcast name resolution. However, because IP broadcast name resolution increases network traffic, and is ineffective in routed networks, this book assumes you are using WINS or DNS.

The Cluster service does not require any special configuration of either WINS or DNS. If you use WINS, all cluster resource names that have associated IP addresses are registered with WINS.

You should not use static WINS mappings for cluster resources. If you do, the clustering software cannot update the WINS entries in the event of a failover. For more information on static versus dynamic WINS entries, see Using static mappings.


Server cluster network communication between nodes

Communication between the nodes of a cluster enables the Cluster service to detect node failures, status changes, and to manage the cluster as a single entity. Communication sessions can be multiplexed over multiple networks to eliminate a single point of failure.

Nodes in a cluster communicate using their installation of the Cluster service. The Cluster service keeps track of the current state of the nodes within a cluster and determines when a group and its resources should fail over to an alternate node. This communication takes the form of messages that are sent regularly between the each node's Cluster service. These messages are called heartbeats.

In addition to heartbeat traffic, some network traffic occurs during startup, failover, and whenever changes are made to the cluster. During startup, node-to-node communication occurs for the purpose of synchronizing the cluster databases that reside on each node. The cluster database stores configuration information about the cluster resources.


Planning your server cluster

This section covers the options you should consider as you plan how to set up server clusters to work most efficiently in your organization.

This section covers:

  • Addressing risks using server clusters
  • Choosing applications to run on a server cluster
  • Determining failover policies for groups
  • Choosing a domain model
  • Limitations of server clusters
  • Choosing a cluster model
  • Capacity planning
  • Planning for fault-tolerant disks
  • Optimizing your clusters


Addressing risks using server clusters

When you configure a cluster, you should identify the possible failures that can interrupt access to resources. A single point of failure is any component in your environment that would block data or applications if it failed. Single points of failure can be hardware, software, or external dependencies, such as power supplied by a utility company and dedicated wide area network (WAN) lines.

In general, you provide maximum reliability when you:

  • Minimize the number of single points of failure in your environment.
  • Provide mechanisms that maintain service when a failure occurs.

With Windows 2000, you can use server clusters and new administrative procedures to provide increased reliability. However, server clusters are not designed to protect all components of your work flow in all circumstances. For example, clusters are not an alternative to backing up data; clusters protect only availability of data, not the data itself.

Windows 2000 Advanced Server has built-in features that protect certain computer and network processes during failure. These features include mirroring (RAID Level 1) and Redundant Array of Independent Disks (RAID Level 5, striping with parity). When planning your cluster, look for places where these features can help you in ways that server clusters cannot.

The following table lists common points of failure and describes whether the point of failure can be protected, either by server clusters or by other means.

Failure point | Server cluster solution | Other solutions
Network hub | Redundant networks. For more information, see Configuring cluster network hardware. | --
Utility-company power | -- | Uninterruptable power supply (UPS). Put each cluster node on a separate circuit.
Server connection | Failover | --
Disk | -- | Hardware RAID, to protect the data on the disk. For more information, see Using RAID.
Other server hardware, such as CPU or memory | Failover | --
Server software, such as the operating system or specific applications | Failover | --
Wide area network (WAN) links, such as routers and dedicated lines | -- | Redundant links over the WAN, to provide secondary access to remote connections
Dial-up connection | -- | Multiple modems
Client computer within your organization | -- | Configuring multiple clients for the same level of access (If one client fails, you still have access through other clients.)

To further increase the availability of network resources and prevent the loss of data:

  • Consider having replacement disks and controllers available at your site. Always make sure that any spare parts you keep on hand exactly match the original parts, including network and SCSI components. The cost of two spare SCSI controllers can be a small fraction of the cost of having hundreds of clients unable to use data.
  • Consider providing UPS protection for individual computers and the network itself, including hubs, bridges, and routers. Computers running Windows Server support UPS. Many UPS solutions provide power for 5 to 20 minutes, which is long enough for the operating system to do an orderly shutdown when power fails.


Choosing applications to run on a server cluster

Many, but not all, applications can be adapted to run on a server cluster. Of those that can, not all need to be set up as cluster resources. This section offers guidelines for making these decisions.

Three criteria determine whether an application can adapt to server clustering failover mechanisms:

  • The application must use TCP/IP.

    Client/server applications must use TCP/IP (or DCOM, Named Pipes, or RPC over TCP/IP) for their network communications in order to run on a server cluster. Any application that uses only NetBEUI or IPX protocols cannot take advantage of cluster failover.

  • The application must be able to specify where the application data is stored.

    Any application you run on a server cluster must be able to store its data in a configurable location, that is, on the disks attached to shared buses. Some applications that cannot store their data in a configurable location can still be configured to fail over. However, in such cases access to the application data is lost at failover because the data is available only on the disk of the failed node.

  • Client applications that connect to the server application must retry and recover from temporary network failures.

    During failover, client applications will experience a temporary loss of network connectivity. If the client application is configured to recover from temporary network connection problems, it will be able to continue operating after a server failover.

Applications that can be failed over can be further divided into two groups: those that support the Cluster API and those that do not.

Applications that support the Cluster API are defined as cluster-aware. These applications can register with the Cluster service to receive status and notification information, and they can use the Cluster API to administer clusters.

Applications that do not support the Cluster API are defined as cluster-unaware. If cluster-unaware applications meet the TCP/IP and remote-storage criteria, they can still be used in a cluster and often can be configured to fail over.

In either case, applications that keep significant state information in memory are not the best applications for clustering because information that is not stored on disk is lost at failover.


Determining failover policies for groups

You assign the failover policies for each group of resources in your cluster. These policies determine exactly how a group behaves when failover occurs. You can choose which policies are most appropriate for each resource group you set up. For more information on setting failover policies, see Setting group properties .

Failover policies for groups include three settings:

  • Failover timing

    You can set a group for immediate failover when a resource fails, or you can instruct the Cluster service to try to restart the group a number of times before failover occurs. If it is possible that the resource failure can be overcome by restarting all resources within the group, then set the Cluster service to restart the group.

  • Preferred node

    You can set a group so that it always runs on a designated node whenever that node is available. This is useful if one of the nodes is better equipped to host the group.

  • Failback timing

    You can set a group to fail back to its preferred node as soon as the Cluster service detects that the failed node has been restored, or you can instruct the Cluster service to wait until a specified hour of the day, such as after peak business hours.


Choosing a domain model

Nodes in a server cluster can be either member servers or domain controllers. However, in either case, both nodes must belong to the same domain.

If you configure your cluster nodes as domain controllers, you must first ensure that you have the hardware to support them. For more information, see Capacity planning.

If you configure all of the cluster nodes as member servers, then the availability of the cluster will depend on the availability of the domain controller. The domain controller must be highly available. For more information on increasing availability, see Addressing risks using server clusters.

You should account for the additional overhead that is incurred by the domain controller services. In large networks running on Windows 2000, substantial resources can be required by domain controllers for performing directory-replication and server-authentication for clients. For this reason, many applications, such as Microsoft SQL Server and Message Queuing, recommend that you not install the application on domain controllers for best performance. However, if you have a very small network in which account information rarely changes and in which users do not log on and off frequently, you can use domain controllers as cluster nodes.


Limitations of server clusters

This topic covers important limitations of Windows 2000 server clusters.

  • Remote Storage

    You should not install remote storage devices on a shared SCSI bus used by the cluster.

    You should not configure remote storage devices as cluster resources.

  • Disk configuration

    You cannot configure external disks as dynamic disks or spanned volumes (volume sets) if they will be used as cluster resources.

    Disks to be used for cluster storage must be configured as basic disks and must be formatted using the NTFS file system. Windows 2000 does not support the use of dynamic disks or the features of dynamic disks, such as spanned volumes (volume sets), for cluster storage. You cannot change an existing cluster disk, such as the quorum disk, to a dynamic disk.

    You cannot use the Encrypting File System, Remote Storage, mounted volumes, or parse points on the cluster storage.

    You cannot enable write cache on an internal SCSI RAID controller because the data in the cache will be lost during failover. An example of an internal controller is a Peripheral Component Interconnect (PCI) card inside the node. You should enable write cache on an external RAID controller. An external RAID controller is usually inside the disk cabinet and the data in the cache will failover.

    You cannot use software RAID. You can use hardware RAID to protect the data on your cluster disk.

  • Network configuration

    The Cluster service supports only TCP/IP.

    All network interfaces used on all nodes in a server cluster must be on the same network. All cluster nodes must have at least one subnet in common.

  • Terminal Services

    You can use Terminal Services for remote administration on a server cluster node. You cannot use Terminal Services for application server on a server cluster node.


Choosing a cluster model

Clusters can be categorized in five configuration models. This section describes each model and gives examples of the types of applications that are suited to each.

  • Model A: High-availability solution with static load balancing
  • Model B: "Hot spare" solution with maximum availability
  • Model C: Partial server cluster solution
  • Model D: Virtual server only solution with no failover
  • Model E: Hybrid solution


Model A: High availability solution with static load balancing

This model provides high availability and acceptable performance when only one node is online, and high performance when both nodes are online. The model also allows maximum utilization of your hardware resources.

In this model, each of the two nodes makes its own set of resources available to the network in the form of virtual servers, which can be detected and accessed by clients. The capacity for each node is chosen so that the resources on each node run at optimum performance, but so that either node can temporarily take on the burden of running the resources from the other when failover occurs. Depending on the resource and server capacity specifications, all client services remain available during failover, but performance can suffer.

Configuration for high availability with static load balancing

For example, you can use this model for a cluster dedicated to file-sharing and print-spooling services. Two file and print shares are established as separate groups, one on each node. If one node fails, the other node temporarily takes on the file-sharing and print-spooling services for both shares. The failover policy for the group that is temporarily relocated is set to prefer its original node. When the failed node is restored, the relocated group returns to the control of its preferred node, and operations resume at normal performance. Services are available to clients throughout the process with only a minor interruption.

  • Availability: High
  • Suggested failover policies: Assign a preferred server to each group.
  • Suggested failback parameters: Allow failback for all groups.

Two business scenarios

Using Model A can solve two problems that typically occur in a large computing environment. The first problem occurs when a single server is running multiple large applications, causing a degradation in performance. To solve the problem, a second server is clustered with the first, and the applications are split across the servers.

The second problem involves related applications running on separate servers. The problem of availability arises when the two servers are not connected. By placing them in a cluster, the client is ensured greater availability of both applications.

Case one: improving performance

Suppose your corporate intranet relies on a server that runs two large database applications. Both of these databases are critical to hundreds of users who repeatedly connect to this server throughout the day.

Problem: During peak connect times, the server cannot keep up with the demand and performance.

Solution: To alleviate the problem, you attach another server to your overloaded server, form a cluster, and balance the load. You now have two servers, each running one of the database applications. If one server ever fails, you are put back in your original situation of degraded performance, but only temporarily. When the failed server is restored, the application it was running fails back, and operations resume.

Case 1: Adding a server to improve performance

Case two: ensuring availability

Suppose your retail business relies on two separate servers, one that provides external Internet Web services and another that provides a database application for inventory and ordering information.

Problem: Both of these services are essential to your business. Without Web access, customers cannot browse your online catalog. Without access to the database application, customers cannot place orders, and employees cannot access inventory or shipping information.

Case 2, the problem: two nonclustered servers that depend on each other

Solution: To ensure the availability of all services, you join the computers into a cluster. This solution is similar to the one in the previous scenario, but you use it to take advantage of clustering differently.

You create a cluster that contains two groups, one on each node. One group contains all of the resources needed to run the Web-service applications, such as IP addresses, and the other group contains all of the resources for the database application, including the database itself.

Case 2, the solution: clustering two servers to improve availability

In the failover policies of each group, specify that both groups can run on either node, thereby assuring their availability if one node should fail.


Model B: "Hot spare" solution with maximum availability

This model provides the maximum availability and performance for your resources, but requires an investment in hardware that is not in use most of the time.

One node, called a primary node, supports all clients, while its companion node is idle. The companion node is a dedicated "hot spare," ready to be used whenever a failover occurs. If the primary node fails, the "hot spare" node immediately picks up all operations and continues to service clients at a rate of performance that is close or equal to that of the primary node. (Exact performance depends on the capacity of the "hot spare" node.)

Hot spare configuration

This model is best suited for your organization's most important applications and resources. For example, if your organization relies on sales over the World Wide Web, you can use this model to provide "hot spare" nodes for all servers dedicated to supporting Web access, such as those servers running Internet Information Services. The expense of doubling your hardware in this area is justified by the protection of clients' access to your organization. If one of your Web servers fails, a second server is fully configured to take over its operations.

  • Availability: Very high
  • Suggested failover policies: This depends on capacity. If your budget allows for a "hot spare" server with identical capacity to its primary node, then you do not need to set a preferred server for any of the groups. If one node has greater capacity than the other, setting the group failover policies to prefer the larger server keeps performance as high as possible.
  • Suggested failback parameters: This, too, depends on capacity. If the "hot spare" node has identical capacity to the primary node, prevent failback for all groups. If the "hot spare" node has less capacity than the primary node, set the policy for immediate failback or for failback at a specified off-peak hour.


Model C: Partial server cluster solution

This model demonstrates the flexibility of using applications that cannot fail over on the same servers from which resource groups are set to fail over.

One of the steps in planning resource groups is identifying applications that you will not configure to fail over. Those applications can reside on servers that form clusters, but they must store their data on local disks, not on disks on the shared bus. Because these applications are not subject to failover, they have only normal availability. If the availability of these applications is important, you must find other methods of providing it.

Configuration with mixed failover policies

The figure shows group failover. The applications in the other groups also serve clients on one of the servers, but because they are not cluster-aware, no failover policies are established for them. For example, you might use a node to run a mail server that has not been designed to use failover, or for an accounting application that is used so infrequently that availability is not important.

When node failure occurs, the applications that are not configured with failover policies are unavailable unless they have built-in failover mechanisms of their own. They remain unavailable until the node on which they run is restored; you must either restart them manually or set Windows 2000 to automatically start them when the system software starts. The applications you configured with failover policies fail over as usual, according to those policies.

  • Availability: High for applications configured for failover, normal for others
  • Suggested failover policies: Variable
  • Suggested failback parameters: Variable


Model D: Virtual server only solution with no failover

This model shows how you can use the virtual server concept with applications on a single-node server cluster.

This cluster model makes no use of failover. It is merely a way of organizing the resources on a server for administrative convenience and for the convenience of your clients. The main advantage is that both administrators and clients can readily see descriptively named virtual servers on the network rather than navigating a list of actual servers to find the shares they need.

Other advantages of this model include:

  • The Cluster service automatically restarts the various groups of applications and their dependent resources after the server is restored (following a failure). This is useful for applications that benefit from an automatic restart function but do not have their own mechanisms for accomplishing it.
  • The single node can be clustered with a second node at a future time, and the resource groups are already in place. After you configure failover policies for the groups, the virtual servers are ready to operate.
Virtual server only, with no second node or failover policies

You can, for example, use this model to locate all of your organization's file and print resources on a single computer, establishing separate groups for each department. When clients from one department need to connect to the appropriate file or print share, they can find the share as easily as they would find an actual computer.

  • Availability: Normal
  • Suggested failover policies: Not applicable
  • Suggested failback parameters: Not applicable


Model E: Hybrid solution

This model is a hybrid of the others. Using the hybrid solution model, you can incorporate advantages of the previous models and combine them in one cluster. As long as you have provided sufficient capacity, many types of failover scenarios can coexist on the same two nodes. All failover activity occurs as normal, according to the policies you set up.

Hybrid configuration

The figure shows an example of static load balancing for two database shares, allowing somewhat reduced performance when both shares are on a single node. For administrative convenience, the two file-and-print shares in the cluster (which do not require failover ability) are grouped logically by department and configured as virtual servers. Finally, an application that cannot fail over resides on one of the clusters and operates as normal (without any failover protection).

  • Availability: High or very high for resources set to fail over
  • Suggested failover policy: Variable


Capacity planning

After you assess your clustering needs, you are ready to determine how many servers you need and with what specifications, such as memory and hard disk storage..

This section covers:

  • Planning your groups
  • Determining server-capacity requirements


Planning your groups

There are six steps you can take to organize your applications and other resources into groups:

List all your server-based applications

Most groups contain one or more applications. Make a list of all applications in your environment, regardless of whether or not you plan to use them with the Cluster service. Your total capacity needs are determined by the sum of the total number of groups (virtual servers) that will run in your environment and the total amount of other software you will run independently of groups.

Sort the list of applications

Determine which of your applications can use failover. For more information, see Choosing applications to run on a server cluster.

Also list applications that will reside on cluster nodes but which will not use the failover feature because it is inconvenient, unnecessary, or impossible to configure the applications for failover. Although you do not set failover policies for these applications or arrange them in groups, they still use a portion of the server capacity.

Before clustering an application, review the application license, or check with the application vendor. Each application vendor sets its own licensing policies for applications running on clusters.

List all other resources

Determine which hardware, connections, and operating-system software a server cluster can protect in your network environment. For more information, see Addressing risks using server clusters.

For example, the Cluster service can fail over print spoolers, to protect client access to printing services. Another example is a file-server resource, which you can set to fail over, maintaining client access to files. In both cases, capacity is affected, such as the RAM required to service the clients.

List all dependencies for each resource

When you create this list, include all resources that support the core resources. For example, if a Web-server application fails over, the Web addresses and disks on the shared buses containing the files for that application must also fail over if the Web server is to function. All these resources must be in the same group. This ensures that the Cluster service keeps interdependent resources together at all times.

Two guidelines for quantifying resources are:

  • A resource and its dependencies must be together in a single group.
  • A resource cannot span groups.

For example, if several applications depend on a particular resource, you must include all of those applications with that resource in a single group.

Make preliminary grouping decisions

Another factor in the way you assign groups is administrative convenience. For example, you might put several applications into one group because viewing those particular applications as a single entity makes it easier to administer the network.

A common use of this technique is to combine file-sharing resources and print-spooling resources in a single group. All dependencies for those applications must also be in the group. You can give this group a unique name for the part of your organization it serves, such as "Accounting File&Print." Whenever you need to intervene with the file- and print-sharing activities for that department, you would look for this group in Cluster Administrator.

Another common practice is to put applications that depend on a particular resource into a single group. For example, suppose a Web-server application provides access to Web pages, and that those Web pages provide result sets that clients access by querying an SQL-database application, through the use of Hypertext Markup Language (HTML) forms. By putting the Web server and the SQL database in the same group, the data for both core applications can reside on a specific disk volume. Because both applications exist within the same group, you can also create an IP address and network name specifically for this resource group.

Make final grouping assignments

After you list the resources that you want to group together, assign a different name to each group, and create a dependency tree. A dependency tree is useful for visualizing the dependency relationships between resources.

To create a dependency tree, first write down all the resources in a particular group. Then draw arrows from each resource to each resource on which the resource directly depends.

A direct dependency between resource A and resource B means that there are no intermediary resources between the two resources. An indirect dependency occurs when a transitive relationship exists between resources. If resource A depends on resource B and resource B depends on resource C, there is an indirect dependency between resource A and resource C. However, resource A is not directly dependent on resource C.

The figure shows the resources in a final grouping assignment in a dependency tree.

Final grouping assignments, including dependencies

In the previous diagram, the File Share resource depends on the Network Name resource, which, in turn depends, on the IP Address resource. However, the File Share resource does not directly depend on the IP Address resource. In this example, both the Network Name resource and the IIS Virtual Root resource depend on the IP Address resource. However, there is no dependency between the Network Name resource and the IIS Virtual Root resource. In fact, these relationships can be viewed as two separate dependency trees: one tree includes the IIS Virtual Root resource and the IP Address resource, and the other tree contains the File Share resource, Network Name resource, and IP Address resource.

For information on using Cluster Administrator to set resource dependencies, see Setting resource properties.


Determining server-capacity requirements

After you choose a cluster model, determine how to group your resources, and determine the failover policies required by each resource, you are ready determine the hardware capacity required for each server in the cluster. The following sections explain the criteria for choosing computers for use as cluster nodes.

  • Hard-disk-storage requirements

    • Each node in a cluster must have enough hard-disk capacity to store permanent copies of all applications and other resources required to run all groups. Calculate this for each node as if all of these resources in the cluster were running on that node, even if some or all of those groups run on the other node most of the time. Plan these disk-space allowances so that either node can efficiently run all resources during failover.

  • CPU requirements

    • Failover can strain the CPU processing capacity of a node when it takes control of the resources from a failed node. Without proper planning, the CPU of a surviving node can be pushed beyond its practical capacity during failover, slowing response time for users. Plan your CPU capacity on each node so that it can accommodate new resources without unreasonably affecting responsiveness.

  • RAM requirements

    • When planning your capacity, make sure that each node in your cluster has enough RAM to run all applications that may run on either node. Also, make sure your Windows 2000 paging files are set appropriately for each node's RAM.


Planning for fault-tolerant disks

Many groups include disk resources for disks on shared buses. In some cases, these are simple physical disks, but in other cases they are complex disk subsystems containing multiple disks. Almost all resource groups depend on the disks on the shared buses. An unrecoverable failure of a disk resource results in certain failure of all groups that depend on that resource.

For these reasons, you might decide to use special methods to protect your disks and disk subsystems from failures. One common solution is the use of a hardware-based redundant array of independent disks (RAID) solution. RAID support ensures the high availability of data contained on disk sets in your clusters. Some of these hardware-based solutions are considered fault tolerant, which means that data will not be lost if a member of the disk set fails.

Important

  • You cannot use software fault-tolerant disk sets for cluster storage.

This section covers:

  • Hardware RAID
  • Error recovery


Hardware RAID

The Microsoft Windows Hardware Compatibility List contains many different hardware RAID configurations for clusters. Because many hardware RAID solutions provide power, bus, and cable redundancy within a single cabinet, and track the state of each component in the hardware RAID firmware, they provide data availability with multiple redundancy, protecting against multiple points of failure. Hardware RAID solutions can also use an onboard processor and cache.

Windows 2000 can use these disks as standard disk resources.

For more information on the different hardware RAID configurations, see the Microsoft Windows Hardware Compatibility List at the Microsoft Web site.(http://www.microsoft.com/) In the Category list box, click Cluster.

Important

  • You cannot use software fault-tolerant disk sets for cluster storage.

Note

  • You should use dual, redundant RAID controllers.


Error recovery

With transaction logging and recovery, the NTFS file system ensures that the volume structure will not be corrupted, so all files remain accessible after a system failure. The NTFS file system also uses the recovery technique called cluster-remapping. When Windows 2000 returns a bad-sector error to the NTFS file system, NTFS dynamically replaces the cluster disk containing the bad sector and allocates a new disk cluster for the data. If the error occurs during a read, NTFS returns a read error to the calling program, and the data is lost (unless protected by RAID fault tolerance). When the error occurs during a write, NTFS writes the data to the new disk cluster, and no data is lost. NTFS puts the address of the disk cluster containing the bad sector in its Bad Sector file so that the bad sector is not reused.

Even with transaction logging and recovery and disk cluster-remapping, user data can be lost due to hardware failure if you do not use a fault-tolerant-disk solution.


Optimizing your clusters

Because Cluster service uses an adaptable architecture, it is largely self-tuning; that is, it is able to allocate resources as needed to meet changing usage requirements. However, there are some hardware and configuration choices you can make to improve cluster performance. These choices are explained in the following sections:

  • Focusing on the right hardware resources
  • Optimizing the paging file size and location
  • Using additional TCP/IP services


Focusing on the right hardware resources

The goal in tuning the Cluster service and hosted applications is to determine which hardware resource will experience the greatest demand, and then to adjust the configuration to relieve that demand and maximize total throughput. A system should be structured so that its resources are used efficiently.

For example, if the primary role of the cluster is to provide high availability of file and print services, high disk use will be incurred due to the large number of files being opened and closed. File and print services also cause a heavy load on network adapters because of the large amount of data that is being transferred. It is important to make sure that your network adapter can handle the load. In this scenario, memory typically does not carry a heavy load (although memory usage can be heavy if a large amount of system memory is allocated to file-system cache). Processor utilization is also typically low in this environment. In such cases, memory and processor utilization usually do not need the optimizing that other components need.

In contrast, a server-application environment (such as one running Microsoft SQL Server, Microsoft Exchange Server, Microsoft Systems Management Server, and Microsoft SNA Server) is much more processor- and memory-bound than a typical file-and-print-server environment because much more processing is taking place at the server. In these cases, it is best to use high-end multiprocessor computers. The disk and network loads tend to be less utilized, because the amount of data being sent over the wire and to the disk is smaller. The Cluster service itself uses little of the system resources either for intracluster communications or for the operation of the cluster itself.


Optimizing the paging file size and location

The location and size of the paging files can greatly affect performance. Paging files cannot be located on the shared bus, but if multiple unshared drives are available on the individual servers, placing the paging file on a separate, fast, low-use drive can boost performance. The size setting of the paging file is also critical to performance. A paging file that must constantly expand and shrink requires additional processor and I/O overhead. Usually, set the size of your paging file at two or two-and-a-half times the amount of installed physical memory if active applications, such as Microsoft SQL Server or Microsoft Exchange Server, are present.


Using additional TCP/IP services

WINS, DHCP, and DNS Services use additional system resources, which you must consider before implementing any of these services on a cluster. In particular, WINS can require substantial overhead during peak logging on times in large networks. In such cases, make sure that your system has the necessary capacity to perform adequately.

Important

  • DNS is not clustered, but the node acts as the server of the service. If you run DNS on a node of a cluster, make sure to implement backup servers to provide redundancy, just as you would normally do on your network.


Using server clusters

This section provides information on how to use a server cluster to provide high availability application support.

  • Server cluster rules
  • Applying administrative procedures to server clusters
  • Cluster automation interface
  • General drive configuration tips for server clusters
  • Server cluster back up and restore
  • Uninstalling a server cluster
  • Cluster hardware configuration
  • Standard resource types
  • Managing security in a cluster
  • Using Cluster Administrator
  • Setting properties
  • Network management
  • Cluster commands overview


Server cluster rules

Following these rules will help you solve the most common problems associated with clusters.

  • Windows 2000 Advanced Server must be installed on each node.
  • All nodes of the cluster must belong to the same Microsoft Windows domain, see Choosing a domain model.
  • When you install the Cluster service, you must be logged on to the domain that has administrative permissions on all nodes.
  • Each cluster node can belong to only one cluster.
  • The shared drive must be formatted using the NTFS file system.
  • Do not change the Windows 2000 computer name of a cluster node after installing the Cluster service.
  • Do not repartition disks on the shared bus without first deleting the corresponding disk resources. After changing the partition layout of a disk on the shared bus, restart all cluster nodes.
  • If you start the node using an operating system other than Windows 2000, do not run any diagnostic tools that make low-level writes to a physical disk.
  • Do not reassign the drive letters of the system disks on the nodes.
  • Allow only one node to access the cluster disk at any time.
  • Verify that either WINS or DNS Services are available to all nodes.
  • Verify that TCP/IP is installed on all nodes and clients.
  • Verify that all cluster nodes can detect one another over the network. Use the TCP/IP Ping utility or the Windows 2000 net view command.
  • Check all event logs on all affected computers for error messages.


Applying administrative procedures to server clusters

Typically, an administrator will follow a set of server operating procedures when performing administrative tasks on a server, such as restarting a server, backing up applications and data, and installing new hardware or software. These operating procedures should be reexamined and some will have to be modified in a server cluster environment.

Reexamining procedures that take a server cluster offline

Because you install the Cluster service on more than one computer, the tasks of administering servers and performing common server operating procedures are less disruptive to users. There are some administrative tasks that make a server unavailable to users. A server cluster, however, has another node that can continue to make the server resources available to users while you are performing administrative tasks. Therefore, you might not have to wait for nonpeak hours, when:

  • A server must be restarted.
  • New hardware must be installed.
  • New software must be installed.

Reexamining backups on a server cluster

Your backup procedures should be modified to account for clustering issues. In a server cluster, you should back up the following items:

  • The operating-system installation on each node in the cluster.
  • Data on the shared SCSI bus drives.
  • Data on local drives on each node.

Backing up and restoring cluster nodes is no different from backing up other installations of Windows Server: use Windows 2000 Backup to back up system state data (operating system loader, system drives, and the registry). Also, use Rdisk.exe to keep a current emergency repair disk (ERD) for both nodes.

For more information on using the Windows 2000 Backup and Recovery Tools wizard to perform a back up and restore of a cluster node, see Server cluster back up and restore.

For more information about replacing hardware, see Installing new SCSI hardware. For more information on restoring Windows 2000 after replacing hardware, see Resources.

You can backup the data on the shared SCSI bus drives from the node that owns the disk resource you want to back up. You can also back up this data from a remote computer through a network connection to a hidden administrative share. For example, you might use the New Resource wizard to create FBackup$, GBackup$, and HBackup$ file shares for the root of drives F, G, and H, respectively. These shares would not appear in the Windows 2000 browse list and could be configured to allow access only to members of the Backup Operators group.


Cluster automation interface

The Cluster Automation Interface is a Component Object Model (COM) interface to the Cluster API. You can use the Cluster Automation Interface with the Windows Script Host (WSH) to automate many administrative tasks.

For more information on the Cluster API, see the Microsoft Platform Software Development Kit (SDK).


General drive configuration tips for server clusters

Before adding or removing hardware from a server cluster, make sure the drive letter assigned to the Windows 2000 system partition (typically C or D) is fixed. The drive letter assignment must remain constant because references to this drive letter are recorded in the Windows 2000 registry, and your server cluster is affected by these references.

By default, Windows 2000 reassigns drive letters at startup, based on the order in which disks are discovered and on the disk partitioning. (Primary partitions are assigned first, followed by all secondary partitions.)

The following events can cause Windows 2000 to change drive letter assignments at startup if the drive letters are not fixed:

  • Adding disks after Windows 2000 Advanced Server is installed, such as when you install server cluster software
  • Adding, removing, or rearranging SCSI bus adapters on systems that have more than one adapter
  • Installing a new version of an adapter driver that changes the starting order of the drivers

If your system drive letter changes, you may be able to correct the problem by assigning a fixed drive letter in the Windows 2000 Disk Administrator.


Server cluster back up and restore

You can use the Windows 2000 Backup and Recovery Tools wizard to perform back up and restore of cluster nodes.

For more information on Windows 2000 backup and restore procedures, see Backing up files and folders.

Backing up data on a server cluster node

Use the Backup wizard to perform a backup of a cluster node where the Cluster service is operational. On the What to Back Up page of the wizard, select Back up everything on my computer or Only back up the System State data.

  • Back up everything on my computer. This option will back up everything on a cluster node. The backup will include the clustering software, cluster administrative software, the quorum resource's recovery log which contains the most recent cluster database information, any resource registry checkpoints, and system state data. For more information on the quorum resource, see Quorum resource.
  • Only back up the System State data. This option will back up only the quorum resource's recovery log which contains the most recent cluster database information, any resource registry checkpoints, and system state data.

These options invoke the BackupClusterDatabase API which ensures that a consistent snapshot of the cluster database is saved. For more information on the BackupClusterDatabase API, see the Microsoft Platform Software Development Kit (SDK).

Performing a back up of a cluster node using these options will back up the quorum resource's recovery log regardless of which cluster node controls the quorum resource.

To back up all cluster disks owned by a node, perform the back up from that node.

Important

  • Do not back up the quorum resource's recovery log using the Back up selected files, drives, or network data option on the What to Back Up page of the wizard. This option does not use the BackupClusterDatabase API.

Backing up data on remaining cluster nodes

After backing up the quorum resource's recovery log on one node, it is not necessary to back up the quorum log on the remaining cluster nodes. You do need to back up the %windir%\cluster\CLUSDB file on the remaining nodes while performing a back up of the first node. You can also back up the clustering software, cluster administrative software, system state data, and other cluster disks on the remaining cluster nodes.

First stop the Cluster service on a cluster node. You should then select Back up everything on my computer or Back up selected files, drives, or network data on the What to Back Up page of the Backup wizard.

For information on how to stop and start the Cluster service, see To stop the Cluster service and To start the Cluster service.

Restoring data on a server cluster node

You can run the Restore wizard to restore the quorum resource recovery log, any resource registry checkpoints, the CLUSDB file, and any clustering software on a node.

The Restore wizard uses the cluster API RestoreClusterDatabase to restore the cluster database to the quorum drive. The functions performed by the RestoreClusterDatabase API are:

  1. Stop the Cluster service on all cluster nodes if the Cluster service is running.
  2. Restore the signature of the quorum disk if the signature of the quorum disk has changed since back up time.
  3. Restore the cluster database and any resource registry checkpoints onto the quorum disk.
  4. Restart the Cluster service on the restoring node.

You can then restore another cluster node using the Restore wizard and restart the Cluster service on that node. Once the CLUSDB file has been restored on the restoring node and all clustering software restored by the Restore wizard, the restoring node can join the first node.

For more information on the RestoreClusterDatabase API, see the Microsoft Platform Software Development Kit (SDK). For information on how to perform back ups and restores, see To back up files to a file or a tape and To restore files from a file or a tape.

Notes

  • The Windows 2000 Backup and Recovery Tools wizard is available only to server clusters where all nodes are running Windows 2000 Advanced Server.
  • The Restore wizard does not restore disk signatures or the partition layout of nonquorum cluster disks. If a nonquorum cluster disk changes after the back up time, the corresponding disk resources may fail to come online after a restore when the Cluster service attempts to bring them online.
  • The Restore wizard will attempt to restore the disk signature of the quorum disk, but will not restore the partition layout of the quorum disk. This is so the Cluster service may recognize a newly replaced quorum disk after a restore.


Uninstalling a server cluster

You can uninstall a node of a server cluster at any time. Before uninstalling a node, you should take all groups offline or move them to the other node. You should also close Cluster Administrator.

For instructions on how to uninstall the Cluster service, see To uninstall the Cluster service.


Cluster hardware configuration

This section covers:

  • Fibre Channel hardware configuration
  • SCSI hardware configuration
  • Network configuration in a server cluster


Fibre Channel hardware configuration

If you choose to use Fibre Channel to connect to your cluster storage, you should know the following:

  • The Fibre Channel systems are listed in a separate section of the Hardware Compatibility List on the Microsoft Web site.(http://www.microsoft.com/) Search for Cluster/FibreChannel Adapter.
  • Windows 2000 will manage your Fibre Channel disks just like any other disk connected to a SCSI bus.
  • Unlike SCSI, the Fibre Channel controller ID is pre configured with a unique ID. This simplifies your hardware setup because you do not need to manually configure each cluster node with a separate ID.
  • Fibre Channel storage solutions do not have the bus termination problems that you can experience in a SCSI cluster. For more information on terminating a shared SCSI bus, see Terminating a shared SCSI bus.

The figure shows a Fibre Channel cluster with a fiber switch or hub. Fiber optic cable runs between a node's Fibre Channel controller and the fiber switch or hub. The device bus between the switch or hub may be fiber or SCSI. Check the Hardware Compatibility List at the Microsoft Web site for your storage device's connection.

Fibre Channel Cluster


SCSI hardware configuration

This section covers:

  • SCSI concepts and terminology
  • Terminating a shared SCSI bus
  • Installing new SCSI hardware
  • Plug and Play disk support


SCSI concepts and terminology

In this documentation, the term shared SCSI bus refers to the total interconnect between the server systems and the cluster storage. In practice, the shared bus typically consists of multiple bus segments, each of which is an electrically complete bus.

Transmission types and type combinations

Devices on a SCSI bus use one of two transmission methods:

  • Single-ended

    • Devices using single-ended transmission establish a signal connection, using one data lead and one ground lead. Although this method is generally less expensive, it is prone to noise problems and requires strict adherence to maximum cable lengths.

  • Differential

    • Devices using differential transmission establish a signal connection such that neither lead is at ground potential. Because this effectively cancels noise on the bus, you can use longer cables and faster bus speeds. However, it is generally more expensive to implement than single-ended transmission.

In general, you should connect single-ended devices to single-ended buses and differential devices to differential buses. If you want to put a device on a bus that uses a different transmission method, you must use a signal converter.

Important

  • Do not connect single-ended and differential devices together unless you connect them through a signal converter. Attempting to connect them without a signal converter can damage your hardware.

Termination of the SCSI Bus

Each physical SCSI bus must be terminated only at the ends of the bus. Some devices and adapters include internal termination that you must remove if the device is not at the end of the bus. Your cluster works best if you remove all internal bus termination and use either Y-cables or trilink connectors to implement external bus termination. This allows the device to be removed for maintenance without affecting the rest of the devices on the bus. These rules also apply to the individual bus segments within the shared SCSI bus.

For more detailed information on terminating a SCSI bus, see Terminating a shared SCSI bus.


Terminating a shared SCSI bus

You must terminate the shared SCSI bus and connecting cables as described in this topic. Each SCSI bus segment must have exactly two points of termination, and these points must be located at the two ends of the segment. If you overlook any of these requirements, the bus may not operate properly in a server cluster.

Terminating a bus segment

There are a number of ways to terminate a bus segment. The following explains the ways that work best for server clusters.

  • SCSI adapters

    • Although SCSI adapters have internal termination that you can use to terminate the bus, this method is not recommended. If the server becomes disconnected from the shared bus in this type of setup, the bus will not be properly terminated and will be inoperable.

  • Storage enclosures

    • You can use the internal termination of a storage enclosure to terminate the bus if the enclosure is at the end of the bus.

  • Y cables

    • You can connect Y cables to some devices. If the device is at the end of the bus, you can attach a terminator to one branch of a Y cable to terminate the bus. To use this method of termination, you must remove or disable the internal terminators in the device.

  • Trilink connectors

    • You can connect trilink connectors to certain devices. If the device is at the end of the bus, you can attach a terminator to one of the trilink connectors to terminate the bus. To use this method of termination, you must remove or disable the internal terminators in the device.

Y cables or trilink connectors are recommended for terminating the bus. Besides providing termination, Y cables and trilink connectors give you a way to isolate systems and storage enclosures from the shared bus without affecting the bus termination. This allows your shared bus to operate while you perform maintenance on a device or change the configuration. If your device is not at the end of the shared bus, you must disable the internal termination of the device.

Terminating a shared bus with a middle storage enclosure

The first diagram shows a configuration with a system at each end of the bus and the storage enclosure in the middle. A Y cable is attached to the unterminated port of each host bus adapter. The bus is terminated by terminators attached to each Y cable. The internal termination of the storage enclosure is disabled.

Middle storage enclosure

If you disconnect one of the Y cables from the adapter port (as shown in the second diagram), the shared bus is still properly terminated. Although the disconnected server is no longer available, the cluster can still operate with the remaining server.

There is no Y cable at the storage enclosure in the configuration shown in the second diagram. If the cluster storage is disconnected, the bus becomes inoperable. If you have more than one storage enclosure on the bus, use a Y cable or a trilink connector to connect each enclosure to the bus. This allows the bus to remain operable if one of the enclosures is disconnected.

Properly terminated, shared SCSI bus with disconnected Y cable


Installing new SCSI hardware

After your server cluster is up and running, you will probably need to add new hardware in the future. For example, you may need to:

  • Install an additional SCSI bus in one of the nodes to support a tape device or SCSI drives for local (unshared) storage.

    • For more information on how to install a new local SCSI bus on a cluster node, see To install local SCSI buses and devices.

  • Install additional SCSI drives on the existing local SCSI bus on one of the nodes.
  • Install additional drives on the shared SCSI bus.

    • For information on how to add a drive on a shared SCSI bus, see To add drives on the shared SCSI bus.

  • Replace failed drives on the shared SCSI bus.
  • Install an additional shared SCSI bus between the two nodes.

Following the specific procedures to perform each of these tasks prevents SCSI conflicts that can affect the operation of either node in the cluster.

For more information on how to install a new shared bus, see To install an additional shared SCSI bus.


Plug and Play disk support

The Cluster service uses the Plug and Play feature of Windows 2000 to detect new cluster physical disks. If the Cluster service finds a new cluster physical disk, the disk immediately appears on the Cluster Administrator list of available disks. You can then use that physical disk in cluster resource groups.

If you remove a cluster physical disk while the Cluster service is running, it does not automatically delete the Physical Disk resource and its dependent resources. Instead, it treats the removal of the physical disk as a disk failure. You must use Cluster Administrator to manually remove the resource and all dependent resources.


Network configuration in a server cluster

This section covers:

  • Configuring cluster network hardware
  • Private network addressing options


Configuring cluster network hardware

Choosing network hardware

The nodes of a cluster must be connected by one or more physically independent networks (sometimes referred to as interconnects). Each cluster network interface must be on a PCI bus. Although your server cluster can function with only one interconnect, two interconnects are strongly recommended; two interconnects eliminate any single point of failure that could disrupt communication between nodes.

Before you install the Cluster service, you must configure both nodes to use the TCP/IP protocol over all interconnects. Each network adapter must have an assigned IP address that is on the same network as the corresponding network adapter on the other node. Therefore, there can be no routers between two cluster nodes. However, routers can be placed between the cluster and its clients. If all interconnects must run through a hub, use separate hubs to isolate each interconnect.

Network roles

You must configure each cluster network to have one of four roles. Each network can support:

  • Only node-to-node communication
  • Only client-to-cluster communication
  • Both node-to-node communication and client-to-cluster communication
  • No cluster-related communication

Networks that support only node-to-node communication are referred to as private networks. Networks that support client-to-cluster communication (either with or without supporting node-to-node communication) are known as public networks. For more information on networks and network roles, see Server cluster networks.

Windows 2000 supports the use of DHCP addresses as private node addresses (you configure private node addresses through the Network and Dial-up Connections folder, not through cluster software). The Cluster service uses the Plug and Play network support to handle the events that occur when a DHCP-allocated IP address changes.

However, using short-term DHCP leases for a private node address has some disadvantages. First, when the address lease expires for a network, the node cannot communicate over that network until it obtains a new address. This makes the node's availability dependent on the availability of the DHCP server; the node cannot communicate over the network until it obtains its address from the DHCP server. Second, if an address lease expires on a network configured for public communication (communication between cluster nodes and clients), it may trigger failover for resource groups that used an IP Address resource on that network.

If possible, use either static IP addresses or a permanently leased DHCP address for private node addresses.

The Cluster service does not support the use of IP addresses assigned from a DHCP server for the cluster administration address (which is associated with the cluster name) or any IP Address resources.

Installing the Cluster service on computers with logically multihomed adapters

A logically multihomed adapter is one that has two IP addresses assigned to it. These adapters can be used only for node-to-node cluster communication if their primary addresses are on the same IP Subnet. If the primary addresses on both nodes are not on the same IP Subnet, reorder the IP addresses assigned to the adapter by using the Network and Dial-up Connections folder.

For information on choosing IP addresses for private networks, see Private network addressing options.


Private network addressing options

If an interconnect connects only the cluster nodes and does not support any other network clients, you can assign it a private IP network address instead of using one of your enterprise's official IP network addresses.

By agreement with the Internet Assigned Numbers Authority (IANA), several IP networks are always left available for private use within an enterprise. These reserved numbers are:

  • 10.0.0.0 through 10.255.255.255 (Class A)
  • 172.16.0.0 through 172.31.255.255 (Class B)
  • 192.168.0.0 through 192.168.255.255 (Class C)

You can use any of these networks or one of their subnets to configure a private interconnect for a cluster. For example, address 10.0.0.1 can be assigned to the first node with a subnet mask of 255.0.0.0. Address 10.0.0.2 can be assigned to the second node. No default gateway or WINS servers should be specified for this network.

Ask your network administrator which of the private networks or subnets you may use within your enterprise before configuring your cluster.

These private network addresses should never be routed. For more information on private IP network addresses, see Resources.


Standard resource types

Windows 2000 comes with numerous resource types to let you manage cluster resources.

Internet Information Services (IIS) can be installed on a server cluster. For more information on IIS Server Instance resource type and how IIS runs on a server cluster, view the IIS online documentation. If you have IIS installed, the IIS online documentation is available by typing the following in your browser address bar and pressing ENTER:

http://localhost/iisHelp/iis/misc/default.asp?jumpurl=..\htm\core\iicluswl.htm

You can install Message Queuing on a server cluster. For more information on Message Queuing Server resource type and how it runs on a server cluster, see Message Queuing.

You can install Distributed Transaction Coordinator (DTC) on a server cluster. For more information on Distributed Transaction Coordinator resource type and how it runs on a server cluster, see MS DTC Transaction Manager on a Windows 2000 server cluster.

Time Service and IIS Virtual Root resource types support rolling upgrades. For more information on rolling upgrades, see Installation and upgrading of cluster nodes.

Other resource types are Simple Mail Transfer Protocol (SMTP) Server Instance and Network News Transport Protocol (NNTP) Server Instance.

This section also covers the following resource types and topics:

  • Physical Disk resource type
  • DHCP and WINS resource types
  • Print Spooler resource type
  • File Share resource type
  • Internet Protocol resource type
  • Network Name resource type
  • Generic Application resource type
  • Generic Service resource type
  • Using a server cluster with large numbers of file shares


Physical Disk resource type

You use the Physical Disk resource type to manage disks that are on a cluster storage device.

Disks have the same drive letters on all cluster nodes.

To prevent data corruption, it is important that only one node at a time use a cluster disk. Normally, the Cluster service prevents more than one node from using a disk at the same time. However, there are two circumstances in which the ordinary cluster safeguards do not work: when you install a new disk, and when you remove a disk from a cluster.

For information on replacing disks in a server cluster, see Updated technical information.


DHCP and WINS resource types

Dynamic Host Configuration Protocol (DHCP) and Windows Internet Name Service (WINS) provide network services to clients. DHCP leases IP addresses to clients. This lets you centrally manage IP addresses and related configuration details. For more information on DHCP, see DHCP. WINS provides a dynamic database service that can register and resolve NetBIOS names to IP addresses used on your network. For more information on WINS, see WINS.

Windows 2000 Advanced Server provides resource types that allow you to manage DHCP and WINS services in a cluster. Each of these resources stores a database on disk. In order for these resources to fail over, the database must be kept on a disk that is on cluster storage.

You must configure a location for the DHCP and WINS database files and for the backup of these files.

The path to the DHCP or WINS database files and backup of these files must:

  • End with a back slash (\).
  • Use a drive letter of a disk resource on which the DHCP or WINS resource depends.
  • Cannot begin with %SystemRoot%, but you can use other environment variables.

The path for the DHCP or WINS database will be of the form f:\dhcp or f:\wins.

The path to the backup of the DHCP database files will be of the form f:\dhcp\backup.

For WINS, you provide a root path, and the backup of the WINS database files is created in a subdirectory of this path. The path will be of the form f:\wins.


Print Spooler resource type

You use the Print Spooler resource to cluster your print services. You can only cluster a printer that is connected to your servers via a network. If the printer is connected via a local port, such as LPT1:, there is no way to fail over control of that printer should the server that it is connected to fail.

You cluster print services using the Print Spooler resource. Multiple Print Spooler resources can exist in a cluster, but there can be no more than one Print Spooler resource per group. Clients access clustered printers in exactly the same way they access nonclustered printers. Clients can use either the network name or IP address as the server name.

When a group containing a Print Spooler resource fails over to another node, the document that is currently being spooled to the printer is restarted from the other node after failover. When you move a Print Spooler resource or take it offline, the Cluster service waits until all jobs that are spooling to the printers are finished (or until the configured wait time has elapsed). Documents that are spooling from an application to a Print Spooler resource are discarded and must be respooled (or reprinted) to the Print Spooler resource if the group containing the Print Spooler resource fails over before the application has finished spooling.

In addition to creating a Print Spooler resource, you must properly configure your printer ports and printer drivers to function on a cluster. To properly set up a printer on a cluster, you must install printer drivers on each cluster node and a printer port on the same virtual server as the Print Spooler resource.

For more information on the entire printing process in Windows 2000, see Understanding printing. For detailed instructions on how to configure a printer to operate in a cluster, see To create a cluster-managed printer.


File Share resource type

If you want to use a server cluster to provide a high availability file server, you will need to use the File Share resource type. There are three major ways you can use this resource type.

  1. A basic file share

    2. You can use the File Share resource type to provide a basic file share. Using this method, a single file folder is published to the network under a single name.

  2. Share subdirectories

    3. You can also use the File Share resource to publish several network names: one each for a file folder and all of its immediate subfolders. This is an efficient way to create large numbers of related file shares on a single file server. An example application for this is creating a file share for each user who has files on the server. For more information on why you would want to share subdirectories, see Using a server cluster with large numbers of file shares.

  3. Dfs root

    4. You can use the File Share resource type to create a resource that manages a standalone Dfs root. Fault tolerant DFS roots cannot be managed by this resource. A Dfs root file share resource has required dependencies on a network name and an IP address. The network name can be either the cluster name or any other network name for a virtual server. For more information on Dfs, see Distributed file system.


Internet Protocol resource type

You use the Internet Protocol (IP) resource type to manage IP network addresses as cluster resources. When an IP Address resource is included in a group with a Network Name resource, the group can be accessed by network clients as a virtual server.

For more information on virtual servers, see Virtual servers.


Network Name resource type

You use the Network Name resource type to provide an alternate computer name for an entity that exists on a network. When included in a group with an Internet Protocol (IP) Address resource, a Network Name resource provides an identity to the group, allowing the group to be accessed by network clients as a virtual server.

For more information on virtual servers, see Virtual servers.


Generic Application resource type

You use the Generic Application resource type to manage cluster-unaware applications.

When to use the Generic Application resource type

Not all applications will function effectively in a cluster. The minimum requirements for an cluster-unaware application are:

  • The application must be able to store its data in a configurable location.
  • The application must use TCP/IP to connect with clients.
  • Clients must reconnect in the event of intermittent network failure.

Installing a generic application

If your cluster-unaware application is to work during failover, you must ensure that the application can run from all cluster nodes. There are two strategies for accomplishing this:

  1. Install the application onto a cluster disk. Because all nodes use the same drive letters for cluster disks, this solution guarantees that the application can be started from all nodes using the same command line. The disadvantage to this solution is that you cannot perform rolling upgrades of this application. For more information on rolling upgrades, see Installation and upgrading of cluster nodes.
  2. Install separate copies of the application on all cluster nodes. Make sure that the application is installed in a folder on each node that has the same drive letter and path as all other nodes. While this solution uses more disk space, it is the only way you can install an application that will allow you to perform a rolling upgrade of that application.


Generic Service resource type

You use the Generic Service resource type to manage Windows 2000 services as cluster resources. Similar to the Generic Application resource type, the Generic Service resource type provides only the most basic functionality. For example, the failure of a Generic Service resource is determined by a query of the Windows 2000 Service Controller. If the service is running it is presumed to be online. To provide greater functionality, you can define a custom resource type. For more information on how to create a custom resource type, see the Microsoft Platform Software Development Kit (SDK).


Using a server cluster with large numbers of file shares

Every cluster resource you create has a performance impact; the Cluster service must periodically poll all resources to determine if they have failed. Because of this, you may notice that your cluster's performance decreases as you increase the number of resources that it manages.

If you want to use a cluster to create a high availability file server that will have hundreds of file shares, you should consider managing those file shares using a single File Share resource. You can do this if the folders that you want to share on the network are all subfolders of a common folder. For example, if you use your file server to support hundreds of users, and each user has a private folder that is a subfolder of the Users folder, you can manage individual file shares for each user using a single File Share resource. You also have the option to hide the file shares that you create for each user. For information on how to do this, see To share the subfolders of a folder.

For more information on how the Cluster service checks for failed resources, see Resource failure.


Managing security in a cluster

The Cluster service relies on Windows 2000 security at all levels for securing communication between nodes, joining nodes, and controlling authentication and access, including client access to the cluster and shared resources. You can use Cluster Administrator to specify which users or groups can:

  • Administer the cluster
  • Access files or folders on File Share resources

For information on how to change the account or the password for the Cluster service, see To change the account under which the Cluster service runs and To change the Cluster service account password.

This section covers common security tasks:

  • Limiting client access to cluster resources
  • Securing shared data in a cluster
  • Domain accounts and the Cluster service
  • Disk resource security


Limiting client access to cluster resources

The following table lists the Windows 2000 security features you can use to control client access to cluster resources.

Important

  • In general, set permissions on the individual applications and services as you would normally. However, you should always use Cluster Administrator to set File Share resource security policies. File Share security policies configured using Windows Explorer are lost when the File Share resource fails over.
Resource type | Windows 2000 security
DHCP Service | Controlled by DHCP
File Share | NTFS share-level security configured with a cluster management application
Generic Application | Windows 2000 network authentication and NTFS security applied to the shared file system
Generic Service | Determined by Windows 2000 service configuration
IIS Server Instance | Windows 2000 network, IIS, and NTFS file-level security
IP Address | N/A
Distributed Transaction Coordinator | Controlled by MS DTC
Message Queue Service | Controlled by Message Queue Service
Network Name | N/A
Physical Disk | NTFS file-level security
Print Spooler | Windows 2000 Network and print-level permissions
WINS | Standard WINS security


Securing shared data in a cluster

Limiting access to shared data

Use Cluster Administrator and standard Windows 2000 security to limit access to files and folders that reside on drives on the cluster storage device.

When setting access permission on nodes, do not specify permissions based on local user or local group accounts. On member servers, local users and local groups have security context only on the local computer. The security context of these accounts and groups is meaningless when failed from one node to another. For this reason, you cannot give local users or local groups permissions to administer the cluster. The single exception to this rule is the local Administrator group. This is not a problem on domain controllers because the local accounts and groups have security context on all domain controllers in the domain.

Important

  • If you change share permissions using Windows Explorer or My Computer instead of using Permissions on the Parameters tab in Cluster Administrator, the permissions are lost when the resource is taken offline.

Auditing access to shared data

Use standard Windows 2000 security to audit access to files and folders that reside on drives on the cluster storage. Use either My Computer or Windows Explorer to set file or directory auditing. You cannot do this using Cluster Administrator. For more information on auditing, see Auditing security events.

Security events are written to the security log on the node that owns the File Share resource.

Audit settings are specific to a node. Therefore, if you enable auditing on one node but not another, you only see security events when the node with auditing enabled owns the File Share resource. If you want to audit access to shared data, it is a best practice to enable auditing on all cluster nodes.

Taking ownership of files or folders

Use either My Computer or Windows Explorer to set file or directory ownership. You cannot do this using Cluster Administrator.


Domain accounts and the Cluster service

Prior to installing the Cluster service on each node, you must log on to the node using an account that is part of an Administrators group. Both nodes must have computer accounts on the domain and be members of the same domain (instead of a workgroup). When you install the Cluster service, you specify the domain user account under which the Cluster service runs. It is best if the Cluster service user account is a new account. The account must have local administrative privileges on the cluster nodes. Be sure to keep the password from expiring on the account (follow your ogranization's policies for password renewal).

When you install the Cluster service on a member server, Setup gives cluster administrative permissions to the local Administrators group. When you install the Cluster service on a domain controller, Setup gives cluster-administrative permissions to the Domain Administrators group.

When you administer a cluster from a remote location, such as from another server or a computer running Windows 2000 Professional, you must also have administrative permissions on both nodes of the cluster, or you must have specific permissions to administer the cluster. By default, the local Administrators group on both nodes has permission to administer the cluster. To give permission to administer the cluster from domain accounts that do not belong to the Administrators group on both nodes, see To give a user permissions to administer a cluster.

If you have administrative permissions on both nodes of the cluster, you can fully administer the cluster. However, if you have only specific permissions to administer the cluster, you cannot change the cluster description, change cluster security, or register extensions to Cluster Administrator.

For information on changing the account used to run the Cluster service, see Securing shared data in a cluster.


Disk resource security

Two disk subsystems exist in a clustered environment: those relevant to the shared bus and those that support Windows 2000. These two systems should be kept separate. Do not put Windows 2000 system files on the shared bus. The Windows 2000 system files can reside on either FAT or NTFS drives, but the shared bus must contain only NTFS-formatted drives.

All standard Windows 2000 file-security options apply to the disk resources on the shared bus. You can control access to folders and files of File Share resources on a user or group basis. You must set access to File Share resources through Cluster Administrator. Any changes you make to the security policy of a File Share resource using a noncluster tool such as Windows Explorer will be lost the first time the File Share resource fails over.

Important

  • The Cluster service must always have full access to the folder on the quorum disk containing the quorum log (the folder is named MSCS by default). (The quorum log file is used to write all cluster state and configuration changes that cannot be committed to the other node.)


Using Cluster Administrator

Cluster Administrator shows you information about the groups and resources on all of your clusters and specific information about the clusters themselves. A copy of Cluster Administrator is automatically installed on a cluster node when you install the Cluster service. For remote administration, you can install copies of Cluster Administrator, through Windows 2000 Administration Tools, included on the Windows 2000 Server and Windows 2000 Advanced Server compact disc sets, on other computers on your network running Windows 2000. The remote and local copies of Cluster Administrator will be identical. It is also possible to administer a Windows 2000 server cluster remotely from a computer running Windows NT 4.0 Service Pack 3 or later using the Windows NT Server, Enterprise Edition 4.0, Cluster Administrator tool.

This section describes the uses of Cluster Administrator, including the ways in which it changes procedures you might have been familiar with in a noncluster environment.

  • Identifying failovers
  • Connecting to a cluster
  • Viewing the default groups in Cluster Administrator
  • Installing Cluster Administrator on a remote computer
  • Using the cluster application configuration wizard


Identifying failovers

Failover can occur in one of two situations: an entire node fails, or a resource on a node fails (such as a network interface). Node failure is easily identifiable in Cluster Administrator. When you are connected to a cluster, Cluster Administrator displays a list of all nodes and their current status. Resource failure that does not bring down a node, but results in group failover can be harder to detect. You should use Cluster Administrator, or another cluster management application, to periodically check the owner of all cluster groups to see if a group has failed over.

It is important to use Cluster Administrator to routinely monitor the status of all clusters and check for failover activities that diminish either the performance or the availability of resources. Failover should be easily tolerated. Your work flow should not suffer if all applications are working, failover policies have been correctly set, and you have provided sufficient capacity for all situations. If any of these three criteria are not met, you must take action to meet them. For information on how to plan your server cluster, failover policies, and capacity requirements, see Planning your server cluster.

Serious failover situations can affect performance and availability. If a node fails and its companion node is unable to serve clients efficiently, the situation must be resolved immediately. If groups persistently fail over and fail back without surviving on either node for very long, availability to clients is completely lost.

Responding to a failover

When investigating possible problems with failovers, answer the following questions:

  • How serious is the problem?

    • For example, other resources could be suffering due to the increased load placed on the alternate node.

  • What caused the failover?

    • Many types of failure can cause failovers. Usually, these occur at the operating-system and hardware levels. For help with determining the exact type of a failure, see Troubleshooting.

    To review what happened prior to and during a group failure, run Windows 2000 Event Viewer and look at the Application log, System log, and the Security log (if applicable). This helps you determine what types of errors occurred.

  • Are any changes needed to prevent this kind of event in the future?

    • If your performance has seriously suffered as a result of a failover, review the capacity planning issues presented in Capacity planning.

    If you determine that the nodes did not efficiently transfer control of various groups and resources during failover, review the failover policies you have set. For example, the Cluster service could be attempting to bring a File Share resource online before the corresponding Physical Disk resource was brought online. This type of error is easily fixed by configuring dependencies.

For more information about diagnosing and resolving specific kinds of failures and errors, see Troubleshooting. For more information on resource dependencies, see Groups.

For information on how to solve failover problems, see Troubleshooting.


Connecting to a cluster

You can connect to a cluster using the network name or the IP address of either the cluster itself or one of its nodes. You can also simultaneously connect to multiple clusters.

When you start Cluster Administrator, any connections you left open at the end of your most recent Cluster Administrator session are automatically restored. If this is your first session, Cluster Administrator prompts you to enter a cluster name, a node, or an IP address to which to connect before it displays any information. Click Browse to view all the clusters in the same domain as the computer that is running Cluster Administrator.

If you do not want Cluster Administrator to restore previous cluster connections, specify /noreconnect on the command line.

For more information on how to connect to a cluster, see To connect to a cluster with Cluster Administrator .


Viewing the default groups in Cluster Administrator

Every new cluster includes two types of default resource groups: Cluster Group and Disk Group. These groups contain the settings for the default cluster and some typical resources that provide generic information and failover policies.

  • Cluster Group

    • The default Cluster Group contains an IP Address resource and a Network Name resource. This group is essential for connectivity to the cluster. When you install the Cluster service and form a new cluster, the IP address and cluster name that you enter during the setup process become the IP address and network name of the Cluster Group.

  • Disk Group

    • One Disk Group is created for each disk resource on the cluster storage device. A Physical Disk resource is included in each group.

Do not delete or rename the Cluster Group. Instead, model your new groups on the Cluster Group by modifying the Disk Groups. For example, you might add an IP Address resource, Network Name resource, and IIS Virtual Root resource to Disk Group 1 and then rename the group, Web Group.


Installing Cluster Administrator on a remote computer

You can use Cluster Administrator to remotely administer a server cluster. Cluster Administrator runs on any computer that is running Windows NT 4.0 Service Pack 3 or later and Windows 2000.

You use Windows 2000 Administration Tools to install Cluster Administrator on computers running Windows 2000 that are not cluster nodes. On cluster nodes, Cluster Administrator is installed when you install the Cluster service. For more information on Windows 2000 Administration Tools, see Managing servers remotely.

You cannot use Windows 2000 Administration Tools to install Cluster Administrator on a computer running Windows NT 4.0. However, if you have the version of Cluster Administrator that was provided with Windows NT Server, Enterprise Edition 4.0, you can use that version from any Windows NT 4.0, Service Pack 3 or later computer to administer a cluster running Windows 2000 Advanced Server. Since Windows 2000 Advanced Server provides resource types that were not supported in Windows NT 4.0, you might see error messages if you administer a cluster running Windows 2000 Advanced Server from a computer running Windows NT 4.0.


Using the cluster application configuration wizard

In Cluster Administrator, you can use the new Cluster Application wizard to configure applications to run on a cluster. The Cluster Application wizard leads you through all of the steps required to run an application on a cluster, including creating a virtual server to host the application, creating dependencies between resources, setting failover and failback policies, and so forth. Before running the Cluster Application wizard, make sure that you have all of the information required to complete the wizard. Use the following table to prepare to run the wizard.

Information required | What it is used for
IP address | To create a new virtual server for your application, you need an IP address. You do not need an IP address if your application runs in an existing virtual server.
Virtual server resource group | Your clients will access your application through a virtual server: a cluster resource group with an IP address and a network name. Using the wizard, you can create a new resource group for a virtual server, use an existing resource group, or use an existing virtual server.
Resource type for your application | You can create a resource to manage your application using the wizard. You need to know the resource type for the resource.
Application resource name | If you use the wizard to create a resource for your application, you must name the resource.
Application resource dependencies | If the application requires other resources to run, you can create resource dependencies using the wizard.

For instructions on how to start the Cluster Application wizard, see To start the Cluster Application wizard.


Setting properties

After setting up your cluster, you may need to change the configuration of some resources and groups from time to time. To make changes to a selected group or resource, from the File menu, click Properties.

For detailed procedures on setting properties for groups, resources, networks, and network interfaces, see How to.

This section covers:

  • Setting group properties
  • Setting resource properties
  • Setting network properties
  • Setting network interface properties
  • Setting node properties
  • Setting resource type properties


Setting group properties

Using the group Properties dialog box, you can:

  • View the state of the group (whether it is online or offline) and view which node currently owns the group.
  • Change the group name, description, and Preferred owner.
  • Set the failover policy (using the Failover tab).
  • Set the failback policy (using the Failback tab).

Properties of a cluster object should not be updated on multiple nodes simultaneously. For more information on multiple and simultaneous property updates, see the Microsoft Platform Software Development Kit (SDK).

Setting failover policy

Use the Failover tab to set failover policy for the group. You can set the failover threshold and the failover period. The failover threshold is the number of times the group can fail over within the number of hours specified by the failover period. For example, if a group failover threshold is set to 5 and its failover period to 3, then the Cluster service will fail over the group at most five times within a three hour period. The sixth time a resource in the group fails, the Cluster service will leave the resource in the offline state instead of failing over the group. All other resources in the group are unaffected. In this example, if a Network Name resource failed six times in three hours, on the sixth failure the Network Name would be left offline. An IP Address resource, however, can be left online.

Setting failback policy

By default, groups are set not to fail back. Unless you manually configure your group to fail back after failing over, it continues to run on the alternate node after the failed node comes back online.

When you configure a group to automatically fail back to the preferred node, you specify whether you want the group to fail back as soon as the preferred node is available or to fail back only during specific hours that you define. This option is useful if you want the failback to occur after peak business hours or if you want to make sure the preferred node is able to support the group when it does come back online.

The group must be configured to have a preferred owner to fail back. You can specify a preferred owner on the General tab of the group Properties dialog box.

For instructions on how to open the Properties dialog box, see To change the properties of a group.


Setting resource properties

Using the resource Properties dialog box, you can:

  • View or change the resource name.
  • View or change the resource description and possible owners.
  • Specify whether the resource should run in a separate memory space.
  • View the resource type, group ownership, resource state, and which node currently owns the resource.
  • View preexisting dependencies and modify resource dependencies.
  • Specify whether to restart a resource and, if so, what settings to use to restart.
  • Specify how often you want the Cluster service to check whether the resource is in the online state (by setting the Looks Alive and Is Alive polling intervals).
  • Specify the amount of time that a resource in a pending state (Online Pending or Offline Pending) has to resolve its status before the Cluster service puts the resource in Offline or Failed status.
  • Set specific resource parameters.

The General, Dependencies, and Advanced tabs are the same for every resource. Some resource types support additional tabs.

Properties of a cluster object should not be updated on multiple nodes simultaneously. For more information on multiple and simultaneous property updates, see the Microsoft Platform Software Development Kit (SDK).

Setting resource dependencies

The Cluster service uses the dependencies list when bringing resources online and offline. For example, if a group in which a physical disk and a file share are located is brought online, it is futile to try to bring the file share online before bringing the physical disk (on which the file share is located) online. It is important to remember this when you configure resources because the groups function properly only if these dependencies are correctly configured.

The following table shows resources and their dependencies. The resources in the right column must be configured before you create the resource.

Resource | Dependencies (required or recommended)
DHCP Service Physical Disk or other storage class device (on which the files are located)

IP Address (for client access to the DHCP server)
Distributed Transaction Coordinator | Physical Disk or other storage class device
File Share

A file share that is configured as a DFS root has the following dependency:

  • Network Name

A file share that is not DFS has no required dependencies.
Generic Application | Network Name
Generic Service | Network Name
IIS Server Instance IP Address (that you want to correspond to the virtual root)

Physical Disk or other storage class device

Network Name (so that remote clients can access it)
IP Address | None
Message Queuing Physical Disk or other storage class device

Network Name (so that remote clients can access it)
Network Name | IP Address (that you want to correspond to the name)
Physical Disk | None
Print Spooler Physical Disk or other storage class device (on which the spool is located)

Network Name (so that remote clients can access it)
WINS Service | Physical Disk or other storage class device

The New Resource wizard enforces the use of resource dependencies.

Setting advanced resource properties

Use the Advanced tab of the resource Properties dialog box to:

  • Specify whether the Cluster service should attempt to restart a resource or allow the resource to fail.
  • If you want the Cluster service to restart the resource, you must specify whether to affect the group. If you want the group to be failed over when this resource fails, select the Affect the group check box and then enter the values you want in Threshold and Period. These values determine how many times the Cluster service attempts to restart the resource before failover and the amount of time in which the threshold number of restart attempts take place. If the Affect the group check box is not selected, a failure of this resource never causes the group to fail over.
  • Specify how often the Cluster service should make a cursory check (Looks Alive) or in-depth check (Is Alive) to determine if resource is in the online state.
  • Click Use resource type value to use the default number for the resource type.
  • Specify the amount of time that a resource in a pending state (Online Pending or Offline Pending) has to resolve its status before the Cluster service puts the resource in Offline or Failed status.

Setting resource parameters

Most resources have a resource-specific Parameters tab in their Properties dialog box. The following table lists each resource and its configurable parameters.

Resource | Configurable Parameters

DHCP Service

You can enter the path to the DHCP database files and to the backup of the DHCP database files.

You can enter the path to the audit log file stored by the DHCP service.
Distributed Transaction Coordinator | None.
File Share You can set permissions on the share and limit the number of simultaneous users.

You can also set the name of the share (because clients will detect it in their browse or explore lists), set the share comment, and set the path to the shared files.
Generic Application | You can use the Parameters tab in the Generic Application Properties dialog box to specify the application command line, current directory, whether it should use the network name for the computer name, and whether or not it can interact with the desktop.
Generic Service | You can use the Parameters tab for the Generic Service Properties dialog box to specify the service name, startup parameters, and whether it should use the Network Name for the computer name.
IIS Server Instance You can configure which service the server instance will be for. You do this by clicking FTP or WWW.

You can enter the path to the directory disk resource on the shared bus on which the files reside.

You can also configure the alias, which is the name under which the virtual root appears in the particular service.

You can configure the type of permissions users accessing the virtual root have for the WWW and FTP services.
IP Address | You can configure the IP address, subnet mask, and the network parameters for the IP Address resource. You must also specify which cluster network to use.

MSMQ Server

 None.
Network Name | You can configure only the computer name parameter for the Network Name resource.
Physical Disk | You can specify only which drive to use for the Physical Disk resource. You cannot change this after the resource is created.
Print Spooler | You can configure the path to the Print Spooler folder and the job completion time-out for the Print Spooler resource.
WINS Service

You can enter the path to the WINS database files and to the backup of the WINS database files.


Setting network properties

After setting up your cluster, you may need to change the configuration of the networks that support client-to-cluster communication and node-to-node communication. For detailed procedures on setting network properties, see Manage networks.

Using the network Properties dialog box, you can:

  • View or change the network name
  • View or change the network description
  • Enable or disable the network for cluster use. If you enable the network for cluster use, you can specify whether to use the network for only client-to-cluster communication, only node-to-node communication, or both.
  • View the network's state
  • View the network's IP address
  • View the network's address mask

Properties of a cluster object should not be updated on multiple nodes simultaneously. For more information on multiple and simultaneous property updates, see the Microsoft Platform Software Development Kit (SDK).

Setting network priorities

Cluster nodes can communicate over multiple networks. You can change the network's priority to specify the order in which the nodes will attempt to communicate over the networks. For detailed instructions on changing the network priority, see To change network priority for communication between nodes.


Setting network interface properties

After setting up your cluster, you may need to change the configuration of the network interfaces. For detailed procedures on setting network interface properties, see Manage networks.

Using the network interface Properties dialog box, you can:

  • View the node and network object name
  • View or change the network interface description
  • View the network interface's state
  • View the name of the network adapter for the network interface
  • View the network interface's IP address

Properties of a cluster object should not be updated on multiple nodes simultaneously. For more information on multiple and simultaneous property updates, see the Microsoft Platform Software Development Kit (SDK).


Setting node properties

Using the node Properties dialog box, you can:

  • View the node object name.
  • View or change the node description.
  • View the node's state. A node's state can be:

      Down - The node is not actively participating in cluster operations.

      Joining - The node is in the process of becoming an active participant in the cluster operations.

      Paused - The node is actively participating in cluster operations but cannot take ownership of resource groups and cannot bring resources online.

      Unknown - The state could not be determined.

      Up - The node is actively participating in all cluster operations.

  • View the version and build number of the Cluster service.

Properties of a cluster object should not be updated on multiple nodes simultaneously. For more information on multiple and simultaneous property updates, see the Microsoft Platform Software Development Kit (SDK).


Setting resource type properties

Using the resource type Properties dialog box, you can:

  • View or change the resource type display name. The display name is used to manage the resource type in the cluster administration tools.
  • View or change the description of the resource type.
  • View the nodes on which the resource type can run.

  • View or change the default poll intervals (in milliseconds) for resources of this type. The poll intervals are Looks Alive and Is Alive.

    The Looks Alive poll interval specifies how often the Cluster service checks the state of the resource to determine whether or not the resource appears to be active. You can use the default value for the resource type or specify a number in milliseconds.

    The Is Alive poll interval specifies how often the Cluster service checks whether the resource is active. You can use the default value for the resource type or specify a number in milliseconds.

  • View the type name of the resource type. The type name is used internally by APIs and resource dynamic link libraries (DLLs).
  • View the DLL file that implements the behavior of this resource type.
  • View whether resources of this type can be used as a quorum resource. The only quorum capable resource type currently provided by Microsoft is the Physical Disk resource type. For more information on quorum resource, see Quorum resource. For more information on the Physical Disk resource type, see Physical Disk resource type.

Properties of a cluster object should not be updated on multiple nodes simultaneously. For more information on multiple and simultaneous property updates, see the Microsoft Platform Software Development Kit (SDK).


Network management

This topic describes features of server clusters that affect network management:

  • Plug and Play network support
  • Name coordination between Cluster service and Network and Dial-up Connections
  • Network failure detection and recovery


Plug and Play network support

Using the Plug and Play technology built into Windows 2000 Advanced Server, the Cluster service detects the addition and removal of TCP/IP network stacks. For example, the Cluster service can detect the following events:

  • Addition or removal of network adapters
  • Binding or unbinding the TCP/IP protocol stack to a network adapter
  • Addition or release of a DHCP-assigned IP address

When you add a new TCP/IP stack to a computer, the Cluster service adds a network interface object to the cluster. If the network interface is connected to a new network, the Cluster service also adds a new network object to the cluster. You do not need to restart the Cluster service for these changes to take place. The newly created interface and network objects are used only for client communication. They are not used for internal cluster communication unless you manually change their configuration.

For more information on configuring network objects, see Setting network properties. For more information on configuring network interface objects, see Setting network interface properties.

Similarly, if a TCP/IP stack is removed, the Cluster service removes the corresponding network interface object from the cluster. If that network interface is the last interface connected to a network, the Cluster service removes the network object from the cluster.


Name coordination between Cluster service and Network and Dial-up Connections

In Windows 2000, each physical network on a computer is represented by a named icon in the Windows 2000 Network and Dial-up Connections folder. The Cluster service coordinates the names of its network interface objects with the names of the icons in the Network and Dial-up Connections folder.

Automatic renaming of networks

Windows 2000 automatically ensures that both a server cluster and the Network and Dial-up Connections folder use the same name to reference any individual network interface. For example, if you use any cluster administration tool to rename a cluster network object, Windows 2000 automatically renames the corresponding icon in the Network and Dial-up Connections folder. Similarly, if you rename an network connection icon in the Network and Dial-up Connections folder, Windows 2000 renames the matching cluster network object, if one exists.

Windows 2000 ensures that the two nodes of a cluster also use the same name for the network object and corresponding icons in the Network and Dial-up Connections folder. Therefore, if you rename a cluster network object on one node of a cluster, the name of the network object on the other node and the icon name in the Network and Dial-up Connections folders on both nodes also change.

Windows 2000 does not notify you when it renames a related cluster network object or icon in a Network and Dial-up Connections folder.

The following table summarizes the actions Windows 2000 takes in response to any renaming you perform.

Action | Result
Setup a new cluster | Windows 2000 uses the names of the icons in the Network and Dial-up Connections folder as the default names for cluster network objects. If you choose to rename any of the cluster network objects, then Windows 2000 renames the corresponding icon in the Network Connections folder.
Add a new node to an existing cluster | Windows 2000 renames icons in the Network and Dial-up Connections folder to match the names of the cluster network objects.
Rename a network object using a cluster administration tool | The corresponding icon in the Network and Dial-up Connections folder is renamed on both cluster nodes.
Rename an icon in the Network and Dial-up Connections folder | Windows 2000 renames the corresponding cluster network object. It renames the corresponding icon in the Network and Dial-up Connections folder on the other node.

Network name conflicts

When you change the name of a network object or an icon in the Network and Dial-up Connections folder on one node of a cluster, you introduce the possibility of a naming conflict. For example, assume you have a cluster consisting of Node 1 and Node 2, and you change the name of a cluster network object on Node 1 from Public Network to Corporate Network. If a icon in the Network and Dial-up Connections folder on either Node 1 or Node 2 is already named Corporate Network, then the renaming attempt creates a name conflict.

Windows 2000 avoids name conflicts by appending a number to any existing icon or network object names that would cause a name conflict with whatever new name you enter. In the above example, Windows 2000 renames the existing Corporate Network icon as Corporate Network (2). This feature ensures that whenever you attempt to rename a network object or an icon in the Network and Dial-up Connections folder, your renaming attempt succeeds without generating any name conflicts.


Network failure detection and recovery

The Cluster service is able to detect and isolate network failures. The Cluster service uses its improved network failure detection to improve failure recovery actions.

This section describes the Cluster service network state management and failure recovery process:

  • Network state management and failure detection
  • Network-failure recovery


Network state management and failure detection

Windows 2000 uses sophisticated algorithms to monitor the health of network interfaces in a server cluster. The following tables summarize the states that a network interface and a network can be in.

Network interface states

State | Description
Failed

The node that owns the network interface is active; however, it cannot communicate through its network interface. The Cluster service has determined that the error is isolated to the network interface.

Windows 2000 uses several methods to determine if failures are isolated to network interfaces. First, the Cluster service uses a heartbeat to help detect network problems. Second, Windows 2000 can receive hardware failure notifications from a network adapter that supports the Network Driver Interface Specification (NDIS). Using newer network adapters that support NDIS improves cluster network state management. Finally, the Cluster service attempts to ping external hosts to estimate the scope of a network interface failure. This can cause a temporary increase in network traffic while Windows 2000 investigates the extent of a network failure.

Note

  • When a failed network adapter is replaced, the Cluster service will determine that the new card is the interface for an existing network if the card is on the same subnet.
Unavailable | The network is disabled for cluster use, or the node associated with this network interface is down.
Unreachable | The node cannot communicate through this network interface. The reason for the failure is unknown.
Up | The network interface is active and can communicate with all other interfaces on the network (except those currently in Failed or Unavailable states). Up is the normal operational state.
Unknown | The state cannot be determined.

Network states

State | Description
Down | The network has failed. None of the active nodes in the cluster can communicate with one another using this network.
Unavailable | The network is disabled for cluster use, or all of the cluster nodes attached to this network are inactive.
Partitioned | The network has partially failed. Some active cluster nodes cannot communicate with one another over this network.
Up | The network is functioning normally. Up is the normal operational state.
Unknown | The state cannot not be determined.


Network-failure recovery

When a network interface enters the Failed state, the Cluster service triggers the failure of all IP Address resources that use that network interface. When an IP Address resource fails, the Cluster service treats it like the failure of any other resource: All resources that depend on the IP Address resource fail, and the Cluster service uses the failover policy that you have set to determine whether or not to fail over the resource group.

The Cluster service does not trigger the failure of IP Address resources when a network interface enters the Unreachable state. If the network interface is in the Unreachable state, the Cluster service has not isolated the network problem enough to implement an appropriate recovery policy. When a network interface enters the Unreachable state, you should investigate the state of the network to determine whether or not you should cause a manual failover of resource groups.

The following table summarizes all possible network-interface states, and the corresponding network and resource-group states.

Network-interface state for node A | Network-interface state for node B | Network state | Effect on resources
Up | Up | Up | Normal operation.
Up | Unavailable | Up | Only Node A is running.
Up | Failed | Up | The IP Address resource that depends on the network interface on Node B fails. This triggers a failover of any resources that depended on the IP Address resource, depending on your failover policy.
Failed | Failed | Down | The IP Address resource fails on both Node A and Node B. All resources that depend upon the IP Address resource fail.
Failed | Unavailable | Down | Node A is running. Node B is not running. However, the IP Address resource on Node A fails. Since Node B is not running, all resources that depend upon the IP Address resource fail.
Unavailable | Unavailable | Unavailable | No nodes are running.


Resources

  • Pfister, Gregory F. In Search of Clusters. Upper Saddle River, NJ: Prentice Hall, 1998.
  • Search for Windows 2000 at the Microsoft Windows Web site (http://www.microsoft.com/).
  • For technical support information on server clusters, see Updated technical information.
  • Requests for Comments (RFCs) are an evolving series of reports, proposals for protocols, and protocol standards used by the Internet community. Standards are defined in RFCs published by the Internet Engineering Task Force (IETF) and other working groups. For more information on private IP network addresses, see RFC 1918: Address Allocation for Private Internets.

    You can obtain RFCs from the Request for Comments Web site.

  • Cluster Administrator supports command-line parameters. If you start Cluster Administrator from the command line, you can connect to one or more clusters by specifying the cluster name, the name of one of the cluster nodes, or the name of a cluster IP address.

    When you specify the clusters to connect to using the Cluster Administrator command line, Cluster Administrator will not try to restore your most recent cluster connections. You can also prevent Cluster Administrator from restoring your most recent cluster connections by typing /noreconnect on the command line.

  • The following links point to information that may help you better understand server clusters within the overall context of Windows Clustering.

    For information on the solutions that make up Windows Clustering, see Windows Clustering.

    For information on Network Load Balancing clusters, see Network Load Balancing clusters.

    For information on server clusters and how they work with Network Load Balancing clusters, see Updated technical information.

  • Server clusters support unattended setup, a feature of Windows 2000.

    For information about unattended setup, see Planning for unattended setup.


Troubleshooting

This section provides symptom-based diagnostic procedures for troubleshooting clustering problems. For more information about how to obtain product support, see Microsoft Product Support Services.

This section covers:

  • Cluster disk and drive connection problems
  • Node-to-node connectivity problems
  • Client-to-cluster connectivity problems
  • Group and resource failure problems
  • General administrative problems


Cluster disk and drive connection problems

What problem are you having?

When the physical disks are not powering up or spinning, the Cluster service cannot initialize any quorum resources.

Cause: Cables are not correctly connected, or the physical disks are not configured to spin when they receive power.

Solution: After checking that the cables are correctly connected, check that the physical disks are configured to spin when they receive power. If you are using SCSI, you can try taking one or more of the drives in your server off the SCSI chain to see if the rest of the drives spin up when you turn on the server.

Drive on the shared SCSI bus is not recognized.

Cause: The SCSI controller is not properly terminated.

Solution: Verify proper SCSI termination.

To check for proper termination, put the terminator on the end where the other controller should be and see if the device is recognized. Then, reverse the procedure. If the device is recognized on one server but not on the other, there is a termination problem.

Cause: Scanning for SCSI devices is not disabled on each controller on the shared SCSI bus.

Solution: Verify that scanning for SCSI devices is disabled on each controller on the shared SCSI bus.

Many times, the second computer you turn on does not recognize the shared SCSI bus during the BIOS scan if the first computer is running. This situation can manifest itself in a "Device not ready" error being generated by the SCSI controller or in substantial delays during startup.

To correct this, disable the option to scan for SCSI devices on the shared SCSI controller. If this option is not present on your computer, you can follow the instructions in To start a cluster that has SCSI connection problems.

Notes

  • This symptom can manifest itself as one of several errors, depending on the attached SCSI controller. It is normally accompanied with a one to two minute start delay and an error indicating the failure of some device.
  • On computers that use Adaptec 2940 SCSI controller cards, it is recommended that you turn off the Adaptec firmware controllers so that the server does not scan for the SCSI device in its BIOS setup.

Configuration cannot be accessed through Disk Administrator.

Under normal cluster operations, the node that owns a quorum resource locks the drive storing the quorum resource, preventing the other node from using the device. If you find that the cluster node that owns a quorum resource cannot access configuration information through Disk Administrator, the source of the problem and the solution might be one of the following:

Cause: A device does not have physical connectivity and power.

Solution: Reseat SCSI cards, reseat cables, and make sure the drive spins up when you start.

Cause: The SCSI IDs are not properly configured.

Solution: Check the SCSI cards and devices to ensure that there are no conflicting SCSI IDs. Each SCSI card and device must have a unique SCSI ID.

Cause: You attached the cluster storage device to both nodes and started both nodes before installing the Cluster service on either node.

Solution: After you attach both servers to the cluster drives, you must install the Cluster service on one node before starting both nodes. Attaching the drive to both nodes before you have the cluster installed can corrupt the file system on the disk resources on the shared SCSI bus.

SCSI devices do not respond.

Cause: The SCSI bus is not properly terminated.

Solution: Make sure that the SCSI bus is not terminated early and that the SCSI bus is terminated at both ends.

Cause: The SCSI cable is longer than the specification allows.

Solution: Make sure that the SCSI cable is not longer than the SCSI specification allows.

Cause: The SCSI cable is damaged.

Solution: Make sure that the SCSI cable is not damaged. (Check for bent pins and loose connectors on the cable and replace it if necessary.)

Disk groups do not move or stay online pending after move.

Cause: SCSI is not properly terminated.

Solution: Check your SCSI termination.

Cause: Cables are damaged or not properly installed.

Solution: Check for bent pins on cables and make sure that all cables are firmly anchored to the chassis of the server and drive cabinet.

Cause: Termination is not set to Enabled or Automatic.

Solution: Check the firmware of the SCSI controllers to make sure that termination is set to Enabled or Automatic.

Cause: Cables are faulty.

Solution: Test for faulty cables using the instructions in To test for faulty cables in a cluster.

Disks do not come online or Cluster service does not start when a node is turned off.

Cause: If disks do not come online or the Cluster service does not start when one node is turned off, ensure that your SCSI adapter in the node that is turned off still provides proper termination. (Some SCSI hardware does not provide termination when the SCSI device is turned off.)

Solution: You can test for termination problems by putting a terminator in place of the SCSI cable from the node that is turned off, or you can turn on the other node and then prevent it from starting Windows Server by pressing the SPACEBAR at the Windows 2000 loader screen.

Cause: If the quorum log is corrupted, the Cluster service cannot start.

Solution: If you suspect the quorum resource is corrupted, see the information on the problem "Quorum log becomes corrupted" in Node-to-node connectivity problems.

Drives do not fail over or come online.

Cause: The drive is not on a shared SCSI bus.

Solution: If drives on the shared SCSI bus do not fail over or come online, make sure the disk is on a shared SCSI bus, not on a nonsystem bus.

Cause: When you install the Cluster service, Setup displays all SCSI disks on SCSI buses other than the system SCSI bus. If you have more than one local SCSI bus, some drives in Shared cluster disks will not be on a shared SCSI bus.

Solution: If you do not remove these drives from Shared cluster disks, the drives do not fail over, even though you can configure them as resources.

Shared cluster disks is in the Cluster Application wizard.

For more information about how to obtain product support, see Microsoft Product Support Services.


Node-to-node connectivity problems

What problem are you having?

The Cluster service installation does not complete on the first node.

Cause: There is insufficient free space on your nonshared drives for the Cluster service installation files.

Solution: Make sure that there is sufficient free space on your nonshared drives for the Cluster service installation files.

You may have to free space by moving your paging file to another drive, compressing the drive if it is formatted with NTFS, or removing other applications from the drive.

Cause: Windows 2000 Advanced Server is incorrectly installed.

Solution: Make sure that Windows 2000 Advanced Server is correctly installed.

Cause: Your hardware is not listed in the Cluster category on the Microsoft Windows Hardware Compatibility List.

Solution: Make sure that your hardware is listed on the Microsoft Windows Hardware Compatibility List. See the Hardware Compatibility List on the Microsoft Web site (http://www.microsoft.com/). In the Category list box, click Cluster.

If any of the hardware you are using for your cluster is not on this list, consider replacing those components with hardware that is listed.

Cause: You have chosen individual components from the Hardware Compatibility List instead of systems.

Solution: You should not choose individual components of your cluster from the Microsoft Windows Hardware Compatibility List. Microsoft supports only systems chosen from this list.

Cause: Your primary IP address is invalid.

Solution: If the node uses DHCP to obtain noncluster IP addresses, use Ipconfig.exe to verify that you have a valid primary IP address for all network adapters. If the second IP address listed is 0.0.0.0, your primary address is invalid.

When the resources fail over and the nodes do not detect each other, there is no connectivity between the nodes or with the cluster storage device.

Cause: The Remote Procedure call (RPC) service is not running.

Solution: On each node, use Services in Control Panel to confirm that the RPC service is running.

Cause: The nodes do not have RPC connectivity.

Solution: Verify that the nodes have RPC connectivity.

You can determine this by using a network analyzer (such as Network Monitor), or you can use RPCPing (available on the Microsoft Exchange Server CD)

Quorum resource does not start.

Cause: The resource is not physically connected to the server.

Solution: Make sure that the resource is physically connected to the server.

Cause: The devices are not properly terminated.

Solution: Make sure that the devices are properly terminated.

Most often, the problem is with the hardware configuration. If you use SCSI and if your connections are set, turn off the SCSI devices and check the SCSI IDs of the devices. Make sure that the IDs are not both set to 7 (the default). If they are, this causes a conflict that prevents a node from detecting the resource.

Quorum resource fails.

Cause: The disk on the shared bus holding the quorum resource has failed.

Solution: If the disk on the shared bus holding the quorum resource fails and cannot be brought online, the Cluster service cannot start. To correct this situation, you must use the fixquorum option to start the Cluster service on a single node, and then use Cluster Administrator to configure the Cluster service to use a different disk on the shared bus for the quorum resource.

When fixquorum is specified, the Cluster service starts without a quorum resource, and does not bring the quorum disk online. A node cannot join a cluster when the Cluster service is running with the fixquorum option.

For instructions on how to change the disk that the Cluster service uses for the quorum resource, see To configure the Cluster service to use a different disk for the quorum resource.

Quorum log becomes corrupted.

Cause: This may occur for a variety of reasons.

Solution: If the quorum log is corrupted, the Cluster service attempts to correct the problem by resetting the log file. In this case, the Cluster service writes the following message in the Windows 2000 system log:

The log file [name] was found to be corrupt. An attempt will be made to reset it.

If the quorum log cannot be reset, the Cluster service cannot start.

If the Cluster service fails to detect that the quorum log is corrupted, the Cluster service may fail to start. In this case, there may be an "ERROR_CLUSTERLOG_CORRUPT" message in the system log.

To correct this, you must use the noquorumlogging option when starting the Cluster service to temporarily run the Cluster service without quorum logging. You can then correct the disk corruption and delete the quorum log, as necessary. When noquorumlogging is specified, the Cluster service brings the quorum disk online, but disables quorum logging. You can then run Chkdsk on your quorum disk to detect and correct disk corruption.

For instructions on how to recover from a corrupted quorum log or quorum disk, see To recover from a corrupted quorum log or quorum disk.

Second node cannot join the cluster.

When a second node fails to join a cluster, improper name resolution is often the cause. The problem may exist because of invalid data in the WINS cache. You may also have the wrong binding on the WINS or DNS Services for the second node.

If WINS or DNS is functioning correctly on both nodes:

Cause: You may not be using the proper cluster name, node name, or IP address.

Solution: Confirm that you are using the proper cluster name, node name, or IP address.

When joining a cluster, you can specify the cluster name, the computer name of the first node, or the IP address of either the cluster or the first node.

Cause: The Cluster Name resource may not have started.

Solution: Confirm that the Cluster Name resource started.

Use Cluster Administrator on the first node to ensure that the Cluster Name resource is running.

Cause: The Cluster service may not be running on the first node.

Solution: Confirm that the Cluster service is running on the first node and that all resources within the Cluster Group are online before installing the second node.

The Cluster service may not have yet started when you attempted to join the cluster.

Cause: Network connectivity may not exist between the two nodes.

Solution: Confirm that network connectivity exists between the two nodes.

Make sure TCP/IP is properly configured on both nodes.

Cause: You may not have IP connectivity to the cluster address.

Solution: Confirm that you have IP connectivity to the cluster address and that the IP address is assigned to the correct network.

If you cannot ping the IP address of the cluster, run Cluster Administrator on the first node and ensure the cluster IP Address resource is running. Also, use Cluster Administrator to ensure that the cluster has a valid IP address and subnet mask (click Cluster Group, right-click Cluster IP Address, and click Properties), and that the IP address does not conflict with an IP address that is already in use on the network. If the address is not valid, change it, take the Cluster IP Address resource offline, and then bring it online again. If the IP address is not assigned to the correct network, use Cluster Administrator to correct the problem.

If your cluster nodes use DHCP to obtain noncluster IP addresses, use Ipconfig.exe to verify that you have a valid primary IP address for the networks in question. If the second IP address listed is 0.0.0.0, your primary address is invalid.

Cause: The network role may have changed from Use for all communication.

Solution:Confirm that the network role has not been changed from Use for all communication.

A network role is initialized to Use for all communications but can be changed by the administrator. After verifying that you have IP connectivity to the cluster address and that the IP address is assigned to the correct network, use Cluster Administrator to confirm that at least one of the networks connected between the nodes is enabled to Use for all communications. To verify the role in Cluster Administrator, open the Networks folder, right-click Network, and then click Properties. Use for all communications enables the network to have both node-to-node communication and client-to-cluster communication.

For more information on networks, see Server cluster networks. For more information on network roles, see Configuring cluster network hardware. To use Cluster Administrator to reset the network's role to Use for all communications, see To enable a network for cluster use.

Second node cannot connect to the cluster drives.

Cause: The same drive letters may not have been assigned to the cluster drives on all nodes.

Solution: Confirm that the cluster drives are assigned the same drive letters on all nodes.

To do so, run Disk Administrator on each node and make sure that identical drive letters are assigned to all cluster drives.

Cause: The SCSI devices may not have unique IDs.

Solution: Verify that each SCSI device has a unique ID. SCSI controller IDs are preset to seven. Reset one SCSI controller ID to six.

Cause: The second node may not be physically connected to the cluster drive.

Solution: Confirm that the second node is physically connected to the cluster drive.

If it is not, shut down both nodes and the cluster drive. Connect the nodes to the shared SCSI bus. Then, start the cluster drive and start the first node. After the Cluster service starts on the first node, start the second node, and attempt to connect to the cluster drive.

Cause: The SCSI controllers on the shared SCSI bus may not be correctly configured.

Solution: Confirm that the SCSI controllers on the shared SCSI bus are correctly configured (with both cards configured to transfer data at the same rate).

Cause: The devices and controllers may not match.

Solution: Confirm that your devices and controllers match.

For example, do not use a wide connection controller on one node and a narrow connection controller on the other node. It is also recommended that both SCSI controllers are homogeneous, so do not use different brands of SCSI controllers together.

For more information about how to obtain product support, see Microsoft Product Support Services.


Client-to-cluster connectivity problems

What problem are you having?

Clients cannot connect to virtual servers.

Cause: The client may not be using the correct network name or IP address to access the cluster.

Solution: Make sure that the client is accessing the cluster using the correct network name or IP address.

Cause: The client may not have the TCP/IP protocol correctly installed and configured.

Solution: Make sure that the client has the TCP/IP protocol correctly installed and configured.

Depending on the application being accessed, the client can address the cluster by specifying either the resource network name or the IP address. In the case of the network name, you can verify proper name-resolution by checking the NetBT cache (using the Nbtstat.exe utility) to determine whether the name had been previously resolved. Also, confirm proper WINS configuration, both at the client and through the WINS Administrator.

If the client is accessing the resource through a specific IP address, ping the IP address of the cluster resource and cluster nodes from a command prompt.

For more information on Nbtstat.exe, see Nbtstat.

For instructions on how to troubleshoot connectivity problems, see To troubleshoot client-to-virtual server connectivity.

Clients cannot access resources.

Cause: Both your private network and the primary network are down.

Solution: If your server cluster nodes are multihomed and use a private network to communicate, the primary network can be down and the Cluster service can still function normally.

If the private network is lost between two nodes, resources that are configured to do so will fail over to the node that has ownership of the quorum resource. The other node will stop its Cluster service.

Cause: A node may have lost connectivity with the network.

Solution: If you suspect a node has lost connectivity with the network:

  • On the desktop, right-click My Network Places, click Properties, and confirm that the configuration settings on the Protocol and Services tabs are correct.
  • Check WINS or DNS to make sure that they are properly configured.
  • Confirm that the static IP addresses being used by the Cluster service are still in place and are not being used by other resources on the network.

A node cannot communicate on a network.

Cause: If a node cannot communicate on a network, you may not have a physical connection to the other node, or the nodes may not be connected to each other.

If the cabling has failed, the Cluster service may not have received the heartbeat of the node and so could not fail over the resources according to configuration.

Solution: Check the hub and local cabling, both to the network and to the cluster disks.

Clients cannot access a group that has failed over.

Cause: There may not be a physical connection between the cluster nodes.

Solution: Confirm that you have a physical connection between the cluster nodes.

  • Make sure that the network cabling has not failed or been damaged.

    If the cabling has failed, the Cluster service may have failed over the resources to another node.

  • Ensure the SCSI device cabling has not failed.
  • If the nodes are separated by one or more hubs, check the connectivity through all hubs.

Clients cannot attach to a cluster file share resource.

Cause: WINS or DNS may not be correctly configured.

Solution: Make sure that WINS or DNS are correctly configured.

If you are using WINS, run WINS Manager on the WINS server; then, on the Mappings menu, click Show Database. Make sure that each node and the cluster are registered in the WINS database and that the registrations are active.

For more information on WINS and WINS Manager, see Windows 2000 Server Resource Kit Networking Guide, available separately.

Cause: Your security policies may not allow the client to access the share.

Solution: Make sure that your security policies allow the client to access the share.

The client must have the right to log on to the share, or the Guest account must be enabled for the client to have access.

Clients cannot access a cluster resource.

Cause: Either the IP Address resource or Network Name resource for the group in which the resource is contained is not online.

Solution: Check the group dependencies; the resource should be dependent on either the IP Address or the Network Name resource. Ensure that the IP Address and Network Name resources are online in the resource group. From the client computer, try to ping the IP addresses of the virtual server and individual nodes.

Cause: Either the client or the cluster computer is not configured for either WINS or DNS.

Solution: Make sure that the cluster nodes are configured properly for name resolution using either WINS or DNS, and make sure that clients are configured to use the same form of name resolution.

Cause: The client is attempting to access the cluster from a different subnet, and DNS is not correctly configured.

Solution: The cluster nodes and client computer should be configured to use WINS or DNS. If you use DNS, add a DNS address record for the cluster in the DNS database.

Client can detect all nodes but cannot detect a virtual server.

Cause: The virtual server may not have its own IP Address and Network Name resources.

Solution: Make sure that the virtual server has its own IP Address and Network Name resources, and that both resources are online.

Your servers must have an address and a name on the network for any other server or client to properly recognize that the servers are on the network.

Cause: One or more nodes are not correctly configured to use WINS or DNS.

Solution: Make sure that all nodes are correctly configured to use WINS or DNS.

For more information about how to obtain product support, see Microsoft Product Support Services.


Group and resource failure problems

What problem are you having?

A resource fails, but is not brought back online.

Cause: A resource may depend on another resource that has failed.

Solution: In the resource Properties dialog box, make sure that the Do not restart is clear. If the resource needs another resource in order to function, and if the second resource fails, confirm that the dependencies are correctly configured.

You cannot bring a resource online.

Cause: The resource is not properly installed.

Solution: Make sure the application or service associated with the resource is properly installed.

Cause: The resource is not properly configured.

Solution: Make sure the properties are set correctly for the resource.

Cause: The resource is not compatible with server clusters.

Solution: Not all applications can be configured to fail over in a cluster. For more information, see Choosing applications to run on a server cluster.

You cannot bring the default physical disk resource online in Cluster Administrator.

Most cluster configuration problems result from improper configuration of the shared SCSI bus or the restart of servers.

Cause: You may not have restarted the servers after installing the Cluster service.

Solution: Make sure that you restarted all servers after installing the Cluster service.

When the servers are restarted, the signature of each disk in the cluster storage is read, and the registries are updated with the signature information.

Cause: There may be hardware errors or transport problems.

Solution: Make sure that there are no hardware errors or transport problems.

Using Event Viewer (on the Start menu, under Programs and Administrative Tools (Common)), look in the event log for disk I/O error messages or indications of problems with the communications transport.

Cause: You may not have waited long enough for the registries to be updated.

Solution: Make sure that you waited long enough for the registries to be updated.

Cluster Administrator takes a snapshot of the registry when it starts up. However, it can take up to a minute after the second server restarts for the disk signatures to be written to the registries. Wait a minute, and then click Refresh.

Cause: One or more SCSI adapters on the shared SCSI bus are configured incorrectly.

Solution: Make sure that the SCSI adapters are configured correctly.

Cause: The shared SCSI bus exceeds the maximum cable length.

Solution: Make sure that the shared SCSI bus does not exceed the maximum cable length.

Cause: The shared SCSI bus is improperly terminated.

Solution: Make sure that the shared SCSI bus is properly terminated.

Cause: The disk is not supported.

Solution: Make sure that the disk hardware or firmware revision level is not outdated.

Cause: The bus adapter is not supported, or the adapter hardware or firmware revision level is outdated.

Solution: Make sure that the bus adapter is supported, and that the adapter hardware or firmware revision level is current.

Cause: Duplicate SCSI IDs have been specified on the shared SCSI bus.

Solution: Verify that each SCSI device has a unique ID. SCSI controller IDs are preset to seven. Reset one SCSI controller ID to six.

Cause: If you move your SCSI bus adapter to another I/O slot, add or remove bus adapters, or install a new version of the bus adapter driver, the cluster software may not be able to access disks on your shared SCSI bus

Solution: In order to accommodate these changes, make sure that your shared SCSI bus adapter has been properly reconfigured.

Cause: Windows 2000 is incorrectly configured to access the shared SCSI bus.

Solution: Verify that Windows 2000 can detect the shared SCSI bus adapter and that the SCSI IDs for the adapter and disks are listed. To do so, open Control Panel and double-click SCSI Adapters.

In Disk Administrator, you do not see the disk for the group that is online on that node.

Cause: You may not be looking at the right disks.

Solution: Make sure that you are looking at the right disks.

If you have not labeled your disks or assigned fixed drive letters to them, you may not recognize which disks are part of the cluster and which ones are not. Label your disks in a meaningful manner and assign fixed drive letters to all partitions.

Cause: There may have been hardware problems.

Solution: Make sure that there have not been any hardware problems.

Run Event Viewer and check for disk I/O error messages or indications of hardware problems.

You are unable to manually move a group, or it does not fail over when it should to another node.

Cause: The other node may not be designated as a possible owner for all resources in the group that you want to fail over.

Solution: Make sure that the other node is designated as a possible owner for all resources in the group you want to fail over.

Check the ownership configuration in the group resource Properties dialog box. If the node is not set as a possible owner for all resources in the group, the node cannot own the group, so failover will not occur. To fix this, make the node a possible owner for all resources in the group.

Cause: A resource in the group may be continually failing.

Solution: Determine if a resource in the group is continually failing.

If the node can, it will bring the resource back up without failing over the group. If the resource continually fails but does not fail over, make sure that the resource property Restart and affect the group is selected. Also, check the Restart Threshold and Restart Period settings, which are also in the resource Properties dialog box.

A group failed over but did not fail back.

Cause: The failback policies of both the group and the resources may not be properly configured.

Solution: Make sure that the Prevent failback check box is clear in the group Properties dialog box. If the Allow failback check box is selected, be sure to wait long enough for the group to fail back. Check these settings for all affected resources within a group. Because groups fail over as a whole, one resource that is prevented from failing back affects the entire group.

Cause: The node to which you want the group to fail back is not configured as the preferred owner of the group.

Solution: Make sure that the node to which you want the group to fail back is configured as the preferred owner of the group. If not, the Cluster service leaves the group on the node to which they failed over.

The entire group failed and has not restarted.

Cause: A node is offline.

Solution: Make sure that the node is not offline.

If the node on which the group had been running is offline, check that another node is a possible owner of the group and of every resource in the group.

Cause: The group has failed repeatedly.

Solution: The group may have exceeded its failover threshold or its failover period. Try to bring the resources online individually (following the correct sequence of dependencies) to determine which resource is causing the problem. Or, create a temporary resource group (for testing purposes) and move the resources to it, one at a time.

All nodes are functioning, but resources fail back repeatedly.

Cause: Power may be intermittent or failing.

Solution: Ensure that your power is not intermittent or failing. You can correct this by using an uninterruptable power supply (UPS) or, if possible, by changing power companies.

The Cluster service does not successfully fail over resources.

Cause: Cluster storage device is not properly configured.

Solution: Verify that the cluster storage device is properly configured and that all cables are properly connected.

For more information about how to obtain product support, see Microsoft Product Support Services.


General administrative problems

What problem are you having?

The Cluster service fails and the node cannot detect the network.

In this case, you probably have a configuration problem. Check the following:

Cause: Have you made any configuration changes recently?

Solution: If the node was recently configured, or if you have installed some resource that required you to restart the computer, make sure that the node is still properly configured for the network.

Cause: Is the node properly configured?

Solution: Check that the server is properly configured for TCP/IP. Also check that the appropriate services are running. If the node recently failed, there is an instance of failover; but, if the other node also has the wrong configuration, the failover is inadequate for client access.

An IP address added to a group in the cluster fails.

Cause: The IP address is not unique.

Solution: The IP address must be different from every other group IP address and every other IP address on the network.

Cause: The IP address is not a static IP address.

Solution: The IP addresses must be statically assigned outside of a DHCP scope, or they must be reserved by the network administrator.

An IP address resource stops responding when taken offline.

Cause: You may not have waited long enough for the resource to go offline.

Solution: If an IP Address resource stops responding when taken offline, make sure that you wait long enough for the resource to go offline.

Certain resources take time to go offline. For example, it can take up to three minutes for the IP Address resource to go fully offline.

You receive the error: "RPC server is unavailable."

Cause: The server may not be operational, or the Cluster service and the RPC services may not be running.

Solution: If you receive the error "RPC Server is unavailable," ensure that the server is operational and that both the Cluster service and the RPC services are running. Also, check the name resolution of the cluster; it is possible that you are using the wrong name or that the name is not being properly resolved by WINS or DNS.

Cluster Administrator cannot open a connection to a node.

Cause: The node may not be running.

Solution: If Cluster Administrator cannot open a connection to a node, make sure that the node is running. If it is, confirm that both the Cluster service and the RPC services are running.

An application starts but cannot be closed.

Cause: You may not have taken a resource offline using Cluster Administrator.

Solution: When you bring resources online using Cluster Administrator, you must also take those resources offline using Cluster Administrator; do not attempt to close or exit the application from the application interface.

A resource has failed over but will not fail back.

Cause: The hardware and network configurations may not be valid.

Solution: Make sure that the hardware and network configurations are valid.

If the SCSI cable or any interconnect fails, failover can occur because the Cluster service does not detect a heartbeat, or it may not even register that the node was ever online. In this case, the Cluster service fails over the resources to the server that does exist, but it cannot fail back because that node is still down.

Cause: The resource may not have been configured to fail back immediately, or you are not troubleshooting the problem within the allowable failback hours for the resource.

Solution: Make sure that the resource is configured to fail back immediately, or that you are troubleshooting the problem within the allowable failback hours for the resource.

A group can be configured to fail back only during specified hours. Often, administrators prevent failback during peak business hours. To check this, use Cluster Administrator to view the resource failback policy.

All nodes appear to be functioning correctly, but you cannot access all of the drives from one node.

Cause: The shared drive may not be functioning.

Solution: Confirm that the shared drive is still functioning.

Try to access the drive from another node. If you can do that, check the cable from the device to the node that you cannot perform the access. If the cable is not the problem, restart the computer and then try again to access the device. If you cannot access the drive, check your configuration.

Cause: The drive has completely failed.

Solution: Determine (from another node) if the drive is functioning at all. You may have to restart the drive (by restarting the computer) or replace the drive.

The hard disk with the resource or a dependency for the resource may have failed. You may have to replace a hard disk. You may also have to reinstall the cluster.

Cluster Administrator update delays.

Cause: If you run Cluster Administrator from a remote computer, it may not display the correct (updated) cluster state when the cluster network name fails over from one node to another node. This can result in Cluster Administrator displaying a node as being online, when it is actually offline.

Solution: To work around this problem, restart Cluster Administrator.

You can avoid this problem by connecting to clusters through node names. However, if the node you are connected to fails, Cluster Administrator stops responding until the RPC connection times out.

Cluster Administrator stops responding when a node fails.

Cause: The Cluster Administrator may be slow in doing dynamic updates.

Solution: If Cluster Administrator stops responding when a node fails, make sure that Cluster Administrator is not just slow in doing dynamic updates. If the Cluster service is running on a remaining node, Cluster Administrator is either not responding or is updating very slowly. There are two ways to see if the Cluster service is running on a remaining node:

  • Use the TCP/IP Ping utility to ping the cluster name on a remaining node.
  • In Control Panel, double-click Services, and check whether the Cluster service is running.

Cannot connect to cluster from recent file list.

Cause: Files listed in the Cluster Administrator recent file list (both on the File menu and in the Open Connection to Cluster dialog box) have the cluster name appended to the path. For example, instead of Webclust1, the recent file list may list C:\Winnt\Cluster\Webclust1. This problem occurs when Microsoft Visual C++(r) version 5.0 is installed.

Solution: To work around this problem, manually type the cluster name when you open the connection.

Node performance is sluggish and node fails.

Cause: CPU may be overloaded.

Solution: Check that your node is not processor-bound. That is, that the CPU is not running at 100-percent utilization. If you try to run too many resources for the node capacity, you can overload the CPU.

Also, review the size of your paging file. If the paging file is too small, the Cluster service can detect this as a node failure and fail over the groups.

For more information about how to obtain product support, see Microsoft Product Support Services.