Overview and Requirements for a Two-Node Failover Cluster

Applies To: Windows Server 2008

This topic provides an overview of the structure of a two-node failover cluster and describes the hardware and software requirements. For a list of other topics in this guide, see Migrating Cluster Settings from Windows Server 2003 to Windows Server 2008 Step-by-Step Guide.

Servers in a failover cluster can function in a variety of roles, including the file server role, and they can provide high availability for a variety of other services and applications. A failover cluster usually includes a storage unit that is physically connected to all the servers in the cluster, although any given volume in the storage is only accessed by one server at a time. The following diagram shows a two-node failover cluster 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.

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 two-node failover cluster

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

Hardware requirements for a two-node failover cluster

Software requirements for a two-node failover cluster

Network infrastructure and domain account requirements for a two-node 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 two-node failover cluster

You will need the following hardware for a two-node failover cluster:

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

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

  In the network infrastructure that will connect 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.

For more details about the network configuration required for a failover cluster, see Network infrastructure and domain account requirements for a two-node 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, the mass-storage device controllers that are dedicated to the cluster storage should be identical between clustered servers. They should also use the same firmware and driver versions.

  - **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 cluster communications. 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.  
      
    For more information about iSCSI, see the iSCSI FAQ on the Microsoft Web site ([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.

  For a two-node failover cluster, the storage should contain at least two separate volumes (LUNs), configured at the hardware level. One volume will function as the witness disk (described in the next paragraph). At least one volume will contain data being accessed by users. 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).

  The witness disk is a disk in the cluster storage that is designated to hold a copy of the cluster configuration database. (A witness disk is part of some but not all quorum configurations.) For this two-node failover cluster, the quorum configuration will be Node and Disk Majority, the default for a cluster with an even number of nodes. Node and Disk Majority means that the nodes and the witness disk each contain replicas of the cluster configuration, and the cluster has quorum as long as a majority (two out of three) of these replicas are available.

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.

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, you can 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, 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.

Software requirements for a two-node failover cluster

The servers for a two-node failover cluster must run the same version of Windows Server 2008, including the same hardware version (32-bit, x64-based, or Itanium architecture-based). They should also have the same software updates (patches) and service packs.

If you are migrating a Generic Application, Generic Script, or Generic Service resource, you must also confirm that any associated application is compatible with Windows Server 2008, or any associated service exists in Windows Server 2008 and has the same name as in Windows Server 2003. 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 two-node failover cluster

You will need the following network infrastructure for a two-node 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 the 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 a cluster node in a central office that uses one physical network, and another node 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 two-node 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 controller: We recommend that your clustered servers be member servers. If they are, you need an additional server that acts as the domain controller in the domain that contains your failover cluster.

• Clients: As needed for testing, you can connect one or more networked clients to the failover cluster that you create, and observe the effect on a client when you move or fail over clustered services or applications from one cluster node to the other.

• 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, but 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 assigned Create Computer Objects and Read All Properties permissions in the domain.

• Computer account permission adjustments for migration of Network Name resources with Kerberos enabled: This requirement applies only if you are migrating one or more Network Name resources with Kerberos enabled. The Kerberos setting is displayed in Cluster Administrator in the Properties for the Network Name resource. The requirement is for a permissions change that must be made in Active Directory Users and Computers (on a domain controller) during the migration process. After creating the new failover cluster, use Active Directory Users and Computers to locate the computer accounts (computer objects) for any Network Name resources you will migrate that have Kerberos enabled. Make sure you know the correct name of the new cluster, and modify the accounts associated with the Network Name resources to assign Full Control over these accounts to the computer account of the failover cluster. (The computer account of the failover cluster will be created automatically when you run the Create Cluster wizard.) This will give the cluster the necessary permissions for these resources.

  Note that there is an additional Kerberos setting, RequireKerberos, that is a private property associated with Network Name resources. You can view this setting through the command line only. To view the setting, at a command prompt on a cluster node, type:

  CLUSTER RESOURCE "NetworkNameResource" /PRIV

  If RequireKerberos is set to 1, Kerberos authentication is required for that resource. If RequireKerberos is set to 0, Kerberos authentication is not required.