Failover Clusters

  • Overview of Failover Clusters

  • Checklist: Create a Failover Cluster

  • Checklist: Create a Clustered File Server

  • Checklist: Create a Clustered Print Server

  • Installing Failover Clustering

  • Validating a Failover Cluster Configuration

  • Creating a Failover Cluster or Adding a Cluster Node

  • Configuring a Service or Application for High Availability

  • Migrating Settings from a Server Cluster Running Windows Server 2003

  • Modifying Settings for a Failover Cluster

  • Managing a Failover Cluster

  • Resources for Failover Clusters

  • User Interface: The Failover Cluster Management Snap-In


Overview of Failover Clusters

A cluster is a set of independent computers that work together to increase the availability of services and applications. The clustered servers (called nodes) are connected by physical cables and by software. If one of the nodes fails, another node begins to provide service through a process known as failover.

You can use the Microsoft® Management Console (MMC) snap-in, Failover Cluster Management, to validate failover cluster configurations, create and manage failover clusters, and migrate certain settings from a cluster running Windows Server® 2003 to a cluster running the Windows Server® 2008 operating system.

In Windows Server 2008, the improvements to failover clusters (formerly known as server clusters) are aimed at simplifying clusters, making them more secure, and enhancing cluster stability. Cluster setup and management are easier. Security and networking in clusters have been improved, as has the way a failover cluster communicates with storage.

Note that the Failover Clustering feature is included in Windows Server 2008 Enterprise and Windows Server 2008 Datacenter. It is not included in Windows Server 2008 Standard or Windows Web Server 2008.

  • Checklist: Create a Failover Cluster

  • Checklist: Create a Clustered File Server

  • Checklist: Create a Clustered Print Server

  • Installing Failover Clustering

  • Validating a Failover Cluster Configuration

  • Creating a Failover Cluster or Adding a Cluster Node

  • Configuring a Service or Application for High Availability

  • Migrating Settings from a Server Cluster Running Windows Server 2003

  • Modifying Settings for a Failover Cluster

  • Managing a Failover Cluster

  • Resources for Failover Clusters

  • User Interface: The Failover Cluster Management Snap-In

Additional references

  • For a list of links to a variety of topics about failover clusters, see http://go.microsoft.com/fwlink/?LinkId=68633.

  • For design and deployment information for failover clusters, see http://go.microsoft.com/fwlink/?LinkId=86168.

  • For troubleshooting information for failover clusters, see http://go.microsoft.com/fwlink/?LinkId=86170.

  • For operations information for failover clusters, see http://go.microsoft.com/fwlink/?LinkId=86169.


Checklist: Create a Failover Cluster

If you want to provide high availability for users of one or more file shares, see a more complete checklist at Checklist: Create a Clustered File Server.

If you want to provide high availability for users of one or more print servers, see a more complete checklist at Checklist: Create a Clustered Print Server.

 | Step | Reference
Check box | Review hardware and infrastructure requirements for a failover cluster. | Understanding Requirements for Failover Clusters
Check box | Install the failover cluster feature on every server that will be in the cluster. | Install Failover Clustering
Check box | Connect the networks and storage that the cluster will use. | Prepare Hardware Before Validating a Failover Cluster
Check box | Run the Validate a Configuration Wizard to confirm that the hardware and hardware settings of the servers, network, and storage are compatible with failover clustering. If necessary, adjust hardware or hardware settings and rerun the wizard. | Validate a New or Existing Failover Cluster
Check box | Create the failover cluster. | Create a New Failover Cluster

After you have created a failover cluster, the next step is usually to configure the cluster to support a particular service or application. For more information, see Configuring a Service or Application for High Availability.

Additional references

  • Overview of Failover Clusters

  • For design and deployment information for failover clusters, see http://go.microsoft.com/fwlink/?LinkId=86168.


Checklist: Create a Clustered File Server

 | Step | Reference
Check box | Review hardware and infrastructure requirements for a failover cluster. | Understanding Requirements for Failover Clusters
Check box | Install the failover cluster feature on every server that will be in the cluster. | Install Failover Clustering
Check box | Connect the networks and storage that the cluster will use. | Prepare Hardware Before Validating a Failover Cluster
Check box | Run the Validate a Configuration wizard to confirm that the hardware and hardware settings of the servers, network, and storage are compatible with failover clustering. If necessary, adjust hardware or hardware settings and rerun the wizard. | Validate a New or Existing Failover Cluster
Check box | Create the failover cluster. | Create a New Failover Cluster
Check box | If the clustered servers are connected to a network that is not to be used for network communication in the cluster (for example, a network intended only for iSCSI or only for backup), then configure that network so that it does not allow cluster communication. | Modify Network Settings for a Failover Cluster
Check box | Run the High-Availability Wizard and specify the File Server role, a name for the clustered file server, and IP address information that is not automatically supplied by your DHCP settings. Also specify the storage volume or volumes. | Configure a Service or Application for High Availability
Check box | Add shared folders to the clustered file server as needed. | Create a Shared Folder in a Clustered File Server
Check box | Test failover of the clustered file server. | Test Failover of a Clustered Service or Application

Additional references

  • Overview of Failover Clusters

  • Modify Failover Settings for a Clustered Service or Application

  • For design and deployment information for failover clusters, see http://go.microsoft.com/fwlink/?LinkId=86168.


Checklist: Create a Clustered Print Server

 | Step | Reference
Check box | On every server that will be in the cluster, open Server Manager, click Add roles and then use the Add Roles Wizard to add the Print Services role and any role services that are needed. | Help in Server Manager
Check box | Review hardware and infrastructure requirements for a failover cluster. | Understanding Requirements for Failover Clusters
Check box | Install Failover Clustering on every server that will be in the cluster. | Install Failover Clustering
Check box | Connect the networks and storage that the cluster will use. | Prepare Hardware Before Validating a Failover Cluster
Check box | Run the Validate a Configuration Wizard to confirm that the hardware and hardware settings of the servers, network, and storage are compatible with failover clustering. If necessary, adjust hardware or hardware settings and rerun the wizard. | Validate a New or Existing Failover Cluster
Check box | Create the failover cluster. | Create a New Failover Cluster
Check box | If the clustered servers are connected to a network that is not to be used for network communication in the cluster (for example, a network intended only for iSCSI or only for backup), then configure that network so that it does not allow cluster communication. | Modify Network Settings for a Failover Cluster
Check box | Run the High-Availability Wizard and specify the Print Server role, a name for the clustered print server, and IP address information that is not automatically supplied by your DHCP settings. | Configure a Service or Application for High Availability
Check box | Configure print settings such as the setting that specifies the printer. | Configure Print Settings for a Clustered Print Server
Check box | Test failover of the clustered print server. | Test Failover of a Clustered Service or Application
Check box | From a client, print a test page on the clustered print server. | Help for the operating system on the client (for specifying the path to the clustered print server) Help from the application from which you print the test page

Additional references

  • Overview of Failover Clusters

  • Modify Failover Settings for a Clustered Service or Application

  • For design and deployment information for failover clusters, see http://go.microsoft.com/fwlink/?LinkId=86168.


Installing Failover Clustering

Before you can create a failover cluster, you must install Failover Clustering on all servers that you want to include in the cluster. This section provides instructions for installing this feature.

Note that the Failover Clustering feature is included in Windows Server 2008 Enterprise and Windows Server 2008 Datacenter. It is not included in Windows Server 2008 Standard or Windows Web Server 2008.

Install Failover Clustering


Install Failover Clustering

You can install Failover Clustering on Windows Server 2008 Enterprise or Windows Server 2008 Datacenter by using the Add Features command from Initial Configuration Tasks or from Server Manager.

Membership in the local Administrators group, or equivalent, is the minimum required to complete this procedure. Review details about using the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/?LinkId=83477.

To install the failover cluster feature

  1. If you recently installed Windows Server 2008 on the server and the Initial Configuration Tasks interface is displayed, under Customize This Server, click Add features. (Skip to Step 3.)

  2. If Initial Configuration Tasks is not displayed, add the feature through Server Manager:

    • If Server Manager is already running, under Features Summary, click Add Features.

    • If Server Manager is not running, click Start, click Administrative Tools, click Server Manager, and then, if prompted for permission to continue, click Continue. Then, under Features Summary, click Add Features.

  3. In the Add Features Wizard, click Failover Clustering and then click Install.

  4. When the wizard finishes, close it.

  5. Repeat the process for each server that you want to include in the cluster.

Additional considerations

  • The Failover Clustering feature is included in Windows Server 2008 Enterprise and Windows Server 2008 Datacenter. It is not included in Windows Server 2008 Standard or Windows Web Server 2008.

Additional references

  • Overview of Failover Clusters


Validating a Failover Cluster Configuration

Before you create a failover cluster, we strongly recommend that you validate your configuration, that is, that you run all tests in the Validate a Configuration Wizard. By running the tests, you can confirm that your hardware and settings are compatible with failover clustering.

You can run the tests on a set of servers and storage devices either before or after you have configured them as a failover cluster.

Important

Microsoft supports a failover cluster solution only if the complete configuration (servers, network, and storage) can pass all tests in the Validate a Configuration wizard. In addition, all hardware components in the solution must be marked as "Certified for Windows Server 2008."

With the Validate a Configuration Wizard, you can run the complete set of configuration tests or a subset of the tests. The wizard provides a report that shows the result of each test that was run.

  • Understanding Requirements for Failover Clusters

  • Understanding Microsoft Support of Cluster Solutions

  • Understanding Cluster Validation Tests

  • Prepare Hardware Before Validating a Failover Cluster

  • Validate a New or Existing Failover Cluster

Additional references

  • Use Validation Tests for Troubleshooting a Failover Cluster

  • For troubleshooting information for failover clusters, see http://go.microsoft.com/fwlink/?LinkId=86170.

  • For design and deployment information for failover clusters, see http://go.microsoft.com/fwlink/?LinkId=86168.


Understanding Requirements for Failover Clusters

A failover cluster must meet certain requirements for hardware, software, and network infrastructure, and it requires an administrative account with the appropriate domain permissions. The following sections provide information about these requirements.

  • Hardware requirements for a failover cluster

    • Deploying storage area networks with failover clusters

  • Software requirements for a failover cluster

  • Network infrastructure and domain account requirements for a failover cluster

For additional information about hardware compatibility for Windows Server 2008, see http://go.microsoft.com/fwlink/?LinkID=59821.

Hardware requirements for a failover cluster

