Overview and Requirements for a Failover Cluster Running Windows Server 2008 R2

Updated: July 8, 2010

Applies To: Windows Server 2008 R2

This topic provides an overview of the structure of a failover cluster, and it describes the hardware and software requirements for a cluster. For a list of all topics in this guide, see Migrating Clustered Services and Applications to Windows Server 2008 R2 Step-by-Step Guide.

Servers in a failover cluster can function in a variety of roles and can support a variety of services and applications. A failover cluster usually includes a storage unit that is physically connected to all the servers in the cluster. The following diagram shows a two-node failover cluster connected to a storage unit. For simplicity, the illustration shows two nodes, but clusters can have additional nodes.

Failover cluster with two nodes connected to a storage unit

Storage volumes or logical unit numbers (LUNs) exposed to the nodes in a cluster must not be exposed to other servers, including servers in another cluster. The following diagram illustrates this:

Two failover clusters, each with its own LUNs

Note that for the maximum availability of any server, it is important to follow best practices for server management—for example, carefully managing the physical environment of the servers, testing software changes before fully implementing them, and carefully keeping track of software updates and configuration changes on all clustered servers.

Requirements for a failover cluster

To create a failover cluster (regardless of the service or application that the nodes provide), you need the hardware, software, accounts, and network infrastructure described in the following sections:

Hardware requirements for a failover cluster

Software requirements for a failover cluster

Network infrastructure and domain account requirements for a failover cluster

We recommend that you first use the information provided in this guide in a test lab environment. A Step-by-Step guide is not necessarily meant to be used to deploy Windows Server features without the accompanying documentation (as listed in the Additional References section), and it should be used with discretion as a stand-alone document.

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.

For information about hardware compatibility for Windows Server 2008 R2, see [Windows Server Catalog](https://go.microsoft.com/fwlink/?linkid=139145) (https://go.microsoft.com/fwlink/?LinkId=139145).  
  
For information about the maximum number of servers that you can have in a failover cluster, see [Edition Comparison by Technical Specification](https://go.microsoft.com/fwlink/?linkid=139146) (https://go.microsoft.com/fwlink/?LinkId=139146).  
  

• 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 R2." If you use iSCSI, your network adapters should be dedicated to either network communication or iSCSI, not both.

  In the network infrastructure that will connect your cluster nodes, avoid having single points of failure. There are multiple ways to accomplish 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.

For more details about the network configuration that is 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 (SAS) or Fibre Channel: If you are using Serial Attached SCSI or Fibre Channel, in all clustered servers, all components of the storage stack should be identical. It is required that the multipath I/O (MPIO) software and Device Specific Module (DSM) software components be identical.  It is recommended that the mass-storage device controllers—that is, the host bus adapter (HBA), HBA drivers, and HBA firmware—that are attached to cluster storage be identical. If you use dissimilar HBAs, you should verify with the storage vendor that you are following their supported or recommended configurations.

  - **For iSCSI**: If you are using iSCSI, each clustered server should have one or more network adapters or host bus adapters that are dedicated to the cluster storage. The network that you use for iSCSI should not be used for network communication. In all clustered servers, the network adapters that 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 [iSCSI Cluster Support: Frequently Asked Questions](https://go.microsoft.com/fwlink/?linkid=61375) (https://go.microsoft.com/fwlink/?LinkId=61375).  
      

• Storage: You must use shared storage that is compatible with Windows Server 2008 R2. 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 disk witness (described at the end of this subsection). Other disks contain the files that are 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. If you have a disk witness or use Cluster Shared Volumes, the partition for each of those must be NTFS.

    For Cluster Shared Volumes, there are no special requirements other than the requirement for NTFS.

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

  The disk witness is a disk in the cluster storage that is designated to hold a copy of the cluster configuration database. A disk witness is part of some but not all quorum configurations, and it is recommended for most clusters with an even number of nodes. You do not need to migrate a disk witness (and it is not eligible for migration), because the Create a Cluster Wizard automatically creates the quorum configuration that will provide the highest availability for your cluster. You can adjust the configuration as needed as you change the cluster. For more information, see Failover Cluster Step-by-Step Guide: Configuring the Quorum in a Failover Cluster (https://go.microsoft.com/fwlink/?LinkId=180628).

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 R2.

Failover clusters include the following new requirements for storage:  
  
  - Improvements in failover clusters (as compared to server clusters in Windows Server 2003) 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 that is 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 R2, your multipath solution must be based on Microsoft Multipath I/O (MPIO). Your hardware vendor usually supplies an MPIO device-specific module (DSM) for your hardware, although Windows Server 2008 R2 includes one or more DSMs as part of the operating system.

Software requirements for a failover cluster

All the servers in a failover cluster must either run Windows Server 2008 R2 for Itanium-Based Systems or the x64-based version of Windows Server 2008 R2. Nodes within a single failover cluster cannot run different versions.

The Failover Clustering feature is included in some server products, including Windows Server 2008 R2 Enterprise and Windows Server 2008 R2 Datacenter. The Failover Clustering feature is not included in Windows Server 2008 R2 Standard or Windows Web Server 2008 R2.

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

If you are migrating a Generic Application, Generic Script, or Generic Service resource, you must confirm that any associated application is compatible with Windows Server 2008 R2, or any associated service exists in Windows Server 2008 R2 and has the same name as in the operating system from which you are migrating. Test the application or service (separately, not as part of a cluster) to confirm that it runs as expected.

Network infrastructure and domain account requirements for a failover cluster

For a failover cluster, you need the following network infrastructure 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 use 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 that are 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 the Create Computer Objects and Read All Properties permissions in the domain.