You need the following hardware in a failover cluster:

  • Servers: We recommend that you use a set of matching computers that contain the same or similar components.

    Important

    Microsoft supports a failover cluster solution only if all the hardware components are marked as "Certified for Windows Server 2008." In addition, the complete configuration (servers, network, and storage) must pass all tests in the Validate a Configuration wizard, which is included in the Failover Cluster Management snap-in.

    For information about hardware compatibility for Windows Server 2008, see http://go.microsoft.com/fwlink/?LinkID=59821.

    For information about the maximum number of servers that you can have in a failover cluster, see http://go.microsoft.com/fwlink/?LinkId=92091.

  • Network adapters and cable (for network communication): The network hardware, like other components in the failover cluster solution, must be marked as "Certified for Windows Server 2008." If you use iSCSI, your network adapters must be dedicated to either network communication or iSCSI, not both.

    In the network infrastructure that connects your cluster nodes, avoid having single points of failure. There are multiple ways of accomplishing this. You can connect your cluster nodes by multiple, distinct networks. Alternatively, you can connect your cluster nodes with one network that is constructed with teamed network adapters, redundant switches, redundant routers, or similar hardware that removes single points of failure.

    Note

    If you connect cluster nodes with a single network, the network will pass the redundancy requirement in the Validate a Configuration Wizard. However, the report from the wizard will include a warning that the network should not have single points of failure.

    For more details about the network configuration required for a failover cluster, see Network infrastructure and domain account requirements for a failover cluster, later in this topic.

  • Device controllers or appropriate adapters for the storage:

    • For Serial Attached SCSI or Fibre Channel: If you are using Serial Attached SCSI or Fibre Channel, in all clustered servers, the mass-storage device controllers that are dedicated to the cluster storage should be identical. They should also use the same firmware version.

      Note

      With Windows Server 2008, you cannot use parallel SCSI to connect the storage to the clustered servers.

    • For iSCSI: If you are using iSCSI, each clustered server must have one or more network adapters or host bus adapters that are dedicated to the cluster storage. The network you use for iSCSI cannot be used for network communication. In all clustered servers, the network adapters you use to connect to the iSCSI storage target should be identical, and we recommend that you use Gigabit Ethernet or higher.

      For iSCSI, you cannot use teamed network adapters, because they are not supported with iSCSI.

      For more information about iSCSI, see the iSCSI FAQ on the Microsoft Web site (http://go.microsoft.com/fwlink/?LinkId=61375).

  • Storage: You must use shared storage that is compatible with Windows Server 2008.

    In most cases, the storage should contain multiple, separate disks (LUNs) that are configured at the hardware level. For some clusters, one disk functions as the witness disk (described at the end of this subsection). Other disks contain the files required for the clustered services or applications. Storage requirements include the following:

    • To use the native disk support included in failover clustering, use basic disks, not dynamic disks.

    • We recommend that you format the partitions with NTFS (for the witness disk, the partition must be NTFS).

    • For the partition style of the disk, you can use either master boot record (MBR) or GUID partition table (GPT).

    A witness disk is a disk in the cluster storage that is designated to hold a copy of the cluster configuration database. A failover cluster has a witness disk only if this is specified as part of the quorum configuration. For more information, see Understanding Quorum Configurations in a Failover Cluster.

Deploying storage area networks with failover clusters

When deploying a storage area network (SAN) with a failover cluster, follow these guidelines:

  • Confirm compatibility of the storage: Confirm with manufacturers and vendors that the storage, including drivers, firmware, and software used for the storage, are compatible with failover clusters in Windows Server 2008.

    Important

    Storage that was compatible with server clusters in Windows Server 2003 might not be compatible with failover clusters in Windows Server 2008. Contact your vendor to ensure that your storage is compatible with failover clusters in Windows Server 2008.

    Failover clusters include the following new requirements for storage:

    • Improvements in failover clusters require that the storage respond correctly to specific SCSI commands. To confirm that your storage is compatible, run the Validate a Configuration Wizard. In addition, you can contact the storage vendor.

    • The miniport driver used for the storage must work with the Microsoft Storport storage driver.

  • Isolate storage devices, one cluster per device: Servers from different clusters must not be able to access the same storage devices. In most cases, a LUN used for one set of cluster servers should be isolated from all other servers through LUN masking or zoning.

  • Consider using multipath I/O software: In a highly available storage fabric, you can deploy failover clusters with multiple host bus adapters by using multipath I/O software. This provides the highest level of redundancy and availability. For Windows Server 2008, your multipath solution must be based on Microsoft Multipath I/O (MPIO). Your hardware vendor will usually supply an MPIO device-specific module (DSM) for your hardware, although Windows Server 2008 includes one or more DSMs as part of the operating system.

    Important

    Host bus adapters and multipath I/O software can be very version sensitive. If you are implementing a multipath solution for your cluster, you should work closely with your hardware vendor to choose the correct adapters, firmware, and software for Windows Server 2008.

Software requirements for a failover cluster

All the servers in a failover cluster must run the same version of Windows Server 2008. The servers can run any of the following versions of the operating system:

  • Windows Server 2008 Enterprise

  • Windows Server 2008 Datacenter

  • A Server Core installation of Windows Server 2008 Enterprise

  • A Server Core installation of Windows Server 2008 Datacenter

In addition, all the servers must run the same hardware version of the operating system (32-bit, x64-based, or Itanium architecture-based). For example, if one server is running the x64-based version of Windows Server 2008 Enterprise, all the servers in the failover cluster must run that version.

All servers should also have the same software updates (patches) and service packs.

Network infrastructure and domain account requirements for a failover cluster

You will need the following network infrastructure for a failover cluster and an administrative account with the following domain permissions:

  • Network settings and IP addresses: When you use identical network adapters for a network, also use identical communication settings on those adapters (for example, Speed, Duplex Mode, Flow Control, and Media Type). Also, compare settings between the network adapter and the switch it connects to and make sure that no settings are in conflict.

    If you have private networks that are not routed to the rest of your network infrastructure, ensure that each of these private networks uses a unique subnet. This is necessary even if you give each network adapter a unique IP address. For example, if you have two cluster nodes in a central office that uses one physical network, and two more nodes in a branch office that uses a separate physical network, do not specify 10.0.0.0/24 for both networks, even if you give each adapter a unique IP address.

    For more information about the network adapters, see Hardware Requirements for a Failover Cluster, earlier in this topic.

  • DNS: The servers in the cluster must be using Domain Name System (DNS) for name resolution. The DNS dynamic update protocol can be used.

  • Domain role: All servers in the cluster must be in the same Active Directory domain. As a best practice, all clustered servers should have the same domain role (either member server or domain controller). The recommended role is member server.

  • Domain controllers: We recommend that your clustered servers be member servers. If they are, other servers will be the domain controllers in the domain that contains your failover cluster.

  • Clients: There are no specific requirements for clients, other than the obvious requirements for connectivity and compatibility: the clients must be able to connect to the clustered servers, and they must run software that is compatible with the services offered by the clustered servers.

  • Account for administering the cluster: When you first create a cluster or add servers to it, you must be logged on to the domain with an account that has administrator rights and permissions on all servers in that cluster. The account does not need to be a Domain Admins account—it can be a Domain Users account that is in the Administrators group on each clustered server. In addition, if the account is not a Domain Admins account, the account (or the group that the account is a member of) must be delegated Create Computer Objects permission in the domain.

    Note

    There is a change in the way the Cluster service runs in Windows Server 2008, as compared to Windows Server 2003. In Windows Server 2008, there is no Cluster service account. Instead, the Cluster service automatically runs in a special context that provides the specific permissions and privileges necessary for the service (similar to the local system context, but with reduced privileges).

Additional references

  • Validating a Failover Cluster Configuration

  • Overview of Failover Clusters

  • For information about hardware compatibility for Windows Server 2008, see http://go.microsoft.com/fwlink/?LinkID=59821.

  • For design and deployment information for failover clusters, see http://go.microsoft.com/fwlink/?LinkId=86168.


Understanding Microsoft Support of Cluster Solutions

Microsoft supports a failover cluster solution only if it meets the following requirements:

  • All hardware components in the failover cluster solution are marked as "Certified for Windows Server 2008."

  • The complete cluster configuration (servers, network, and storage) can pass all tests in the Validate a Configuration Wizard.

  • The hardware manufacturers' recommendations for firmware updates and software updates (patches) have been followed. Usually, this means that the latest firmware and software updates have been applied. Occasionally, a manufacturer might recommend specific updates other than the latest updates.

Additional references

  • Understanding Requirements for Failover Clusters

  • Validating a Failover Cluster Configuration

  • For information about hardware compatibility for Windows Server 2008, see http://go.microsoft.com/fwlink/?LinkID=59821.

  • For design and deployment information for failover clusters, see http://go.microsoft.com/fwlink/?LinkId=86168.


Understanding Cluster Validation Tests

With the Validate a Configuration Wizard, you can run tests to confirm that your hardware and hardware settings are compatible with failover clustering. You can run the complete set of configuration tests or a subset of the tests.

We recommend that you run the tests on your set of servers and storage devices before you configure them as a failover cluster (create a cluster from them). You can also run the tests after you create a cluster.

Note that the Failover Clustering feature must be installed on all the servers that you want to include in the tests.

Important

Microsoft supports a failover cluster solution only if the complete configuration (servers, network, and storage) can pass all tests in the Validate a Configuration wizard. In addition, all hardware components in the solution must be marked as "Certified for Windows Server 2008."

The Validate a Configuration Wizard includes four types of tests:

  • Inventory tests. Provide an inventory of the hardware, software, and settings (such as network settings) on the servers, and information about the storage. For more information, see Understanding Cluster Validation Tests: Inventory.

  • Network tests. Validate that your networks are set up correctly for clustering. For more information, see Understanding Cluster Validation Tests: Network.

  • Storage tests. Validate that the storage on which the failover cluster depends is behaving correctly and supports the required functions of the cluster. For more information, see Understanding Cluster Validation Tests: Storage.

  • System Configuration tests. Validate that system software and configuration settings are compatible across servers. For more information, see Understanding Cluster Validation Tests: System Configuration.

The report from the Validate a Configuration Wizard includes one of the following messages about each test:

  • The tested item meets requirements for a failover cluster.

  • The tested item might meet the requirements, but there is a warning about something that you should check.

  • The test item does not meet requirements.

  • The test could not be run (for example, if you are testing a single node by itself, certain tests do not run).

Additional references

  • Validating a Failover Cluster Configuration

  • For information about hardware compatibility for Windows Server 2008, see http://go.microsoft.com/fwlink/?LinkID=59821.

  • For design and deployment information for failover clusters, see http://go.microsoft.com/fwlink/?LinkId=86168.

  • For troubleshooting information for failover clusters, see http://go.microsoft.com/fwlink/?LinkId=86170.


Understanding Cluster Validation Tests: Inventory

Inventory tests provide lists of information about the hardware, software, and settings on each of the servers you are testing. You can use inventory tests alone (without other tests in the Validate a Cluster Configuration Wizard) to review or record the configuration of hardware (for example, to review that the software updates on each server are identical after you perform scheduled maintenance).

You can run the following inventory tests by using the Validate a Configuration Wizard:

  • List BIOS Information

  • List Environment Variables: Examples of environment variables are the number of processors, the operating system path, and the location of temporary folders.

  • List Fibre Channel Host Bus Adapters

  • List iSCSI Host Bus Adapters

  • List Memory Information

  • List Operating System Information

  • List Plug and Play Devices

  • List Running Processes

  • List SAS Host Bus Adapters: This test lists the host bus adapters for Serial Attached SCSI (SAS).

  • List Services Information: As a general best practice for servers, especially cluster nodes, you should run only necessary services.

  • List Software Updates: You can use this test to help correct issues that are uncovered by one of the System Configuration tests, Validate Software Update Levels. For more information, see Understanding Cluster Validation Tests: System Configuration.

  • List System Drivers

  • List System Information: The system information includes the following:

    • Computer name

    • Manufacturer, model, and type

    • Account name of the person who ran the validation tests

    • Domain that the computer is in

    • Time zone and daylight time setting (determines whether the clock is adjusted for daylight time changes)

    • Number of processors

  • List Unsigned Drivers: You can use this test to help correct issues that are uncovered by one of the System Configuration tests, Validate All Drivers Signed. For more information, see Understanding Cluster Validation Tests: System Configuration.

Additional references

  • Understanding Cluster Validation Tests

  • Validating a Failover Cluster Configuration

  • For information about hardware compatibility for Windows Server 2008, see http://go.microsoft.com/fwlink/?LinkID=59821.


Understanding Cluster Validation Tests: Network

Network tests help you confirm that the correct network infrastructure is in place for a failover cluster.

Correcting issues uncovered by network tests

For information about how to correct the issues that are revealed by network tests, see:

  • Prepare Hardware Before Validating a Failover Cluster

  • Understanding Requirements for Failover Clusters

For additional information about hardware compatibility for Windows Server 2008, see http://go.microsoft.com/fwlink/?LinkID=59821.

Network tests in the Validate a Configuration Wizard

You can run the following network tests by using the Validate a Configuration Wizard:

  • Validate Cluster Network Configuration includes the following tasks:

    • Lists the cluster networks, that is, the network topology as seen from the perspective of the cluster.

    • Validates that, for a particular cluster network, all network adapters are provided with IP addresses in the same way (that is, all use static IP addresses or all use DHCP).

    • Validates that, for a particular cluster network, all network adapters use the same version of IP (that is, all use IPv4, all use IPv6, or all use both IPv4 and IPv6).

  • Validate IP Configuration includes the following tasks:

    • Lists the IP configuration details.

    • Validates that IP addresses are unique in the cluster (no duplication).

    • Checks the number of network adapters on each tested server. If only one adapter is found, the report provides a warning about avoiding single points of failure in the network infrastructure that connects clustered servers.

      There are multiple ways of avoiding single points of failure. You can connect your cluster nodes by multiple, distinct networks. Alternatively, you can connect your cluster nodes with one network that is constructed with teamed network adapters, redundant switches, redundant routers, or similar hardware that removes single points of failure.

    • Validates that no tested servers have multiple adapters on the same IP subnet.

    • Validates that all tested servers use the same version of IP (that is, all use IPv4, all use IPv6, or all use both IPv4 and IPv6).

  • Validate Network Communication: This test validates that tested servers can communicate with acceptable latency on all networks. The test also checks to see if there are redundant communication paths between all servers. Communication between the nodes of a cluster enables the cluster to detect node failures and status changes and to manage the cluster as a single entity.

  • Validate Windows Firewall Configuration: This test validates that Windows Firewall is configured correctly for failover clustering on the tested servers.

Additional references

  • Understanding Cluster Validation Tests

  • Understanding Requirements for Failover Clusters

  • Prepare Hardware Before Validating a Failover Cluster

  • Validating a Failover Cluster Configuration

  • For additional information about hardware compatibility for Windows Server 2008, see http://go.microsoft.com/fwlink/?LinkID=59821.


Understanding Cluster Validation Tests: Storage

Storage tests analyze the storage to determine whether it will work correctly for a failover cluster running Windows Server 2008.

Correcting issues uncovered by storage tests

If a storage test indicates that your storage or your storage configuration will not support a failover cluster, review the following suggestions:

  • Contact your storage vendor and use the utilities provided with your cluster storage to gather information about the configuration. (In unusual cases, your storage vendor might indicate that your cluster solution is supported even though this is not reflected in the storage tests. For example, your cluster solution might have been specifically designed to work without shared storage.)

  • Review results from multiple tests in the Validate a Configuration Wizard, such as the List Host Bus Adapters test (see the topic Understanding Cluster Validation Tests: Inventory) and two tests that are described in this topic, List All Disks and List Cluster Disks.

  • Look for a storage validation test that is related to the one that uncovered the issue. For example, if Validate Multiple Arbitration uncovered an issue, the related test, Validate Disk Arbitration, might provide useful information.

  • Review the storage requirements in Understanding Requirements for Failover Clusters.

    For information about hardware compatibility for Windows Server 2008, see http://go.microsoft.com/fwlink/?LinkID=59821.

  • Review the documentation for your storage, or contact the manufacturer.

Storage tests in the Validate a Configuration Wizard

You can run the following storage tests by using the Validate a Configuration Wizard:

  • List All Disks

  • List Potential Cluster Disks

  • Validate Disk Access Latency

  • Validate Disk Arbitration

  • Validate Disk Failover

  • Validate File System

  • Validate Microsoft MPIO-Based Disks

  • Validate Multiple Arbitration

  • Validate SCSI Device Vital Product Data (VPD)

  • Validate SCSI-3 Persistent Reservation

  • Validate Simultaneous Failover

List All Disks

This test lists all disks that are visible to one or more tested servers. The test lists:

  • Disks that can support clustering and can be accessed by all the servers.

  • Disks on an individual server.

The following information is listed for each disk:

  • Disk number

  • Unique identifier

  • Bus type

  • Stack type

  • Disk address (where applicable), including the port, path, target identifier (TID), and Logical Unit Number (LUN)

  • Adapter description

  • Disk characteristics such as the partition style and partition type

You can use this test to help diagnose issues uncovered by other storage tests described in this topic.

List Potential Cluster Disks

This test lists disks that can support clustering and are visible to all tested servers. To support clustering, the disk must be connected through Serial Attached SCSI (SAS), iSCSI, or Fibre Channel. In addition, the test validates that multipath I/O is working correctly, meaning that each of the disks is seen as one disk, not two.
Types of disks not listed by the test

This test lists only disks that can be used for clustering. The disks that it lists must:

  • Be connected through Serial Attached SCSI (SAS), iSCSI, or Fibre Channel.

  • Be visible to all servers in the cluster.

  • Be accessed through a host bus adapter that supports clustering.

  • Not be a boot volume or system volume.

  • Not be used for paging files, hibernation, or dump files. (Dump files record the contents of memory when the system stops unexpectedly.)

Validate Disk Access Latency

This test validates that the latency for disk read and write operations is within an acceptable limit for a failover cluster. If disk read and write operations take too long, one possible result is that cluster time-outs might be triggered. Another possible result is that the application attempting to access the disk might appear to have failed, and the cluster might initiate a needless failover.

Validate Disk Arbitration

This test validates that:

  • Each of the clustered servers can use the arbitration process to become the owner of each of the cluster disks.

  • When a particular server owns a disk, if one or more other servers arbitrate for that disk, the original owner retains ownership.

If a clustered server cannot become the owner of a disk, or it cannot retain ownership when other clustered servers arbitrate for the disk, various issues might result:

  • The disk could have no owner and therefore be unavailable.

  • The disk could have two owners at the same time and therefore become corrupted.

    Failover cluster servers are designed to operate in circumstances where only one server owns a disk at a time. If multiple servers could own a disk at the same time, they might perform write operations in an uncoordinated way, possibly corrupting the disk.

  • The disk could change owners every time arbitration occurs, which would interfere with disk availability.

Validate Disk Failover

This test validates that disk failover works correctly in the cluster. Specifically, the test validates that when a disk owned by one clustered server is failed over, the server that takes ownership of the disk can read it. The test also validates that information written to the disk before the failover is still the same after the failover.

If disk failover occurs but the server that takes ownership of a disk cannot read it, the cluster cannot maintain availability of the disk. If information written to the disk is changed during the process of failover, it could cause issues for users or software that require this information. In either case, if the affected disk is a witness disk (a disk that stores cluster configuration data and participates in quorum), such issues could cause the cluster to lose quorum and shut down.

If this test reveals that disk failover does not work correctly, the results of the following tests might help you identify the cause of the issue:

  • Validate SCSI-3 Persistent Reservation

  • Validate Disk Arbitration

  • Validate Multiple Arbitration

Validate File System

This test validates that the file system on disks in shared storage is supported by failover clusters.

Validate Microsoft MPIO-Based Disks

This test validates that multi-path disks (Microsoft MPIO-based disks) have been configured correctly for failover cluster.

Validate Multiple Arbitration

This test validates that when multiple clustered servers arbitrate for a cluster disk, only one server obtains ownership.

If multiple clustered servers could obtain ownership of a cluster disk through disk arbitration, the disk might become corrupted. Failover clusters are designed to operate in circumstances where only one clustered server owns a disk at a time. If multiple servers could own a disk at the same time, they might perform write operations in an uncoordinated way, possibly corrupting the disk.

If this test reveals that multiple clustered servers can obtain ownership of a cluster disk through disk arbitration, the results of the following test might help you identify the cause of the issue:

  • Validate SCSI-3 Persistent Reservation

Validate SCSI Device Vital Product Data (VPD)

This test validates that the storage supports necessary SCSI inquiry data (VPD descriptors) and that they are unique.

Validate SCSI-3 Persistent Reservation

This test validates that the cluster storage uses the more recent (SCSI-3 standard) Persistent Reserve commands (which are different from the older SCSI-2 standard reserve/release commands). The Persistent Reserve commands avoid SCSI bus resets, which means they are much less disruptive than the older reserve/release commands. Therefore, a failover cluster can be more responsive in a variety of situations, as compared to a cluster running an earlier version of the operating system. In addition, disks are never left in an unprotected state, which lowers the risk of volume corruption.

Validate Simultaneous Failover

This test validates that simultaneous disk failovers work correctly in the cluster. Specifically, the test validates that even when multiple disk failovers occur at the same time, any clustered server that takes ownership of a disk can read it. The test also validates that information written to each disk before a failover is still the same after the failover.

If disk failover occurs but the server that takes ownership of a disk cannot read it, the cluster cannot maintain availability of the disk. If information written to the disk is changed during the process of failover, it could cause issues for users or software that require this information. In either case, if the affected disk is a witness disk (a disk that stores cluster configuration data and participates in quorum), such issues could cause the cluster to lose quorum and shut down.

If this test reveals that disk failover does not work correctly, the results of the following tests might help you identify the cause of the issue:

  • Validate Disk Failover

  • Validate Disk Arbitration

  • Validate Multiple Arbitration

Additional references

  • Understanding Cluster Validation Tests

  • Understanding Requirements for Failover Clusters

  • Prepare Hardware Before Validating a Failover Cluster

  • Validating a Failover Cluster Configuration

  • For additional information about hardware compatibility for Windows Server 2008, see http://go.microsoft.com/fwlink/?LinkID=59821.


Understanding Cluster Validation Tests: System Configuration

System configuration tests analyze the selected servers to determine whether they are properly configured for working together in a failover cluster. The system configuration tests include the following:

  • Validate Active Directory Configuration: This test validates that each tested server is in the same domain and organizational unit. It also validates that all tested servers are domain controllers or that all are member servers. To change the domain role of a server, use the Active Directory® Domain Services Installation Wizard.

  • Validate All Drivers Signed: This test validates that all tested servers contain only signed drivers. If an unsigned driver is detected, the test is not considered a failure, but a warning is issued.

    The purpose of signing drivers is to tell you whether the drivers on your system are original, unaltered files that either came with the operating system or were supplied by a vendor.

    You can get a list of system drivers and a list of unsigned drivers by running the corresponding inventory tasks. For more information, see Understanding Cluster Validation Tests: Inventory.

  • Validate Operating System Versions: This test validates that all tested servers have the same operating system version.

  • Validate Required Services: This test validates that the services that are required for failover clustering are running on each tested server and are configured to start automatically whenever the server is restarted.

  • Validate Same Processor Architecture: This test validates that all tested servers have the same architecture. A failover cluster is supported only if the systems in it are all 32-bit systems or all 64-bit systems.

  • Validate Service Pack Levels: This test validates that all tested servers have the same service packs. A failover cluster can run even if some servers have different service packs than others. However, servers with different service packs might behave differently from each other, with unexpected results. We recommend that all servers in the failover cluster have the same service packs.

  • Validate Software Update Levels: This test validates that all tested servers have the same software updates. A failover cluster can run even if some servers have different updates than others. However, servers with different software updates might behave differently from each other, with unexpected results. We recommend that all servers in the failover cluster have the same software update levels.

Additional references

  • Understanding Cluster Validation Tests

  • Validating a Failover Cluster Configuration

  • For information about hardware compatibility for Windows Server 2008, see http://go.microsoft.com/fwlink/?LinkID=59821.


Prepare Hardware Before Validating a Failover Cluster

Before running the Validate a Configuration Wizard for a failover cluster, you should make preparations such as connecting the networks and storage needed by the cluster. This topic briefly describes these preparations. For a full list of the requirements for a failover cluster, see Understanding Requirements for Failover Clusters.

In most cases, membership in the local Administrators group on each server, or equivalent, is the minimum required to complete this procedure. This is because the procedure includes steps for configuring networks and storage. Review details about using the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/?LinkId=83477.

To prepare hardware before validating a failover cluster

  1. Confirm that your entire cluster solution, including drivers, is compatible with Windows Server 2008 by checking the hardware compatibility information on the Microsoft Web site (http://go.microsoft.com/fwlink/?LinkID=59821).

    Important

    Microsoft supports a failover cluster solution only if all the hardware components are marked as "Certified for Windows Server 2008." In addition, the complete configuration (servers, network, and storage) must pass all tests in the Validate a Configuration wizard, which is included in the Failover Cluster Management snap-in.

    We recommend that you use a set of matching computers that contain the same or similar components.

  2. For the cluster networks:

    1. Review the details about networks in Understanding Requirements for Failover Clusters.

    2. Connect and configure the networks that the servers in the cluster will use.

      Note

      One option for configuring cluster networks is to create a preliminary network configuration, then run the Validate a Configuration Wizard with only the Network tests selected (avoid selecting Storage tests). When only the Network tests are run, the process does not take a long time. Using the validation report, you can make any corrections still needed in the network configuration. (Later, after the storage is configured, you should run the wizard with all tests.)

  3. For the storage:

    1. Review the details about storage in Understanding Requirements for Failover Clusters.

    2. Follow the manufacturer's instructions for physically connecting the servers to the storage.

  4. Ensure that the disks (LUNs) that you want to use in the cluster are exposed to the servers you will cluster (and only those servers). You can use any of the following interfaces to expose disks or LUNs:

    • Microsoft Storage Manager for SANs (part of the operating system in Windows Server 2008). To use this interface, you need to contact the manufacturer of your storage for a Virtual Disk Service (VDS) provider package that is designed for your storage.

    • If you are using iSCSI, an appropriate iSCSI interface.

    • The interface provided by the manufacturer of the storage.

  5. If you have purchased software that controls the format or function of the disk, obtain instructions from the vendor about how to use that software with Windows Server 2008.

  6. On one of the servers that you want to cluster, click Start, click Administrative Tools, click Computer Management, and then click Disk Management. (If the User Account Control dialog box appears, confirm that the action it displays is what you want, and then click Continue.) In Disk Management, confirm that the cluster disks are visible.

  7. If you want to have a storage volume larger than 2 terabytes, and you are using the Windows interface to control the format of the disk, convert that disk now to the partition style called GUID partition table (GPT). To do this, back up any data on the disk, delete all volumes on the disk and then, in Disk Management, right-click the disk (not a partition) and click Convert to GPT Disk.

    For volumes smaller than 2 terabytes, instead of using GPT, you can use the partition style called master boot record (MBR).

    Important

    You can use either MBR or GPT for a disk used by a failover cluster, but you cannot use a disk that you converted to dynamic by using Disk Management.

  8. Check the format of any exposed volume or LUN. We recommend NTFS for the format (for the witness disk, you must use NTFS).

  9. As appropriate, make sure that there is connectivity from the servers to be clustered to any nonclustered domain controllers. (Connectivity to clients is not necessary for validation, and it can be established later.)

Additional references

  • Understanding Microsoft Support of Cluster Solutions

  • Understanding Requirements for Failover Clusters

  • For information about hardware compatibility for Windows Server 2008, see http://go.microsoft.com/fwlink/?LinkID=59821.

  • For design and deployment information for failover clusters, see http://go.microsoft.com/fwlink/?LinkId=86168.


Validate a New or Existing Failover Cluster

Before creating a failover cluster, we recommend that you validate your hardware (servers, networks, and storage) by running the Validate a Configuration Wizard. You can validate either an existing cluster or one or more servers that are not yet clustered.

Important

Microsoft supports a failover cluster solution only if the complete configuration (servers, network, and storage) can pass all tests in the Validate a Configuration wizard. In addition, all hardware components in the solution must be marked as "Certified for Windows Server 2008."

Membership in the local Administrators group, or equivalent, is the minimum required to complete this procedure. Review details about using the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/?LinkId=83477.

To validate a new or existing failover cluster

  1. Identify the server or servers that you want to test and confirm that the failover cluster feature is installed:

    • If the cluster does not yet exist, choose the servers that you want to include in the cluster, and make sure you have installed the failover cluster feature on those servers. For more information, see Install Failover Clustering.

      Note that when you run the Validate a Configuration Wizard on unclustered servers, you must enter the names of all the servers you want to test, not just one.

    • If the cluster already exists, make sure you know the name of the cluster or a node in the cluster.

  2. Review network or storage hardware that you want to validate, to confirm that it is connected to the servers. For details, see Prepare Hardware Before Validating a Failover Cluster and Understanding Requirements for Failover Clusters.

  3. Decide whether you want to run all or only some of the available validation tests. For detailed information about the tests, see the topics listed in Understanding Cluster Validation Tests.

    The following guidelines can help you decide whether to run all tests:

    • For a planned cluster with all hardware connected: Run all tests.

    • For a planned cluster with parts of the hardware connected: Run System Configuration tests, Inventory tests, and tests that apply to the hardware that is connected (that is, Network tests if the network is connected or Storage tests if the storage is connected).

    • For a cluster to which you plan to add a server: Run all tests. When you run them, be sure to include all servers that you plan to have in the cluster.

    • For troubleshooting an existing cluster: If you are troubleshooting an existing cluster, you might run all tests, although you could run only the tests that relate to the apparent issue.

      Important

      If a clustered service or application is using a disk when you start the wizard, the wizard will prompt you about whether to take that clustered service or application offline for the purposes of testing. If you choose to take a clustered service or application offline, it will remain offline until the tests finish.

  4. In the Failover Cluster Management snap-in, in the console tree, make sure Failover Cluster Management is selected and then, under Management, click Validate a Configuration.

  5. Follow the instructions in the wizard to specify the servers and the tests, run the tests, and view the results.

    Note that when you run the Validate a Configuration Wizard on unclustered servers, you must enter the names of all the servers you want to test, not just one.

Additional considerations

  • To open the failover cluster snap-in, click Start, click Administrative Tools, and then click Failover Cluster Management. If the User Account Control dialog box appears, confirm that the action it displays is what you want, and then click Continue.

  • To view the results of the tests after you close the wizard, choose one of the following:

    • Open the folder systemroot\Cluster\Reports (on a clustered server).

    • If the tested servers are now a cluster, in the console tree, right-click the cluster, and then click View Validation Report. This displays the most recent validation report for that cluster.

Additional references

  • Install Failover Clustering

  • Understanding the Migration Process from a Cluster Running Windows Server 2003

  • Prepare Hardware Before Validating a Failover Cluster

  • Understanding Cluster Validation Tests

  • For information about hardware compatibility for Windows Server 2008, see http://go.microsoft.com/fwlink/?LinkID=59821.

  • For design and deployment information for failover clusters, see http://go.microsoft.com/fwlink/?LinkId=86168.


Creating a Failover Cluster or Adding a Cluster Node

Before you can configure the cluster for the first time or add a server (node) to an existing failover cluster, you need to take the following preparatory steps:

  • Install the failover cluster feature: You must install the failover cluster feature on any server that will become a server (node) in the cluster. For more information, see Install Failover Clustering.

  • Connect networks and storage: You must connect the networks and storage that the nodes will use. For details, see:

    • Prepare Hardware Before Validating a Failover Cluster

    • Understanding Requirements for Failover Clusters.

  • Validate the hardware configuration: We strongly recommend that you validate your hardware configuration (servers, network, and storage) before creating a cluster or adding a node to a cluster. To validate, you run a wizard. For more information, see Validate a New or Existing Failover Cluster.

    Important

    Microsoft supports a failover cluster solution only if the complete configuration (servers, network, and storage) can pass all tests in the Validate a Configuration wizard. In addition, all hardware components in the solution must be marked as "Certified for Windows Server 2008."

To see the preceding steps in the context of a checklist, see Checklist: Create a Failover Cluster.

The following topics describe how to create a failover cluster or add a server (node) to a failover cluster:

  • Understanding Access Points (Names and IP Addresses) in a Failover Cluster

  • Create a New Failover Cluster

  • Add a Server to a Failover Cluster

Additional references

  • Configuring a Service or Application for High Availability

  • Migrating Settings from a Server Cluster Running Windows Server 2003

  • For information about the maximum number of servers that you can have in a failover cluster, see http://go.microsoft.com/fwlink/?LinkId=92091.

  • For design and deployment information for failover clusters, see http://go.microsoft.com/fwlink/?LinkId=86168.


Understanding Access Points (Names and IP Addresses) in a Failover Cluster

An access point is a name and associated IP address information. You use an access point to administer a failover cluster or to communicate with a service or application in the cluster. One access point can include one or more IP addresses, which can be IPv6 addresses, IPv4 addresses supplied through DHCP, or static IPv4 addresses.

When selecting a network to be used for an access point, avoid any network that is used for iSCSI. Configure networks used for iSCSI so that they are not used for network communication in the cluster.

Additional references

  • Understanding Cluster Validation Tests: Network

  • Modify Network Settings for a Failover Cluster

  • Understanding Requirements for Failover Clusters


Create a New Failover Cluster

Before you create a cluster, you must carry out tasks such as connecting the hardware and validating the hardware configuration. For a list of these tasks, see Checklist: Create a Failover Cluster.

For information about the maximum number of servers that you can have in a failover cluster, see http://go.microsoft.com/fwlink/?LinkId=92091.

Membership in the local Administrators group, or equivalent, is the minimum required to complete this procedure. In addition, if your account is not a Domain Admins account, either the account or the group that the account is a member of must be delegated the Create Computer Objects permission in the domain. Review details about using the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/?LinkId=83477.

To create a new failover cluster

  1. Confirm that you have connected the hardware and validated the hardware configuration, as described in the following topics:

    • Prepare Hardware Before Validating a Failover Cluster

    • Validate a New or Existing Failover Cluster.

    Important

    Microsoft supports a failover cluster solution only if the complete configuration (servers, network, and storage) can pass all tests in the Validate a Configuration wizard. In addition, all hardware components in the solution must be marked as "Certified for Windows Server 2008."

  2. In the Failover Cluster Management snap-in, confirm that Failover Cluster Management is selected and then, under Management, click Create a Cluster.

  3. Follow the instructions in the wizard to specify:

    • The servers to include in the cluster.

    • The name of the cluster.

    • Any IP address information that is not automatically supplied by your DHCP settings.

  4. After the wizard runs and the Summary page appears, if you want to view a report of the tasks that the wizard performed, click View Report.

    To view the report after you close the wizard, see the following folder, where SystemRoot is the location of the operating system (for example, C:\Windows):

    SystemRoot\Cluster\Reports\

Additional considerations

  • To open the failover cluster snap-in, click Start, click Administrative Tools, and then click Failover Cluster Management. If the User Account Control dialog box appears, confirm that the action it displays is what you want, and then click Continue.

Additional references

  • Creating a Failover Cluster or Adding a Cluster Node

  • For design and deployment information for failover clusters, see http://go.microsoft.com/fwlink/?LinkId=86168.


Add a Server to a Failover Cluster

Before you add a server (node) to a failover cluster, we strongly recommend that you run the Validate a Configuration Wizard for the existing cluster nodes and the new node or nodes. The Validate a Configuration Wizard helps you confirm the configuration in a variety of important ways. For example, it validates that the server to be added is connected correctly to the networks and storage and that it contains the same software updates.

Important

Microsoft supports a failover cluster solution only if the complete configuration (servers, network, and storage) can pass all tests in the Validate a Configuration wizard. In addition, all hardware components in the solution must be marked as "Certified for Windows Server 2008."

For information about the maximum number of servers that you can have in a failover cluster, see http://go.microsoft.com/fwlink/?LinkId=92091.

For more information about validation, see Validate a New or Existing Failover Cluster.

Membership in the local Administrators group, or equivalent, is the minimum required to complete this procedure. Review details about using the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/?LinkId=83477.

To add a server to a failover cluster

  1. Confirm that you have connected the networks and storage to the server you want to add. For details about the requirements for networking and storage, see Prepare Hardware Before Validating a Failover Cluster.

  2. Validate the hardware configuration, including both the existing cluster nodes and the proposed new node. For information about validation, see Validate a New or Existing Failover Cluster.

    Important

    Microsoft supports a failover cluster solution only if the complete configuration (servers, network, and storage) can pass all tests in the Validate a Configuration wizard. In addition, all hardware components in the solution must be marked as "Certified for Windows Server 2008."

  3. In the Failover Cluster Management snap-in, if the cluster you want to configure is not displayed, in the console tree, right-click Failover Cluster Management, click Manage a Cluster, and select or specify the cluster you want.

  4. Select the cluster, and then in the Actions pane, click Add Node.

  5. Follow the instructions in the wizard to specify the server to add to the cluster.

  6. After the wizard runs and the Summary page appears, if you want to view a report of the tasks the wizard performed, click View Report.

    To view the report after you close the wizard, see the following folder, where SystemRoot is the location of the operating system (for example, C:\Windows):

    SystemRoot \Cluster\Reports\

Additional considerations

  • To open the failover cluster snap-in, click Start, click Administrative Tools, and then click Failover Cluster Management. If the User Account Control dialog box appears, confirm that the action it displays is what you want, and then click Continue.

Additional references

  • Creating a Failover Cluster or Adding a Cluster Node


Configuring a Service or Application for High Availability

This topic provides an overview of the task of configuring specific services or applications for failover clustering by using the High Availability Wizard. Instructions for running the wizard are provided in Configure a Service or Application for High Availability.

Important

If you want to cluster a mail server or database server application, see the application's documentation for information about the correct way to install it in a cluster environment. Mail server and database server applications are complex, and they might require configuration steps that fall outside the scope of this failover clustering Help.

Applications and services listed in the High Availability Wizard

A variety of services and applications can work as "cluster-aware" applications, functioning in a coordinated way with cluster components.

Note

When configuring a service or application that is not cluster-aware, you can use generic options in the High Availability Wizard: Generic Service, Generic Application, or Generic Script. For information about using these options, see Understanding Generic Services and Applications that Can Be Configured in a Failover Cluster.

In the High Availability Wizard, you can choose from the generic options described in the previous note, or you can choose from the following services and applications:

  • DFS Namespace Server: Provides a virtual view of shared folders in an organization. When a user views the namespace, the folders appear to reside on a single hard disk. Users can navigate the namespace without needing to know the server names or shared folders that are hosting the data.

  • DHCP Server: Automatically provides client computers and other TCP/IP-based network devices with valid IP addresses.

  • Distributed Transaction Coordinator (DTC): Supports distributed applications that perform transactions. A transaction is a set of related tasks, such as updates to databases, that either succeed or fail as a unit.

  • File Server: Provides a central location on your network where you can store and share files with users.

  • Internet Storage Name Service (iSNS) Server: Provides a directory of iSCSI targets.

  • Message Queuing: Enables distributed applications that are running at different times to communicate across heterogeneous networks and with computers that may be offline.

  • Other Server: Provides a client access point and storage only. Add an application after completing the wizard.

  • Print Server: Manages a queue of print jobs for a shared printer.

  • WINS Server: Enables users to access resources by a NetBIOS name instead of requiring them to use IP addresses that are difficult to recognize and remember.

The following topics describe the process of configuring a service or application for high availability in a failover cluster:

  • Understanding Generic Services and Applications that Can Be Configured in a Failover Cluster

  • Configure a Service or Application for High Availability

  • Test Failover of a Clustered Service or Application

  • Modifying Settings for a Clustered Service or Application

Additional references

  • Checklist: Create a Failover Cluster

  • For design and deployment information for failover clusters, see http://go.microsoft.com/fwlink/?LinkId=86168.


Understanding Generic Services and Applications that Can Be Configured in a Failover Cluster

You can configure a variety of different services or applications for high availability in a failover cluster. For a list of the services or applications most commonly configured for high availability, see Configuring a Service or Application for High Availability.

This topic contains the following sections:

  • Services or applications that can be run as a Generic Application, Generic Script, or Generic Service

  • Basic requirements for a service or application in a failover cluster environment

Services or applications that can be run as a Generic Application, Generic Script, or Generic Service

In failover clusters, you can use the Generic Application, Generic Script, and Generic Service options to configure high availability for some services and applications that are not "cluster-aware" (not originally designed to run in a cluster).

Generic Application

If you run an application as a Generic Application, the cluster software will start the application, then periodically query the operating system to see whether the application appears to be running. If so, it is presumed to be online, and will not be restarted or failed over.

Note that in comparison with a cluster-aware application, a Generic Application has fewer ways of communicating its precise state to the cluster software. If a Generic Application enters a problematic state but nonetheless appears to be running, the cluster software does not have a way of discovering this and taking an action (such as restarting the application or failing it over).

Before running the High Availability Wizard to configure high availability for a Generic Application, make sure that you know the path of the application and the names of any registry keys under HKEY_LOCAL _MACHINE that are required by the application.

Generic Script

You can create a script that runs in Windows Script Host and that monitors and controls your application. Then you can configure the script as a Generic Script in the cluster. The script provides the cluster software with information about the current state of the application. As needed, the cluster software will restart or fail over the script (and through it, the application will be restarted or failed over).

When you configure a Generic Script in a failover cluster, the ability of the cluster software to respond with precision to the state of the application is determined by the script. The more precise the script is in providing information about the state of the application, the more precise the cluster software can be in responding to that information.

Before running the High Availability Wizard to configure high availability for a Generic Script, make sure that you know the path of the script.

Generic Service

The cluster software will start the service, then periodically query the Service Controller (a feature of the operating system) to determine whether the service appears to be running. If so, it is presumed to be online, and will not be restarted or failed over.

Note that in comparison with a cluster-aware service, a Generic Service has fewer ways of communicating its precise state to the cluster software. If a Generic Service enters a problematic state but nonetheless appears to be running, the cluster software does not have a way of discovering this and taking an action (such as restarting the service or failing it over).

Before running the High Availability Wizard to configure high availability for a Generic Service, make sure that you know the name of the service as it appears in the registry under HKEY_LOCAL _MACHINE\System\CurrentControlSet\Services.

Basic requirements for a service or application in a failover cluster environment

To be appropriate for a failover cluster, a service or application must have certain characteristics. The most important characteristics include:

  • The service or application should be stateful. In other words, the service or application should have long-running in-memory state or large, frequently updated data states. One example is a database application. For a stateless application (such as a Web server front end), Network Load Balancing will probably be more appropriate than failover clustering.

  • The service or application should use a client component that automatically retries after temporary network interruptions. Otherwise, if the server component of the application fails over from one clustered server to another, the unavoidable (but brief) interruption will cause the clients to stop, rather than simply retrying and reconnecting.

  • The service or application should be able to identify the disk or disks it uses. This makes it possible for the service or application to communicate with disks in the cluster storage, and to reliably find the correct disk even after a failover.

  • The service or application should use IP-based protocols. Examples include TCP, UDP, DCOM, named pipes, and RPC over TCP/IP.

Additional references

  • Configuring a Service or Application for High Availability

  • For design and deployment information for failover clusters, see http://go.microsoft.com/fwlink/?LinkId=86168.


Configure a Service or Application for High Availability

You can configure a service or application for high availability by running a wizard that creates the appropriate settings in a failover cluster. For information about the services and applications that you can configure in a failover cluster, see:

  • Configuring a Service or Application for High Availability

  • Understanding Generic Services and Applications that Can Be Configured in a Failover Cluster.

If you are configuring a clustered file server or a clustered print server, review one of the following:

  • Checklist: Create a Clustered File Server

  • Checklist: Create a Clustered Print Server.

Membership in the local Administrators group, or equivalent, is the minimum required to complete this procedure. In addition, if your account is not a Domain Admins account, either the account or the group that the account is a member of must be delegated the Create Computer Objects permission in the domain. Review details about using the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/?LinkId=83477.

To configure a service or application for high availability

  1. In the Failover Cluster Management snap-in, if the cluster you want to configure is not displayed, in the console tree, right-click Failover Cluster Management, click Manage a Cluster, and select or specify the cluster you want.

  2. If the console tree is collapsed, expand the tree under the cluster that you want to configure.

  3. Click Services and Applications and then, under Actions (on the right), click Configure a Service or Application.

  4. Follow the instructions in the wizard to specify the service or application that you want to configure for high availability, along with the following details:

    • A name for the clustered service or application. This name will be registered in DNS and associated with the IP address for this clustered service or application.

    • Any IP address information that is not automatically supplied by your DHCP settings—for example, a static IPv4 address for this clustered service or application.

    • The storage volume or volumes that the clustered service or application should use.

    • Specific information for the service or application that you are configuring. For example, for a Generic Application, you must specify the path for the application and any registry keys that the application requires (so that the registry keys can be replicated to all nodes in the cluster).

  5. After the wizard runs and the Summary page appears, if you want to view a report of the tasks that the wizard performed, click View Report.

    If you are configuring a clustered file server or a clustered print server, see the following "Additional considerations" section.

Additional considerations

  • To open the failover cluster snap-in, click Start, click Administrative Tools, and then click Failover Cluster Management. If the User Account Control dialog box appears, confirm that the action it displays is what you want, and then click Continue.

  • If this is the first service or application that you are configuring for high availability, it might be appropriate to review your cluster network settings now. If the clustered servers are connected to a network that is not to be used for network communication in the cluster (for example, a network that is intended only for iSCSI or only for backup), then under Networks, right-click that network, click Properties, and then select Do not allow the cluster to use this network.

  • If you are configuring a clustered file server, review Checklist: Create a Clustered File Server.

  • If you are configuring a clustered print server, review Checklist: Create a Clustered Print Server.

  • For information about modifying the settings for this service or application after the wizard finishes running, see Modifying Settings for a Clustered Service or Application.

Additional references

  • Configuring a Service or Application for High Availability

  • Understanding Generic Services and Applications that Can Be Configured in a Failover Cluster

  • Modifying Settings for a Clustered Service or Application


Test Failover of a Clustered Service or Application

You can perform a basic test to confirm that a clustered service or application can fail over successfully to another node.

This procedure is one of the steps in the following checklists:

  • Checklist: Create a Clustered File Server

  • Checklist: Create a Clustered Print Server

Membership in the local Administrators group, or equivalent, is the minimum required to complete this procedure. Review details about using the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/?LinkId=83477.

To test failover of a clustered service or application

  1. In the Failover Cluster Management snap-in, if the cluster you want to configure is not displayed, in the console tree, right-click Failover Cluster Management, click Manage a Cluster, and select or specify the cluster you want.

  2. If the console tree is collapsed, expand the tree under the cluster that you want to configure.

  3. Expand Services and Applications, and then click the service or application for which you want to test failover.

  4. Under Actions (on the right), click Move this service or application to another node.

    As the service or application moves, the status is displayed in the results pane (center pane).

  5. Optionally, repeat step 4 to move the service or application to an additional node or back to the original node.

Additional considerations

  • To open the failover cluster snap-in, click Start, click Administrative Tools, and then click Failover Cluster Management. If the User Account Control dialog box appears, confirm that the action it displays is what you want, and then click Continue.

Additional references

  • Configuring a Service or Application for High Availability

  • Modifying Settings for a Clustered Service or Application


Modifying Settings for a Clustered Service or Application

This topic describes failover and failback settings for a clustered service or application. It also provides links to information about other settings that you can modify for a clustered service or application.

Modifying failover and failback settings, including preferred owners

You can adjust the failover settings, including preferred owners and failback settings, to control how the cluster responds when the application or service fails. You can configure these settings on the property sheet for the clustered service or application (on the General tab or the Failover tab). The following table provides examples that illustrate how these settings work.

Settings | Effect
Example 1: General tab, Preferred owner: Node1 Failover tab, Failback setting: Allow failback (Immediately) | If the service or application fails over from Node1 to Node2, when Node1 is again available, the service or application will fail back to Node1.
Example 2: Failover tab, Maximum failures in the specified period: 10 Failover tab, Period (hours): 6 | In a six-hour period, if the application or service fails ten times (or less), it will be restarted or failed over each time. If the application or service fails an eleventh time in the six-hour period, it will be left in the failed state.

The following topics provide details about settings that you can modify for a clustered service or application:

  • Add Storage for a Clustered Service or Application

    For information about adding a disk to the cluster itself, so that the disk is available for adding to a clustered service or application, see Add Storage to a Failover Cluster.

  • Add a Resource to a Clustered Service or Application

  • Modify Failover Settings for a Clustered Service or Application

  • Create a Shared Folder in a Clustered File Server

  • Configure Print Settings for a Clustered Print Server

Additional references

  • Configuring a Service or Application for High Availability

  • For design and deployment information for failover clusters, see http://go.microsoft.com/fwlink/?LinkId=86168.


Add Storage for a Clustered Service or Application

You can add storage to an existing clustered service or application. However, if the storage has not already been added to the failover cluster itself, you must first add the storage to the cluster before you can add the storage to a clustered service or application within the cluster. For information about adding storage to a cluster, see Add Storage to a Failover Cluster.

Membership in the local Administrators group, or equivalent, is the minimum required to complete this procedure. Review details about using the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/?LinkId=83477.

To add storage for a clustered service or application

  1. In the Failover Cluster Management snap-in, if the cluster you want to configure is not displayed, in the console tree, right-click Failover Cluster Management, click Manage a Cluster, and select or specify the cluster you want.

  2. If the console tree is collapsed, expand the tree under the cluster that you want to configure.

  3. Expand Services and Applications, and then click the service or application that you want to add storage to.

  4. Under Actions (on the right), click Add storage.

  5. Select the disk or disks that you want to add.

    If a disk does not appear in the list, it might not have been added to the cluster yet. For more information, see Add Storage to a Failover Cluster.

Additional considerations

  • To open the failover cluster snap-in, click Start, click Administrative Tools, and then click Failover Cluster Management. If the User Account Control dialog box appears, confirm that the action it displays is what you want, and then click Continue.

Additional references

  • Modifying Settings for a Clustered Service or Application

  • Add Storage to a Failover Cluster

  • Understanding Requirements for Failover Clusters

  • Understanding Cluster Validation Tests: Storage


Add a Resource to a Clustered Service or Application

To customize the way your clustered service or application works, you can add a resource.

Important
  • This procedure is designed for use by administrators who are familiar with the way clustered resources and resource groups are configured in Windows Server 2003. Unless you have this familiarity, do not use this procedure, but instead follow the steps in Configure a Service or Application for High Availability, which tells how to run the High Availability Wizard. When you run the wizard and choose a role or service such as File Server or Print Server, the wizard creates the appropriate resources for a clustered instance of that role or service.
  • If you want to cluster a mail server or database server application, see the application's documentation for information about the correct way to install and configure it in a cluster environment. Mail server and database server applications are complex, and therefore might require configuration steps that fall outside the scope of this failover clustering Help.

Membership in the local Administrators group, or equivalent, is the minimum required to complete this procedure. Review details about using the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/?LinkId=83477.

To add a resource to a clustered service or application

  1. Ensure that the software or feature that is needed for the resource is installed on all nodes in the cluster.

  2. In the Failover Cluster Management snap-in, if the cluster you want to configure is not displayed, in the console tree, right-click Failover Cluster Management, click Manage a Cluster, and select or specify the cluster you want.

  3. If the console tree is collapsed, expand the tree under the cluster that you want to configure.

  4. Expand Services and Applications, and then click the service or application that you want to add a resource to.

  5. Under Actions (on the right), click Add a resource.

  6. Click the resource that you want to add, or click More resources and then click the resource that you want to add. If a wizard appears for the resource you chose, provide the information requested by the wizard.

  7. In the center pane, right-click the resource that you added and click Properties.

  8. If the property sheet includes a Parameters tab, click the tab and then configure the parameters that are needed by the resource.

  9. Click the Dependencies tab, and then configure the dependencies for the resource. Click OK.

  10. In the console tree, select the service or application (not the individual resource), and then under Actions (on the right), click Show Dependency Report.

  11. Review the dependencies between the resources. For many resources, you must configure the correct dependencies before the resource can be brought online. If you need to change the dependencies, close the dependency report and then repeat step 9.

  12. Right-click the resource that you just added, and then click Bring this resource online.

Additional considerations

  • To open the failover cluster snap-in, click Start, click Administrative Tools, and then click Failover Cluster Management. If the User Account Control dialog box appears, confirm that the action it displays is what you want, and then click Continue.

Additional references

  • Modifying Settings for a Clustered Service or Application

  • Configure a Service or Application for High Availability

  • For design and deployment information for failover clusters, see http://go.microsoft.com/fwlink/?LinkId=86168.


Modify Failover Settings for a Clustered Service or Application

You can adjust the failover, failback, or preferred owner settings to control the way the cluster responds when a particular application or service fails. For examples that illustrate the way the settings work, see Modifying Settings for a Clustered Service or Application.

Membership in the local Administrators group, or equivalent, is the minimum required to complete this procedure. Review details about using the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/?LinkId=83477.

To modify failover settings for a clustered service or application

  1. In the Failover Cluster Management snap-in, if the cluster you want to configure is not displayed, in the console tree, right-click Failover Cluster Management, click Manage a Cluster, and select or specify the cluster you want.

  2. If the console tree is collapsed, expand the tree under the cluster that you want to configure.

  3. Expand Services and Applications.

  4. Right-click the service or application that you want to modify failover settings for, and then click Properties.

  5. To configure failback, on the General tab, change settings for preferred owners, then click the Failover tab and choose options under Failback.

    You must configure a preferred owner if you want failback to occur (that is, if you want a particular service or application to fail back to a particular node when possible).

  6. To configure the number of times that the cluster service should attempt to restart or fail over a service or application in a given time period, click the Failover tab and specify values under Failover.

    For more information about failover settings for a clustered service or application, see Modifying Settings for a Clustered Service or Application.

Additional considerations

  • To open the failover cluster snap-in, click Start, click Administrative Tools, and then click Failover Cluster Management. If the User Account Control dialog box appears, confirm that the action it displays is what you want, and then click Continue.

Additional references

  • Configuring a Service or Application for High Availability

  • Modifying Settings for a Clustered Service or Application


Create a Shared Folder in a Clustered File Server

Before you perform this procedure, review the steps in Checklist: Create a Clustered File Server. This procedure describes a step in that checklist.

Membership in the local Administrators group, or equivalent, is the minimum required to complete this procedure. Review details about using the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/?LinkId=83477.

To create a shared folder in a clustered file server

  1. In the Failover Cluster Management snap-in, if the cluster you want to configure is not displayed, in the console tree, right-click Failover Cluster Management, click Manage a Cluster, and select or specify the cluster you want.

  2. If the console tree is collapsed, expand the tree under the cluster that you want to configure.

  3. Expand Services and Applications, and then select the clustered file server.

  4. Under Actions, click Add a shared folder.

    The Create a Shared Folder Wizard appears. This is the same wizard that you would use to share a folder on a nonclustered server.

  5. Follow the instructions in the wizard to specify the settings for the shared folder, including path, name, offline settings, and permissions.

Additional considerations

  • To open the failover cluster snap-in, click Start, click Administrative Tools, and then click Failover Cluster Management. If the User Account Control dialog box appears, confirm that the action it displays is what you want, and then click Continue.

  • In a clustered file server, when you bring the associated File Server resource online or take it offline, all shared folders in that resource go offline or online at the same time. You cannot change the online or offline status of one of the shared folders without affecting all of the shared folders.

Additional references

  • Modifying Settings for a Clustered Service or Application

  • Checklist: Create a Clustered File Server

  • For design and deployment information for failover clusters, see http://go.microsoft.com/fwlink/?LinkId=86168.


Configure Print Settings for a Clustered Print Server

Before you perform this procedure, review the steps in Checklist: Create a Clustered Print Server. This procedure describes the last step in that checklist.

Membership in the local Administrators group, or equivalent, is the minimum required to complete this procedure. Review details about using the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/?LinkId=83477.

To configure print settings for a clustered print server

  1. In the Failover Cluster Management snap-in, if the cluster you want to configure is not displayed, in the console tree, right-click Failover Cluster Management, click Manage a Cluster, and select or specify the cluster you want.

  2. If the console tree is collapsed, expand the tree under the cluster that you want to configure.

  3. Expand Services and Applications.

  4. Right-click the clustered print server that you want to configure print settings for, and then click Manage Printers.

    An instance of the Failover Cluster Management interface appears with Print Management in the console tree.

  5. Under Print Management, click Print Servers and locate the clustered print server you want to configure.

    Always perform management tasks on the clustered print server. Do not manage the individual cluster nodes as print servers.

  6. Right-click the clustered print server, and then click Add Printer. Follow the instructions in the wizard to add a printer.

    This is the same wizard you would use to add a printer on a nonclustered server.

  7. When you have finished configuring settings for the clustered print server, to close the instance of the Failover Cluster Management interface with Print Management in the console tree, click File and then click Exit.

Additional considerations

  • To open the failover cluster snap-in, click Start, click Administrative Tools, and then click Failover Cluster Management. If the User Account Control dialog box appears, confirm that the action it displays is what you want, and then click Continue.

  • The failover cluster software automatically replicates important files (such as print drivers) to each of the nodes in the cluster. It supports this replication process by using a disk resource (in the cluster storage) as a place to store these files. This disk resource is configured automatically by the High Availability Wizard as part of a new clustered print server. Do not delete the disk resource that is part of the clustered print server.

Additional references

  • Modifying Settings for a Clustered Service or Application

  • Checklist: Create a Clustered Print Server

  • For design and deployment information for failover clusters, see http://go.microsoft.com/fwlink/?LinkId=86168.


Migrating Settings from a Server Cluster Running Windows Server 2003

The following topics provide information about migrating settings from a server cluster running Windows Server 2003:

  • Understanding the Migration Process from a Cluster Running Windows Server 2003

  • Migrate Clustered Resource Groups from Windows Server 2003

Additional references

  • For information about hardware compatibility for Windows Server 2008, see http://go.microsoft.com/fwlink/?LinkID=59821.

  • For design and deployment information for failover clusters, see http://go.microsoft.com/fwlink/?LinkId=86168.


Understanding the Migration Process from a Cluster Running Windows Server 2003

You can use a wizard to migrate the settings of some types of resources from a cluster running Windows Server 2003 to a cluster running Windows Server 2008. This topic describes some limitations for this process and provides an overview of several approaches to using the process. From the third page of the wizard, you can view a premigration report that explains whether each resource is eligible for migration and describes additional steps to perform after running the wizard. After the wizard finishes, it provides a report that describes additional steps for completing the migration.

For information about the specific steps for running the Migrate a Cluster Wizard, see Migrate Clustered Resource Groups from Windows Server 2003.

Caution

You must handle copying or moving of data or folders during a migration. The wizard for migrating clustered resource groups does not copy data from one location to another.

This topic contains the following subsections:

  • Identifying which clustered services or applications can be migrated from a cluster running Windows Server 2003

  • Migration scenario A: Both old and new clusters have multiple nodes when you migrate settings

    Follow this scenario if you can create a multiple-node cluster running Windows Server 2008 and then migrate settings to it from a multiple-node cluster running Windows Server 2003.

  • Migration scenario B: Both old and new clusters have one node when you migrate settings (in-place migration for two-node cluster)

    Follow this scenario for an in-place migration of a two-node cluster running Windows Server 2003 to a two-node cluster running Windows Server 2008. With this scenario, you use the same physical servers for a new two-node cluster as you used for the old one (although this scenario is not a rolling upgrade).

    Note that the hardware for the new cluster must meet the requirements for a cluster running Windows Server 2008. For more information, see Understanding Requirements for Failover Clusters.

  • Why rolling upgrades are not possible from Windows Server 2003

Identifying which clustered services or applications can be migrated from a cluster running Windows Server 2003

This section lists the clustered services or applications (clustered resources) that can be migrated from a server cluster running Windows Server 2003.

Important

You cannot use the Migrate a Cluster Wizard to migrate mail server and database server applications or any other resources that are not listed in the following subsections. For information about migrating mail server applications, see http://go.microsoft.com/fwlink/?LinkId=91732 and http://go.microsoft.com/fwlink/?LinkId=91733.

Resources for which the Migrate a Cluster Wizard performs most or all of the migration steps

After you use the Migrate a Cluster Wizard to migrate the settings of the following resources to a failover cluster running Windows Server 2008, few or no additional steps are needed before the resources can be brought online.

Caution

You must handle copying or moving of data or folders during a migration. The wizard for migrating the settings of clustered resource groups does not copy data from one location to another.

  • File Share: You can migrate settings for a File Share resource and for the associated Physical Disk, IP Address, and Network Name resources.

    The Migrate a Cluster Wizard automatically translates File Share resources in Windows Server 2003 to the resource types used in Windows Server 2008. Therefore, some resources might look different after the migration. The following table provides details:

    Resource as Seen in Server Cluster Running Windows Server 2003 Migrated Rresource as Seen in Failover Cluster Running Windows Server 2008

    One File Share resource

    One File Server resource

    Multiple File Share resources

    Multiple File Server resources within a single clustered file server

    File Share resource with DFS root

    Distributed File System resource and File Server resource (both within a clustered DFS Server)
  • Physical Disk: You can migrate settings for Physical Disk resources other than the quorum resource.

    You do not need to migrate the quorum resource. When you run the Create a Cluster Wizard, the cluster software automatically chooses the quorum configuration that will provide the highest availability for your new failover cluster. You can change the quorum configuration settings if necessary for your specific environment. For information about changing settings (including quorum configuration settings) for a failover cluster, see Modifying Settings for a Failover Cluster.

  • IP Address: You can migrate IP Address settings other than the cluster IP address. IP addresses are eligible for migration only within the same subnet.

  • Network Name: You can migrate Network Name settings other than the cluster name. If Kerberos authentication is enabled for the Network Name resource, the wizard will prompt you for the password for the Cluster service account that is used by the old cluster.

Resources for which the Migrate a Cluster Wizard does not perform all of the migration steps

After you use the Migrate a Cluster Wizard to migrate the settings of the following resources to a failover cluster running Windows Server 2008, some additional steps are needed before the resources can be brought online:

  • DHCP Service

  • WINS Service

  • Generic Application

  • Generic Script

  • Generic Service

The wizard provides a report that describes the additional steps that are needed. Generally, the steps you must take include:

  • Installing server roles or features that are needed in the new cluster (all nodes). When migrating DHCP, you must install the DHCP Server role, and when migrating WINS, you must install the WINS feature.

  • Copying or installing any associated applications, services, or scripts on the new cluster (all nodes).

  • Ensuring that any data is copied.

The resource settings are migrated, as are the settings for the IP Address and Network Name resources that are in the resource group. If there is a Physical Disk resource in the resource group, the settings for the Physical Disk resource are also migrated.

Migration scenario A: Both old and new clusters have multiple nodes when you migrate settings

For this migration scenario, there are three phases:

  1. Install two or more new servers, run validation, and create a new cluster. For this phase, while the old cluster continues to run, install Windows Server 2008 and Failover Clustering on at least two servers. Create the networks the servers will use, and connect the storage. Next, run the complete set of cluster validation tests to confirm that the hardware and hardware settings can support a failover cluster. Finally, create the new cluster. At this point, you have two clusters.

    Additional information about connecting the storage: If the new cluster is connected to old storage, make at least two logical unit numbers (LUNs) or disks accessible to the servers, and do not make those LUNs or disks accessible to any other servers. (These LUNs or disks are necessary for validation and for the witness disk, which is similar to, although not the same as, the quorum resource in Windows Server 2003.) If the new cluster is connected to new storage, make as many disks or LUNs accessible to it as you think it will need.

    The steps for creating a cluster are listed in Checklist: Create a Failover Cluster.

  2. Migrate settings to the new cluster and determine how you will make any existing data available to the new cluster. When the Migrate a Cluster Wizard completes, all migrated resources will be offline. Leave them offline at this stage. If the new cluster will use old storage, plan how you will make the storage available to it, but leave the old cluster connected to the storage until you are ready to make the transition. If the new cluster will use new storage, copy the appropriate folders and data to the storage.

  3. Make the transition from the old cluster to the new. If the new cluster uses old storage, the first step in the transition is to follow your plan for making LUNs or disks inaccessible to the old cluster and accessible to the new cluster. Then, whether the new cluster uses new or old storage, take each resource group offline on the old cluster and bring the corresponding clustered service or application online on the new cluster.

Migration scenario B: Both old and new clusters have one node when you migrate settings (in-place migration for a two-node cluster)

For this migration scenario, there are three phases:

  1. Install a new server and run selected validation tests. For this phase, allow one existing server to keep running Windows Server 2003 and the Cluster service while you begin the migration process. On one other server, install Windows Server 2008 and the failover cluster feature. Connect this server to storage, make at least one LUN or disk accessible to it (a LUN or disk that is not accessible to other servers), and run all tests that the Validate a Configuration Wizard will run. The wizard will recognize that this is a single node and limit the tests that it runs. Tests that require two nodes (for example, tests that compare the nodes or that simulate failover) will not run.

    Note that the tests that you run at this stage do not provide complete information about whether the storage will work in a cluster running Windows Server 2008. As described later in this section, you will run the Validate a Configuration Wizard later with all tests included.

  2. Make the new server into a single-node cluster and migrate settings to it, and determine how you will make existing data available to the new cluster. Migrate settings to the single-node cluster, but keep clustered resources offline. If the new cluster will use the old storage, leave the data on the old storage, and create a plan for making the disks or LUNs accessible to the new cluster. If the new cluster will use new storage, copy folders and data to appropriate LUNs or disks in the new storage, and make sure those LUNs or disks are visible to the new server (and not visible to any other servers).

  3. Make the transition from the old cluster to the new. This phase might involve some downtime. Install Windows Server 2008 and the failover cluster feature on the server that was previously in the old cluster and connect the networks and storage so the new server can join the new cluster.

    If the appropriate disks or LUNs are not already accessible to the new cluster, make them accessible, and run the complete set of validation tests on the new cluster. Confirm that the settings for the migrated services or applications are correct. Finally, on the new cluster, bring the migrated services and applications online.

Why rolling upgrades are not possible from Windows Server 2003

When you shift your clustering operation from servers running Windows Server 2003 to servers running Windows Server 2008, you cannot perform a rolling upgrade, that is, you cannot have nodes running different operating systems in the same cluster. Improvements in failover clusters in Windows Server 2008 mean that the two versions of clustering—server clusters in Windows Server 2003 and failover clusters in Windows Server 2008—use very different underlying functionality for communication with storage and for networking. Storage in failover clusters uses specific SCSI commands (within the standard called SCSI Primary Commands-3 or SPC-3) not used in Windows Server 2003. Networking improvements mean that clustered servers running Windows Server 2008 perform node-to-node communication differently from clustered servers running Windows Server 2003.

Additional references

  • Migrating Settings from a Server Cluster Running Windows Server 2003

  • For information about hardware compatibility for Windows Server 2008, see http://go.microsoft.com/fwlink/?LinkID=59821.

  • For design and deployment information (including migration information) for failover clusters, see http://go.microsoft.com/fwlink/?LinkId=86168.


Migrate Clustered Resource Groups from Windows Server 2003

You can use a wizard to migrate the settings of some types of resource groups from a cluster running Windows Server 2003 to a cluster running Windows Server 2008. After the settings have been migrated, the wizard also provides a report that describes the additional steps to take to complete the migration.

Caution

You must handle all copying or moving of data or folders during a migration. The wizard for migrating clustered resource groups does not copy data from one location to another.

Before you start the wizard, be sure that you know the name or IP Address of the cluster or cluster node from which you want to migrate resource groups.

Membership in the local Administrators group on each clustered server, or equivalent, is the minimum required to complete this procedure. Also, the account you use must be a domain account. Review details about using the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/?LinkId=83477.

To migrate clustered resource groups from Windows Server 2003

  1. In the Failover Cluster Management snap-in, if the cluster you want to configure is not displayed, in the console tree, right-click Failover Cluster Management, click Manage a Cluster, and select or specify the cluster you want.

  2. Under Configure, click Migrate Services and Applications.

  3. Read the first page of the Migrate a Cluster Wizard, and then click Next.

  4. Specify the name or IP Address of the cluster or cluster node from which you want to migrate resource groups, and then click Next.

  5. Click View Report. Read the report, which explains whether each resource is eligible for migration and describes additional steps to perform after running the wizard.

  6. Follow the instructions in the wizard to complete the following:

    • Choose the resource group or groups whose settings you want to migrate.

      Some types of resource groups are eligible for migration and some are not. For more information, see Understanding the Migration Process from a Cluster Running Windows Server 2003.

    • Specify whether the resource groups to be migrated will use new storage, or the same storage used in the old cluster. If the resource groups will use new storage, you can specify the disk that each resource group should use after migration.

  7. After the wizard runs and the Summary page appears, click View Report. This report contains important information about any additional steps you must perform before you bring the migrated resource groups online. For example, you might need to copy applications from the old cluster to the new cluster.

Additional considerations

  • To open the failover cluster snap-in, click Start, click Administrative Tools, and then click Failover Cluster Management. If the User Account Control dialog box appears, confirm that the action it displays is what you want, and then click Continue.

  • For information about modifying the settings of a service or application after migration, see Modifying Settings for a Clustered Service or Application.

Additional references

  • Understanding the Migration Process from a Cluster Running Windows Server 2003

  • Migrating Settings from a Server Cluster Running Windows Server 2003

  • Modifying Settings for a Clustered Service or Application


Modifying Settings for a Failover Cluster

The default settings that are created by wizards for failover clustering work well for most clusters. However, you can change a cluster's settings—for example, add storage or modify network settings. The following topics provide information about changing the overall settings for your cluster:

  • Understanding Quorum Configurations in a Failover Cluster

  • Add Storage to a Failover Cluster

  • Modify Network Settings for a Failover Cluster

  • Select Quorum Options for a Cluster

Additional references

  • Modifying Settings for a Clustered Service or Application

  • For design and deployment information for failover clusters, see http://go.microsoft.com/fwlink/?LinkId=86168.


Understanding Quorum Configurations in a Failover Cluster

This topic contains the following sections:

  • How the quorum configuration affects the cluster

  • Quorum configuration choices

  • Illustrations of quorum configurations

  • Why quorum is necessary

For information about how to configure quorum options, see Select Quorum Options for a Cluster.

How the quorum configuration affects the cluster

The quorum configuration in a failover cluster determines the number of failures that the cluster can sustain. If an additional failure occurs, the cluster must stop running. The relevant failures in this context are failures of nodes or, in some cases, of a witness disk (which contains a copy of the cluster configuration) or witness file share. It is essential that the cluster stop running if too many failures occur or if there is a problem with communication between the cluster nodes. For a more detailed explanation, see Why quorum is necessary later in this topic.

Important

In most situations, use the quorum configuration that the cluster software identifies as appropriate for your cluster. Change the quorum configuration only if you have determined that the change is appropriate for your cluster.

Note that full function of a cluster depends not just on quorum, but on the capacity of each node to support the services and applications that fail over to that node. For example, a cluster that has five nodes could still have quorum after two nodes fail, but each remaining cluster node would continue serving clients only if it had enough capacity to support the services and applications that failed over to it.

Quorum configuration choices

You can choose from among four possible quorum configurations:

  • Node Majority (recommended for clusters with an odd number of nodes)

    Can sustain failures of half the nodes (rounding up) minus one. For example, a seven node cluster can sustain three node failures.

  • Node and Disk Majority (recommended for clusters with an even number of nodes)

    Can sustain failures of half the nodes (rounding up) if the witness disk remains online. For example, a six node cluster in which the witness disk is online could sustain three node failures.

    Can sustain failures of half the nodes (rounding up) minus one if the witness disk goes offline or fails. For example, a six node cluster with a failed witness disk could sustain two (3-1=2) node failures.

  • Node and File Share Majority (for clusters with special configurations)

    Works in a similar way to Node and Disk Majority, but instead of a witness disk, this cluster uses a witness file share.

    Note that if you use Node and File Share Majority, at least one of the available cluster nodes must contain a current copy of the cluster configuration before you can start the cluster. Otherwise, you must force the starting of the cluster through a particular node. For more information, see "Additional considerations" in Start or Stop the Cluster Service on a Cluster Node.

  • No Majority: Disk Only (not recommended)

    Can sustain failures of all nodes except one (if the disk is online). However, this configuration is not recommended because the disk might be a single point of failure.

Illustrations of quorum configurations

The following illustrations show how three of the quorum configurations work. A fourth configuration is described in words, because it is similar to the Node and Disk Majority configuration illustration.

Note

In the illustrations, for all configurations other than Disk Only, notice whether a majority of the relevant elements are in communication (regardless of the number of elements). When they are, the cluster continues to function. When they are not, the cluster stops functioning.

Node Majority Quorum Configuration, Three Nodes

Cluster with Node Majority quorum configuration

As shown in the preceding illustration, in a cluster with the Node Majority configuration, only nodes are counted when calculating a majority.

Node and Disk Majority Quorum Configuration, Four Nodes (Plus Disk)

Cluster with Node and Disk Majority quorum

As shown in the preceding illustration, in a cluster with the Node and Disk Majority configuration, the nodes and the witness disk are counted when calculating a majority.

Node and File Share Majority Quorum Configuration

In a cluster with the Node and File Share Majority configuration, the nodes and the witness file share are counted when calculating a majority. This is similar to the Node and Disk Majority quorum configuration shown in the previous illustration, except that the witness is a file share that all nodes in the cluster can access instead of a disk in cluster storage.

No Majority (Disk Only) Quorum Configuration, Three Nodes

Cluster with Disk Only quorum configuration

In a cluster with the Disk Only configuration, the number of nodes does not affect how quorum is achieved. The disk is the quorum. However, if communication with the disk is lost, the cluster becomes unavailable.

Why quorum is necessary

When network problems occur, they can interfere with communication between cluster nodes. A small set of nodes might be able to communicate together across a functioning part of a network but not be able to communicate with a different set of nodes in another part of the network. This can cause serious issues. In this "split" situation, at least one of the sets of nodes must stop running as a cluster.

To prevent the issues that are caused by a split in the cluster, the cluster software requires that any set of nodes running as a cluster must use a voting algorithm to determine whether, at a given time, that set has quorum. Because a given cluster has a specific set of nodes and a specific quorum configuration, the cluster will know how many "votes" constitutes a majority (that is, a quorum). If the number drops below the majority, the cluster stops running. Nodes will still listen for the presence of other nodes, in case another node appears again on the network, but the nodes will not begin to function as a cluster until the quorum exists again.

For example, in a five node cluster that is using a node majority, consider what happens if nodes 1, 2, and 3 can communicate with each other but not with nodes 4 and 5. Nodes 1, 2, and 3 constitute a majority, and they continue running as a cluster. Nodes 4 and 5, being a minority, stop running as a cluster. If node 3 loses communication with other nodes, all nodes stop running as a cluster. However, all functioning nodes will continue to listen for communication, so that when the network begins working again, the cluster can form and begin to run.

Additional references

  • Modifying Settings for a Failover Cluster

  • Select Quorum Options for a Cluster

  • For design and deployment information for failover clusters, see http://go.microsoft.com/fwlink/?LinkId=86168.


Add Storage to a Failover Cluster

You can add storage to a failover cluster after exposing that storage to all cluster nodes (by changing LUN masking or zoning). You do not need to add the storage to the cluster if the storage is already listed for that cluster under Storage in the Failover Cluster Management snap-in.

If you are only adding storage to a particular clustered service or application (not adding entirely new storage to the failover cluster as a whole), see Add Storage for a Clustered Service or Application.

Membership in the local Administrators group on each clustered server, or equivalent, is the minimum required to complete this procedure. Also, the account you use must be a domain account. Review details about using the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/?LinkId=83477.

To add storage to a failover cluster

  1. In the Failover Cluster Management snap-in, if the cluster you want to configure is not displayed, in the console tree, right-click Failover Cluster Management, click Manage a Cluster, and select or specify the cluster you want.

  2. If the console tree is collapsed, expand the tree under the cluster that you want to configure.

  3. Right-click Storage, and then click Add a disk.

  4. Select the disk or disks you want to add.

Additional considerations

  • To open the failover cluster snap-in, click Start, click Administrative Tools, and then click Failover Cluster Management. If the User Account Control dialog box appears, confirm that the action it displays is what you want, and then click Continue.

  • After you click Add a disk, if you do not see a disk that you expect to see, review the following:

    • The list of disks that are shown when you click Storage in the Failover Cluster Management snap-in. If the disk is already in that list, you do not need to add it to the cluster.

    • The configuration of the storage interfaces, including the storage interfaces that run on the cluster nodes. The disk must be available to all nodes in the cluster before you can add it to the set of storage for the cluster.

    • The disks shown in Disk Management (check each node in the cluster).

      If the disk that you want to add does not appear at all in Disk Management (on any node), there might be an issue with the storage configuration that is preventing the operating system from recognizing or mounting the disk. Note that disks currently in use by the cluster will appear in Disk Management on one node only (the node that is the current owner of that disk).

      If the disk that you want to add appears in Disk Management but does not appear after you click Add a disk, confirm that the disk is configured as a basic disk, not a dynamic disk. Only basic disks can be used in a failover cluster.

      To open Disk Management, click Start, click Administrative Tools, click Computer Management, and then click Disk Management. (If the User Account Control dialog box appears, confirm that the action it displays is what you want, and then click Continue.)

Additional references

  • Modifying Settings for a Failover Cluster

  • Add Storage for a Clustered Service or Application


Modify Network Settings for a Failover Cluster

For each of the networks physically connected to the servers (nodes) in a failover cluster, you can specify whether the network is used by the cluster, and if so, whether the network is used by the nodes only or also by clients. Note that in this context, the term "clients" includes not only client computers accessing clustered services and applications, but remote computers that you use to administer the cluster.

If you use a network for iSCSI (storage), do not use it for network communication in the cluster.

For background information about network requirements for a failover cluster, see Understanding Requirements for Failover Clusters.

Membership in the local Administrators group on each clustered server, or equivalent, is the minimum required to complete this procedure. Also, the account you use must be a domain account. Review details about using the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/?LinkId=83477.

To modify network settings for a failover cluster

  1. In the Failover Cluster Management snap-in, if the cluster you want to configure is not displayed, in the console tree, right-click Failover Cluster Management, click Manage a Cluster, and select or specify the cluster you want.

  2. If the console tree is collapsed, expand the tree under the cluster that you want to configure.

  3. Expand Networks.

  4. Right-click the network that you want to modify settings for, and then click Properties.

  5. If needed, change the name of the network.

  6. Select one of the following options:

    • Allow the cluster to use this network

      If you select this option and you want the network to be used by the nodes only (not clients), clear Allow clients to connect through this network. Otherwise, make sure it is selected.

    • Do not allow the cluster to use this network

      Select this option if you are using a network only for iSCSI (communication with storage) or only for backup. (These are among the most common reasons for selecting this option.)

Additional considerations

  • To open the failover cluster snap-in, click Start, click Administrative Tools, and then click Failover Cluster Management. If the User Account Control dialog box appears, confirm that the action it displays is what you want, and then click Continue.

  • IP addresses and the associated network names used for the cluster itself or for clustered services or applications are called access points. For a brief description of access points, see Understanding Access Points (Names and IP Addresses) in a Failover Cluster.

Additional references

  • Modifying Settings for a Clustered Service or Application

  • Understanding Requirements for Failover Clusters


Select Quorum Options for a Cluster

If you have special requirements or make changes to your cluster, you might want to change the quorum options for your cluster.

Important

In most situations, use the quorum configuration that the cluster software identifies as appropriate for your cluster. Change the quorum configuration only if you have determined that the change is appropriate for your cluster.

For important conceptual information about quorum configuration options, see Understanding Quorum Configurations in a Failover Cluster.

Membership in the local Administrators group on each clustered server, or equivalent, is the minimum required to complete this procedure. Also, the account you use must be a domain account. Review details about using the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/?LinkId=83477.

To select quorum options for a cluster

  1. In the Failover Cluster Management snap-in, if the cluster you want to configure is not displayed, in the console tree, right-click Failover Cluster Management, click Manage a Cluster, and select or specify the cluster you want.

  2. With the cluster selected, in the Actions pane, click More Actions, and then click Configure Cluster Quorum Settings.

  3. Follow the instructions in the wizard to select the quorum configuration for your cluster. If you choose a configuration that includes a witness disk or witness file share, follow the instructions for specifying the witness.

  4. After the wizard runs and the Summary page appears, if you want to view a report of the tasks that the wizard performed, click View Report.

Additional considerations

  • To open the failover cluster snap-in, click Start, click Administrative Tools, and then click Failover Cluster Management. If the User Account Control dialog box appears, confirm that the action it displays is what you want, and then click Continue.

Additional references

  • Modifying Settings for a Failover Cluster

  • Understanding Quorum Configurations in a Failover Cluster


Managing a Failover Cluster

The following topics contain information about managing and troubleshooting a failover cluster:

  • Understanding Backup and Recovery Basics for a Failover Cluster

  • Bring a Clustered Service or Application Online or Take It Offline

  • Pause or Resume a Node in a Failover Cluster

  • Run a Disk Maintenance Tool Such as Chkdsk on a Clustered Disk

  • Start or Stop the Cluster Service on a Cluster Node

  • Use Validation Tests for Troubleshooting a Failover Cluster

  • View Events and Logs for a Failover Cluster

  • View Reports of the Actions of Failover Cluster Wizards

Additional references

  • For operations information for failover clusters, see http://go.microsoft.com/fwlink/?LinkId=86169.

  • For troubleshooting information for failover clusters, see http://go.microsoft.com/fwlink/?LinkId=86170.


Understanding Backup and Recovery Basics for a Failover Cluster

This topic outlines some basic guidelines for backing up and restoring a failover cluster. For more information about backing up and restoring a failover cluster, see http://go.microsoft.com/fwlink/?LinkId=92360.

Backing up a failover cluster

When you back up a failover cluster, you can back up the cluster configuration, the data on clustered disks, or both.

Backing up the cluster configuration

When you back up the cluster configuration, take note of the following:

  • For a backup to succeed in a failover cluster, the cluster must be running and must have quorum. In other words, enough nodes must be running and communicating (perhaps with a witness disk or witness file share, depending on the quorum configuration) that the cluster has achieved quorum.

    For more information about quorum in a failover cluster, see Understanding Quorum Configurations in a Failover Cluster.

  • Before putting a cluster into production, test your backup and recovery process.

  • If you choose to use Windows Server Backup (the backup feature included in Windows Server 2008), you must first add the feature. You can do this in Initial Configuration Tasks or in Server Manager by using the Add Features Wizard.

  • When you perform a backup (using Windows Server Backup or other backup software), choose options that will allow you to perform a system recovery from your backup. For more information, see the Help or other documentation for your backup software.

Backing up data on clustered disks

When you back up data through a cluster node, notice which disks are Online on that node at that time. Only disks that are Online and owned by that cluster node at the time of the backup are backed up.

Restoring to a failover cluster from backup

When you restore to a failover cluster from backup, you can restore the cluster configuration, the data on clustered disks, or both.

Restoring the cluster configuration from backup

The Cluster service keeps track of which cluster configuration is the most recent, and it replicates that configuration to all cluster nodes. (If the cluster has a witness disk, the Cluster service also replicates the configuration to the witness disk). Therefore, when you restore a single cluster node from backup, there are two possibilities:

  • Restoring the node to normal function, but not rolling back the cluster configuration: This is called a "non-authoritative restore." In this scenario, the reason you use the backup is only to restore a damaged node to normal function. When the restored node begins functioning and joins the cluster, the latest cluster configuration automatically replicates to that node.

  • Rolling back the cluster configuration to the configuration stored in the backup: This is called an "authoritative restore." In this scenario, you have determined that you want to use the cluster configuration that is stored in the backup, not the configuration currently on the cluster nodes. By specifying appropriate options when you restore the backup, you can cause the cluster to treat the restored configuration as the "most recent." In this case, the Cluster service will not overwrite the restored configuration, but instead will replicate it across all nodes. For details about how to perform an authoritative restore, see the Help or other documentation for your backup software.

Restoring data to clustered disks from backup

When you restore backed-up data through a failover cluster node, notice which disks are Online on that node at that time. Data can be written only to disks that are Online and owned by that cluster node when the backup is being restored.

Additional references

  • Managing a Failover Cluster

  • For additional information about backing up and restoring failover clusters, see http://go.microsoft.com/fwlink/?LinkId=92360.

  • For additional operations information for failover clusters, see http://go.microsoft.com/fwlink/?LinkId=86169.

  • For troubleshooting information for failover clusters, see http://go.microsoft.com/fwlink/?LinkId=86170.


Bring a Clustered Service or Application Online or Take It Offline

Sometimes during maintenance or diagnosis that involves a service or application in a failover cluster, you might need to bring that service or application online or take it offline. Bringing an application online or taking it offline does not trigger failover, although the Cluster service handles the process in an orderly fashion. For example, if a particular disk is required by a particular clustered application, the Cluster service ensures that the disk is available before the application starts.

For information about related actions, such as pausing a cluster node, see Managing a Failover Cluster.

Membership in the local Administrators group on each clustered server, or equivalent, is the minimum required to complete this procedure. Also, the account you use must be a domain account. Review details about using the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/?LinkId=83477.

Bringing a clustered service or application online or taking it offline

  • Using the Windows interface

  • Using a Command Prompt window

To bring a clustered service or application online or take it offline by using the Windows interface

  1. In the Failover Cluster Management snap-in, if the cluster you want to manage is not displayed, in the console tree, right-click Failover Cluster Management, click Manage a Cluster, and then select or specify the cluster you want.

  2. If the console tree is collapsed, expand the tree under the cluster that you want to manage.

  3. Under Services and Applications, expand the console tree.

  4. Check the status of the service or application that you want to bring online or take offline by clicking the service or application and viewing the Status column (in the center pane).

  5. Right-click the service or application that you want to bring online or take offline.

  6. Click the appropriate command: Bring this service or application online or Take this service or application offline.

Additional considerations

  • To open the failover cluster snap-in, click Start, click Administrative Tools, and then click Failover Cluster Management. If the User Account Control dialog box appears, confirm that the action it displays is what you want, and then click Continue.

  • Note that in a clustered file server, shared folders are associated with a File Server resource. When you bring that resource online or take it offline, all shared folders in the resource go offline or online at the same time. You cannot change the online or offline status of one of the shared folders without affecting all of the shared folders in the File Server resource.

Additional references

  • Managing a Failover Cluster

  • For additional operations information for failover clusters, see http://go.microsoft.com/fwlink/?LinkId=86169.

  • For troubleshooting information for failover clusters, see http://go.microsoft.com/fwlink/?LinkId=86170.

To bring a clustered service or application online or take it offline by using a Command Prompt window

  1. To open a Command Prompt window, click Start, right-click Command Prompt, and then either click Run as administrator or click Open.

  2. If the User Account Control dialog box appears, confirm that the action it displays is what you want, and then click Continue.

  3. Review the status of your clustered services and applications by typing:

    CLUSTER [cluster-name] GROUP /STATUS

  4. Type the one of the following commands:

    • To bring a clustered service or application online, type:

      CLUSTER [cluster-name] GROUP "service-or-application name" /ON[:node-name] [/WAIT[:timeout-seconds]]

    • To take a clustered service or application offline, type:

      CLUSTER [cluster-name] GROUP "service-or-application name" /OFF [/WAIT[:timeout-seconds]]

Value | Description
timeout-seconds | The period of time after which you want the command to cancel if it cannot complete. If you do not specify a time-out, the command will try to run until it completes, or until the node state changes.
cluster-name | The name of the cluster that you want to affect.
"service-or-application name" | The name of the service or application that you want to affect.
node-name | The name of the node where you want to bring the service or application online.

To view the complete syntax for this command, at a command prompt, type:

CLUSTER GROUP /?

Additional references

  • Managing a Failover Cluster

  • For additional operations information for failover clusters, see http://go.microsoft.com/fwlink/?LinkId=86169.

  • For troubleshooting information for failover clusters, see http://go.microsoft.com/fwlink/?LinkId=86170.


Pause or Resume a Node in a Failover Cluster

When you pause a node, existing groups and resources stay online, but additional groups and resources cannot be brought online on the node. The usual reason to pause a node is so that you can apply software updates to the node.

If you need to perform extensive diagnosis or maintenance on a cluster node, it might not be workable to simply pause the node. In that case, you can stop the Cluster service on that node. For more information, see Start or Stop the Cluster Service on a Cluster Node.

Membership in the local Administrators group on each clustered server, or equivalent, is the minimum required to complete this procedure. Also, the account you use must be a domain account. Review details about using the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/?LinkId=83477.

Pausing or resuming a node in a failover cluster

  • Using the Windows interface

  • Using a Command Prompt window

To pause or resume a node in a failover cluster by using the Windows interface

  1. In the Failover Cluster Management snap-in, if the cluster you want to manage is not displayed, in the console tree, right-click Failover Cluster Management, click Manage a Cluster, and select or specify the cluster you want.

  2. If the console tree is collapsed, expand the tree under the cluster you want to manage.

  3. Expand the console tree under Nodes.

  4. Right-click the node you want to pause or resume, and then either click Pause or Resume.

Additional considerations

  • To open the failover cluster snap-in, click Start, click Administrative Tools, and then click Failover Cluster Management. If the User Account Control dialog box appears, confirm that the action it displays is what you want, and then click Continue.

Additional references

  • Managing a Failover Cluster

  • For additional operations information for failover clusters, see http://go.microsoft.com/fwlink/?LinkId=86169.

  • For troubleshooting information for failover clusters, see http://go.microsoft.com/fwlink/?LinkId=86170.

To pause or resume a node in a failover cluster by using a Command Prompt window

  1. To open a Command Prompt window, click Start, right-click Command Prompt, and then either click Run as administrator or click Open.

  2. If the User Account Control dialog box appears, confirm that the action it displays is what you want, and then click Continue.

  3. Type one of the following commands:

    • To pause a node, type:

      CLUSTER [cluster-name] NODE node-name /PAUSE

    • To resume a node, type:

      CLUSTER [cluster-name] NODE node-name /RESUME

Value | Description
cluster-name | The name of the cluster that you want to affect.
node-name | The name of the node that you want to affect.

To view the complete syntax for this command, at a command prompt, type:

CLUSTER NODE /?

Additional considerations

  • To view the status of a given node, type:

    CLUSTER [cluster-name] NODE node-name /STATUS

Additional references

  • Managing a Failover Cluster

  • For additional operations information for failover clusters, see http://go.microsoft.com/fwlink/?LinkId=86169.

  • For troubleshooting information for failover clusters, see http://go.microsoft.com/fwlink/?LinkId=86170.


Run a Disk Maintenance Tool Such as Chkdsk on a Clustered Disk

To run a disk maintenance tool such as Chkdsk on a witness disk in a cluster, or on a disk that is configured as part of a clustered service or application, you must use maintenance mode. When maintenance mode is on, the disk maintenance tool can finish running without triggering a failover.

Membership in the local Administrators group, or equivalent, is the minimum required to complete this procedure. Review details about using the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/?LinkId=83477.

Running a disk maintenance tool such as Chkdsk on a clustered disk

  • Using the Windows interface

  • Using a Command Prompt window

To run a disk maintenance tool such as Chkdsk on a clustered disk by using the Windows interface

  1. In the Failover Cluster Management snap-in, if the cluster is not displayed, in the console tree, right-click Failover Cluster Management, click Manage a Cluster, and select or specify the cluster you want.

  2. If the console tree is collapsed, expand the tree under the cluster that uses the disk on which you want run a disk maintenance tool.

  3. In the console tree, click Storage.

  4. In the center pane, click the disk on which you want to run the disk maintenance tool.

  5. Under Actions, click More Actions, and then click Turn On Maintenance Mode for this disk.

  6. Run the disk maintenance tool on the disk.

    When maintenance mode is on, the disk remains online in the cluster, but the disk maintenance tool can finish running without triggering a failover.

  7. When the disk maintenance tool finishes running, with the disk still selected, under Actions, click More Actions, and then click Turn Off Maintenance Mode for this disk.

Additional considerations

  • To open the failover cluster snap-in, click Start, click Administrative Tools, and then click Failover Cluster Management. If the User Account Control dialog box appears, confirm that the action it displays is what you want, and then click Continue.

  • Maintenance mode will remain on until one of the following occurs:

    • You turn it off.

    • The resource goes offline or fails.

    • The node on which the resource is running restarts or loses communication with other nodes (which causes failover of all resources on that node).

  • You can see whether a disk is in maintenance mode by looking at the status in the center pane when Storage is selected in the console tree. When a disk is in maintenance mode, the status is Online (Maintenance).

Additional references

  • Managing a Failover Cluster

  • For additional operations information for failover clusters, see http://go.microsoft.com/fwlink/?LinkId=86169.

  • For troubleshooting information for failover clusters, see http://go.microsoft.com/fwlink/?LinkId=86170.

To run a disk maintenance tool such as Chkdsk on a clustered disk by using a Command Prompt window

  1. To open a Command Prompt window, click Start, right-click Command Prompt, and then either click Run as administrator or click Open.

  2. If the User Account Control dialog box appears, confirm that the action it displays is what you want, and then click Continue.

  3. To review the resource names of disks in the cluster, type:

    CLUSTER [cluster-name] RESOURCE /STATUS

    From the list that is displayed, identify the resource name of the disk on which you want to turn on maintenance mode.

  4. Type:

    CLUSTER [cluster-name] RESOURCE "disk-resource-name" /MAINT:ON

  5. Run the disk maintenance tool on the disk.

    When maintenance mode is on, the disk remains online in the cluster, but the disk maintenance tool can finish running without triggering a failover.

  6. As soon as the disk maintenance tool finishes running, type:

    CLUSTER [cluster-name] RESOURCE "disk-resource-name" /MAINT:OFF

Value | Description
cluster-name | The name of the cluster that you want to affect.
disk-resource-name | The resource name of the disk that you want to affect.

To view the complete syntax for this command, at a command prompt, type:

CLUSTER RESOURCE /?

Additional considerations

  • To view the status of a particular disk resource, type:

    CLUSTER [cluster-name] RESOURCE "disk-resource-name" /STATUS

  • Maintenance mode will remain on until one of the following occurs:

    • You turn it off.

    • The resource goes offline or fails.

    • The node on which the resource is running restarts or loses communication with other nodes (which causes failover of all resources on that node).

Additional references

  • Managing a Failover Cluster

  • For additional operations information for failover clusters, see http://go.microsoft.com/fwlink/?LinkId=86169.

  • For troubleshooting information for failover clusters, see http://go.microsoft.com/fwlink/?LinkId=86170.


Start or Stop the Cluster Service on a Cluster Node

You might need to stop and restart the Cluster service on a cluster node during some troubleshooting or maintenance operations. When you stop the Cluster service on a node, services or applications on that node will fail over, and the node will stop functioning in the cluster until the Cluster service is restarted.

If you want to leave a particular node functioning so that it supports the services or applications it currently owns, and at the same time prevent additional services and applications from failing over to that node, pause the node (do not stop the Cluster service). For more information, see Pause or Resume a Node in a Failover Cluster.

Membership in the local Administrators group on each clustered server, or equivalent, is the minimum required to complete this procedure. Also, the account you use must be a domain account. Review details about using the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/?LinkId=83477.

Starting or stopping the Cluster service on a cluster node

  • Using the Windows interface

  • Using a Command Prompt window

To start or stop the Cluster service on a cluster node by using the Windows interface

  1. In the Failover Cluster Management snap-in, if the cluster you want to manage is not displayed, in the console tree, right-click Failover Cluster Management, click Manage a Cluster, and then select or specify the cluster that you want.

  2. If the console tree is collapsed, expand the tree under the cluster you want to manage.

  3. To minimize disruption to clients, before stopping the Cluster service on a node, move the applications that are currently owned by that node to another node. To do this, expand the console tree under the cluster that you want to manage, and then expand Services and Applications. Click each service or application and (in the center pane) view the Current Owner. If the owner is the node on which you want to stop the Cluster service, right-click the service or application, click Move this service or application to another node, and then choose the node. (For an explanation of the Best possible command option, see "Additional considerations" in this topic.)

  4. Expand the console tree under Nodes.

  5. Right-click the node that you want to start or stop, and then click More Actions.

  6. Click the appropriate command:

    • To start the service, click Start Cluster Service.

    • To stop the service, click Stop Cluster Service.

Additional considerations

  • To open the failover cluster snap-in, click Start, click Administrative Tools, and then click Failover Cluster Management. If the User Account Control dialog box appears, confirm that the action it displays is what you want, and then click Continue.

  • On a cluster with more than two nodes, from the options next to Move this service or application to another node, you can choose Best possible. This option has no effect if you have not configured a Preferred owners list for the service or application you are moving (in this case, the node will be chosen randomly). If you have configured a Preferred owners list, Best possible will move the service or application to the first available node on the list.

  • In the center pane of the Failover Cluster Management snap-in, you can view information about the state of a node. To specifically check whether the Cluster service is running on a node, right-click the node and click More Actions. On a node that is started, Start Cluster Service is dimmed, and on a node that is stopped, Stop Cluster Service is dimmed.

  • If you are using the Node and File Share Majority quorum option, at least one of the available cluster nodes must contain a current copy of the cluster configuration before you can start the cluster. Otherwise, you must force the starting of the cluster through a particular node. The cluster will then use the copy of the cluster configuration that is on that node and replicate it to all other nodes. To force the cluster to start, on a node that contains a copy of the cluster configuration that you want to use, open the Failover Cluster Management snap-in, click the cluster, and then under Actions (on the right), click Force Cluster Start. (Under most circumstances, this command is not available in the Windows interface.)

    Note

    When you use this command on a given node, the copy of the cluster configuration that is on that node will be treated as the authoritative copy of the configuration and will be replicated to all other nodes.

  • The Cluster service performs essential functions on each cluster node, including managing the cluster configuration, coordinating with the instances of the Cluster service running on other nodes, and performing failover operations.

Additional references

  • Managing a Failover Cluster

  • For additional operations information for failover clusters, see http://go.microsoft.com/fwlink/?LinkId=86169.

  • For troubleshooting information for failover clusters, see http://go.microsoft.com/fwlink/?LinkId=86170.

To start or stop the Cluster service on a cluster node by using a Command Prompt window

  1. To open a Command Prompt window, click Start, right-click Command Prompt, and then either click Run as administrator or click Open.

  2. If the User Account Control dialog box appears, confirm that the action it displays is what you want, and then click Continue.

  3. To minimize disruption to clients, before stopping the Cluster service on a node, review the status of your clustered services and applications, and then move those that are currently owned by the node on which you want to stop the Cluster service. To do this:

    1. Type:

      CLUSTER [cluster-name] GROUP /STATUS

    2. Then, for each service or application that you want to move, type:

      CLUSTER [cluster-name] GROUP "service-or-application-name" /MOVE[:node-name]

      If you move the group called Cluster Group, be sure to enclose the names in quotes.

    3. To confirm that you have moved services and applications as intended, press UP ARROW one or more times until you see the following command, and then press ENTER:

      CLUSTER [cluster-name] GROUP /STATUS

  4. Type a command of the following form:

    • To start the Cluster service on a node, type:

      CLUSTER [cluster-name] NODE node-name /START [/WAIT[:timeout-seconds]]

    • To stop the Cluster service on a node, type:

      CLUSTER [cluster-name] NODE node-name /STOP [/WAIT[:timeout-seconds]]

Value | Description
timeout-seconds | The period of time after which you want the command to cancel if it cannot complete. If you do not specify a time-out, the command will try to run until it completes or until the node state changes.
cluster-name | The name of the cluster that you want to affect.
"service-or-application name" | The name of the service or application that you want to affect.
node-name | The name of the node that you want to affect.

To view the complete syntax for these commands, at a command prompt, type:

CLUSTER GROUP /?

CLUSTER NODE /?

Additional considerations

  • To view the status of a given node, type:

    CLUSTER [cluster-name] NODE node-name /STATUS

  • If you are using the Node and File Share Majority quorum option, at least one of the available cluster nodes must contain a current copy of the cluster configuration before you can start the cluster. Otherwise, you must force the starting of the cluster through a particular node. The cluster will then use the copy of the cluster configuration that is on that node and replicate it to all other nodes. To force the cluster to start, on a node that contains a copy of the cluster configuration that you want to use, type the following command:

    NET START CLUSSVC /FQ

    The /FQ option can also be typed as /FORCEQUORUM.

    Note

    When you use this command on a given node, the copy of the cluster configuration that is on that node will be treated as the authoritative copy of the configuration and will be replicated to all other nodes.

  • The Cluster service performs essential functions on each cluster node, including managing the cluster configuration, coordinating with the instances of the Cluster service running on other nodes, and performing failover operations.

Additional references

  • Managing a Failover Cluster

  • For additional operations information for failover clusters, see http://go.microsoft.com/fwlink/?LinkId=86169.

  • For troubleshooting information for failover clusters, see http://go.microsoft.com/fwlink/?LinkId=86170.


Use Validation Tests for Troubleshooting a Failover Cluster

The Validate a Configuration Wizard can be useful when troubleshooting a failover cluster. By running tests related to the symptoms you see, you can learn more about what to do to correct the issue.

Important

If a clustered service or application is using a disk when you start the wizard, the wizard will prompt you about whether to take that clustered service or application offline for the purposes of testing. If you choose to take a clustered service or application offline, it will remain offline until the tests finish.

Membership in the local Administrators group, or equivalent, is the minimum required to complete this procedure. Review details about using the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/?LinkId=83477.

To use validation tests for troubleshooting a failover cluster

  1. Decide whether you want to run all or only some of the available validation tests. You can select or clear the following tests individually or by category:

    • Inventory tests: Provide an inventory of the hardware, software, and settings (such as network settings) on the servers, and information about the storage. For more information, see Understanding Cluster Validation Tests: Inventory.

    • Network tests: Validate that networks are set up correctly for clustering. For more information, see Understanding Cluster Validation Tests: Network.

    • Storage tests: Validate that the storage on which the failover cluster depends is behaving correctly and supports the required functions of the cluster. For more information, see Understanding Cluster Validation Tests: Storage.

    • System Configuration tests: Validate that the system software and configuration settings are compatible across servers. For more information, see Understanding Cluster Validation Tests: System Configuration.

  2. In the Failover Cluster Management snap-in, in the console tree, make sure Failover Cluster Management is selected. Then under Management, click Validate a Configuration.

  3. Follow the instructions in the wizard to specify the servers and the tests, run the tests, and view the results.

Additional considerations

  • To open the failover cluster snap-in, click Start, click Administrative Tools, and then click Failover Cluster Management. If the User Account Control dialog box appears, confirm that the action it displays is what you want, and then click Continue.

  • To view the results of the tests after you close the wizard, choose one of the following:

    • Open the folder systemroot\Cluster\Reports (on a clustered server).

    • In the console tree, right-click the cluster, and then click View Validation Report. This displays the most recent validation report for that cluster.

Additional references

  • Understanding Cluster Validation Tests

  • Managing a Failover Cluster

  • For troubleshooting information for failover clusters, see http://go.microsoft.com/fwlink/?LinkId=86170.


View Events and Logs for a Failover Cluster

When you view events through the Failover Cluster Management snap-in, you can see events for all nodes in the cluster instead of seeing events for only one node at a time. When you generate and view logs by using a Command Prompt window, you can see detailed listings (traces) of the recent series of actions taken by the failover clustering software.

For information about viewing the reports from the failover cluster wizards, see View Reports of the Actions of Failover Cluster Wizards.

This topic provides only selected information about using events and logs for a failover cluster. For additional information, see http://go.microsoft.com/fwlink/?LinkId=92314.

Membership in the local Administrators group, or equivalent, is the minimum required to complete this procedure. Review details about using the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/?LinkId=83477.

Viewing events and logs for a failover cluster

  • Using the Windows interface

  • Using a Command Prompt window

To view events and logs for a failover cluster by using the Windows interface

  1. In the Failover Cluster Management snap-in, if the cluster is not displayed, in the console tree, right-click Failover Cluster Management, click Manage a Cluster, and then select or specify the cluster that you want.

  2. If the console tree is collapsed, expand the tree under the cluster for which you want to view events.

  3. In the console tree, right-click Cluster Events and then click Query.

  4. In the Cluster Events Filter dialog box, select the criteria for the events that you want to display.

    To return to the default criteria, click the Reset button.

  5. Click OK.

  6. To sort the events, click a heading, for example, Level or Date and Time.

  7. To view a specific event, click the event and view the details in the Event Details pane.

Additional considerations

  • To open the failover cluster snap-in, click Start, click Administrative Tools, and then click Failover Cluster Management. If the User Account Control dialog box appears, confirm that the action it displays is what you want, and then click Continue.

  • You can also use Event Viewer to open a log related to failover clustering. To locate the log, in Event Viewer, expand Applications and Services Logs, expand Microsoft, expand Windows, and then expand FailoverClustering. The log file is stored in systemroot\system32\winevt\Logs.

Additional references

  • Managing a Failover Cluster

  • View Reports of the Actions of Failover Cluster Wizards

  • For additional information about events and logs for failover clusters, see http://go.microsoft.com/fwlink/?LinkId=92314.

  • For troubleshooting information for failover clusters, see http://go.microsoft.com/fwlink/?LinkId=86170.

To view detailed logs for a failover cluster by using a Command Prompt window

  1. To open a Command Prompt window, click Start, right-click Command Prompt, and then either click Run as administrator or click Open.

  2. If the User Account Control dialog box appears, confirm that the action it displays is what you want, and then click Continue.

  3. Enter a command of the following form:

    CLUSTER [cluster-name] LOG /GEN /COPY:"pathname"

    A detailed trace log from each of the nodes is generated and copied to the path you specify.

  4. To change to the folder where the log is located, note the pathname you specified in the previous step and enter a command of the following form:

    CD "pathname"

  5. Type:

    DIR

  6. To view a log in Notepad, find the name of the log file and type:

    NOTEPAD "filename"

Value | Description
cluster-name | The name of the cluster that you want to generate a log for.
"pathname" | The drive and path of the log file that you want to generate or that was generated.
"filename" | The name of the log file that was generated.

To view the complete syntax for this command, at a command prompt, type:

CLUSTER LOG /?

Additional references

  • Managing a Failover Cluster

  • View Reports of the Actions of Failover Cluster Wizards

  • For additional information about events and logs for failover clusters, see http://go.microsoft.com/fwlink/?LinkId=92314.

  • For troubleshooting information for failover clusters, see http://go.microsoft.com/fwlink/?LinkId=86170.


View Reports of the Actions of Failover Cluster Wizards

Each of the failover cluster wizards in Windows Server 2008 produces a report of its actions. This topic describes how to view the report of a particular wizard by clicking a button on the last page of that wizard or by opening a report from a specific folder in Windows Server 2008.

Membership in the local Administrators group, or equivalent, is the minimum required to complete this procedure. Review details about using the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/?LinkId=83477.

To view a report of the actions of a failover cluster wizard

  • Choose one of the following options:

    • If the wizard for which you want to view a report is displayed, proceed through the wizard until you are on the Summary page, and then click View Report.

    • If you ran the wizard but it is not displayed now, use Windows Explorer or another method to navigate to the following location and open the report you want:

      systemroot\Cluster\Reports

Additional considerations

  • To open the failover cluster snap-in, click Start, click Administrative Tools, and then click Failover Cluster Management. If the User Account Control dialog box appears, confirm that the action it displays is what you want, and then click Continue.

Additional references

  • Managing a Failover Cluster

  • View Events and Logs for a Failover Cluster

  • For troubleshooting information for failover clusters, see http://go.microsoft.com/fwlink/?LinkId=86170.


Resources for Failover Clusters

For more information about failover clusters, see the following resources on the Microsoft Web site:

  • For a list of links to a variety of topics about failover clusters, see http://go.microsoft.com/fwlink/?LinkId=68633.

  • For information about hardware compatibility for Windows Server 2008, see http://go.microsoft.com/fwlink/?LinkID=59821.

  • For design and deployment information for failover clusters, see http://go.microsoft.com/fwlink/?LinkId=86168.

  • For operations information for failover clusters, see http://go.microsoft.com/fwlink/?LinkId=86169.

  • For troubleshooting information for failover clusters, see http://go.microsoft.com/fwlink/?LinkId=86170.


User Interface: The Failover Cluster Management Snap-In

This section contains descriptions of the following elements of the Failover Cluster Management snap-in for Windows Server 2008:

  • Add Resource Type Dialog Box

  • <ClusteredInstance> Properties: General Tab

  • <Resource> Properties: Advanced Policies tab

  • <Resource> Properties: Dependencies Tab

  • <Resource> Properties: General Tab

  • <Resource> Properties: Policies Tab

Additional references

Overview of Failover Clusters


Add Resource Type Dialog Box

Item | Details
Resource DLL path and file name | Specify the path and file name of the resource DLL that the Cluster service should use when it communicates with your service or application. A resource DLL monitors and controls the associated service or application in response to commands and requests from the Cluster service and associated software components. For example, the resource DLL saves and retrieves service or application properties in the cluster database, brings the resource online and takes it offline, and checks the health of the resource.
Resource type name | Specify the name that the Cluster service uses for the resource type. This name stays the same regardless of the regional and language options that are currently selected.
Resource type display name | Specify the name that is displayed for the resource type. This name might vary when you make changes to regional and language options.


<ClusteredInstance> Properties: General Tab

Item Details

Preferred owners

Select nodes from the list, and then use the buttons to list them in order.

If you want this service or application to be moved to a particular node whenever that node is available:

  • Select the check box for a node and use the buttons to place it at the top of the list.

  • On the Failover tab, ensure that failback is allowed for this service or application.

Note that in the Preferred owners list, even if you clear the check box for a node, the service or application could fail over to that node for either of two reasons:

  • You have not specified any preferred owners.

  • No node that is a preferred owner is currently online.

To ensure that a clustered service or application never fails over to a particular node:

  1. Select an individual resource in the service or application.

  2. Open the Properties sheet for that resource.

  3. Select the Advanced Policies tab.

  4. Configure Possible owners.


<Resource> Properties: Advanced Policies tab

Item Details

Possible owners

Clear the check box for a node only if you want to prevent this resource (and the clustered service or application that contains this resource) from failing over to that node. Otherwise, leave the boxes checked for all nodes.

Note that if you leave the box for only one node checked, this resource (and the clustered service or application that contains this resource) cannot fail over.

Basic resource health check interval

We recommend that you use the standard time period for the resource type unless you have a reason to change it.

This health check is also known as the Looks Alive poll.

Thorough resource health check interval

We recommend that you use the standard time period for the resource type unless you have a reason to change it.

This health check is also known as the Is Alive poll.


<Resource> Properties: Dependencies Tab

When you specify resource dependencies, you control the order in which the Cluster service brings resources online and takes them offline. A dependent resource is:

  • Brought online after the resource or resources it depends on.

  • Taken offline before the resource or resources it depends on.

Note

After specifying dependencies, to see a report, right-click the clustered service or application (not the resource), and then click Show Dependency Report.

This tab contains the following controls:

Item Details

Resource

Click the box, and then select a resource from the list. The list contains the other resources in this clustered service or application that have not already been selected.

AND/OR

For the second or later lines:

  • Specify AND if both the resource in that line and one or more previously listed resources must be online before the dependent resource is brought online.

  • Specify OR if either the resource in that line or another previously listed resource must be online before the dependent resource is brought online. (The dependent resource can also be brought online if both are online.)

Notice that gray brackets appear to showhow the listings are grouped, based on the AND/OR settings.

Insert

When you select a line in the list and click Insert, a line is added to the list before the selected line.

Delete

When you select a line in the list and click Delete, the line is deleted.


<Resource> Properties: General Tab

If a disk that you are using in a failover cluster has failed, you can use Repair (on the General tab of the Properties sheet) to assign a different disk.

Item Details

Repair button (for a disk)

When you click this button, you can stop using a failed disk and assign a different disk to this service or application. The disk that you assign must be one that can be used for clustering but is not yet clustered.

For more information about disks that can be used for clustering, see "List Potential Cluster Disks" in Understanding Cluster Validation Tests: Storage.

Caution

The Repair button does not recover data.

Before using the Repair button, expose a LUN to each node of the cluster, but do not add that LUN to the cluster (through the Failover Cluster Management snap-in).

You can restore the data to the disk before or after using the Repair button.


<Resource> Properties: Policies Tab

Item Details

Maximum restarts in the specified period

Specify the number of times that you want the Cluster service to try to restart the resource during the period you specify. If the resource cannot be started after this number of attempts in the specified period, the Cluster service will take actions as specified by other fields of this tab.

For example, if you specify 3 for Maximum restarts in the specified period and 15:00 for the period, the Cluster service attempts to restart the resource three times in a given 15 minute period. If the resource still does not run, instead of trying to restart it a fourth time, the Cluster service will take the actions that you specified in the other fields of this tab.

Period (mm:ss)

Specify the length of the period (minutes and seconds) during which the Cluster service counts the number of times that a resource has been restarted. For an example of how the period works with the maximum number of restarts, see the previous cell in this table.

If restart is unsuccessful, fail over all resources in this service or application

Use this box to control the way the Cluster service responds if the maximum restarts fail:

  • Select this box if you want the Cluster service to respond by failing the clustered service or application over to another node.

  • Clear this box if you want the Cluster service to respond by leaving this clustered service or application running on this node (even if this resource is in a failed state).

If all the restart attempts fail, begin restarting again after the specified period (hh:mm)

Select this box if you want the Cluster service to go into an extended waiting period after attempting the maximum number of restarts on the resource. Note that this extended waiting period is measured in hours and minutes. After the waiting period, the Cluster service will begin another series of restarts. This is true regardless of which node owns the clustered service or application at that time.