Windows Server 2008 R2 : Overview of Failover Clusters

Failover Cluster Quorum Models

As previously stated, Windows Server 2008 R2 failover clusters support four different cluster quorum models. Each of these four models is best suited for specific configurations but if all the nodes and shared storage are configured, specified, and available during the installation of the failover cluster, the best-suited quorum model is automatically selected.

Node Majority Quorum

The Node Majority Quorum model has been designed for failover cluster deployments that contain an odd number of cluster nodes. When determining the quorum state of the cluster, only the number of available nodes is counted. A cluster using the Node Majority Quorum is called a Node Majority cluster. A Node Majority cluster remains up and running if the number of available nodes exceeds the number of failed nodes. As an example, in a five-node cluster, three nodes must be available for the cluster to remain online. If three nodes fail in a five-node Node Majority cluster, the entire cluster is shut down. Node Majority clusters have been designed and are well suited for geographically or network dispersed cluster nodes, but for this configuration to be supported by Microsoft, it takes serious effort, quality hardware, a third-party mechanism to replicate any back-end data, and a very reliable network. Once again, this model works well for clusters with an odd number of nodes.

Node and Disk Majority Quorum

The Node and Disk Majority Quorum model determines whether a cluster can continue to function by counting the number of available nodes and the availability of the cluster witness disk. Using this model, the cluster quorum is stored on a cluster disk that is accessible and made available to all nodes in the cluster through a shared storage device using Serial Attached SCSI (SAS), Fibre Channel, or iSCSI connections. This model is the closest to the traditional single-quorum device cluster configuration model and is composed of two or more server nodes that are all connected to a shared storage device. In this model, only one copy of the quorum data is maintained on the witness disk. This model is well suited for failover clusters using shared storage, all connected on the same network with an even number of nodes. For example, on a 2-, 4-, 6-, 8-, or 16-node cluster using this model, the cluster continues to function as long as half of the total nodes are available and can contact the witness disk. In the case of a witness disk failure, a majority of the nodes need to remain up and running for the cluster to continue to function. To calculate this, take half of the total nodes and add one and this gives you the lowest number of available nodes that are required to keep a cluster running when the witness disk fails or goes offline. For example, on a 6-node cluster using this model, if the witness disk fails, the cluster will remain up and running as long as 4 nodes are available, but on a 2-node cluster, if the witness disk fails, both nodes will need to remain up and running for the cluster to function.

Node and File Share Majority Quorum

The Node and File Share Majority Quorum model is very similar to the Node and Disk Majority Quorum model but instead of a witness disk, the quorum is stored on file share. The advantage of this model is that it can be deployed similarly to the Node Majority Quorum model but as long as the witness file share is available, this model can tolerate the failure of half of the total nodes. This model is well suited for clusters with an even number of nodes that do not utilize shared storage or clusters that span sites. This is the preferred and recommended quorum configuration for geographically dispersed failover clusters.

No Majority: Disk Only Quorum

The No Majority: Disk Only Quorum model is best suited for testing the process and behavior of deploying built-in or custom services and/or applications on a Windows Server 2008 R2 failover cluster. In this model, the cluster can sustain the failover of all nodes except one, as long as the disk containing the quorum remains available. The limitation of this model is that the disk containing the quorum becomes a single point of failure and that is why this model is not well suited for production deployments of failover clusters.

As a best practice, before deploying a failover cluster, determine if shared storage will be used, verify that each node can communicate with each LUN presented by the shared storage device, and when the cluster is created, add all nodes to the list. This ensures that the correct recommended cluster quorum model is selected for the new failover cluster. When the recommended model utilizes shared storage and a witness disk, the smallest available LUN will be selected. This can be changed, if necessary, after the cluster is created.

Choosing Applications for Failover Clusters

Many applications can run on failover clusters, but it is important to choose and test those applications wisely. Although many can run on failover clusters, the application might not be optimized for clustering or supported by the software vendor or Microsoft when deployed on Windows Server 2008 R2 failover clusters. Work with the vendor to determine requirements, functionality, and limitations (if any). Other major criteria that should be met to ensure that an application can benefit and adapt to running on a cluster are the following:

• Because clustering is IP-based, the cluster application or applications must use an IP-based protocol.

• Applications that require access to local databases must have the option of configuring where the data can be stored so a drive other than the system drive can be specified for data storage that is separate from the storage of the application core files.

• Some applications need to have access to data regardless of which cluster node they are running on. With these types of applications, it is recommended that the data is stored on a shared disk resource that will failover with the Services and Applications group. If an application will run and store data only on the local system or boot drive, the Node Majority Quorum or the Node and File Share Majority Quorum model should be used, along with a separate file replication mechanism for the application data.

• Client sessions must be able to reestablish connectivity if the application encounters a network disruption or fails over to an alternate cluster node. During the failover process, there is no client connectivity until an application is brought back online. If the client software does not try to reconnect and simply times out when a network connection is broken, this application might not be well suited for failover or NLB clusters.

Cluster-aware applications that meet all of the preceding criteria are usually the best applications to deploy in a Windows Server 2008 R2 failover cluster. Many services built in to Windows Server 2008 R2 can be clustered and will failover efficiently and properly. If a particular application is not cluster-aware, be sure to investigate all the implications of the application deployment on Windows Server 2008 R2 failover clusters before deploying or spending any time prototyping the solution.

Shared Storage for Failover Clusters

Shared disk storage is a requirement for Windows Server 2008 R2 failover clusters using the Node and Disk Majority Quorum and the Disk Only Quorum models. Shared storage devices can be a part of any cluster configuration and when they are used, the disks, disk volumes, or LUNs presented to the Windows systems must be presented as basic Windows disks.

All storage drivers must be digitally signed and certified for use with Windows Server 2008 R2. Many storage devices certified for Windows Server 2003 or even Windows Server 2008 might not work with Windows Server 2008 R2 and either simply cannot be used for failover cluster shared storage, or might require a firmware and driver upgrade to be supported. One main reason for this is that all failover shared storage must comply with SCSI-3 Architecture Model SAM-2. This includes any and all legacy and serial attached SCSI controllers, Fibre Channel host bus adapters, and iSCSI hardware- and software-based initiators and targets. If the cluster attempts to perform an action on a LUN or shared disk and the attempt causes an interruption in communication to the other nodes in the cluster or any other system connected to the shared storage device, data corruption can occur and the entire cluster and each storage area network (SAN)–connected system might lose connectivity to the storage.

When LUNS are presented to failover cluster nodes, each LUN must be presented to each node in the cluster. Also, when the shared storage is accessed by the cluster and other systems, the LUNs must be masked or presented only to the cluster nodes and the shared storage device controllers to ensure that no other systems can access or disrupt the cluster communication. There are strict requirements for shared storage support, especially with failover clusters. Using SANs or other types of shared storage must meet the following list of requirements and recommendations:

• All Fibre, SAS, and iSCSI host bus adapters (HBAs) and Ethernet cards used with iSCSI software initiators must obtain the “Designed for Microsoft Windows” logo for Windows Server 2008 R2 and have suitable signed device drivers.

• SAS, Fibre, and iSCSI HBAs must use StorPort device drivers to provide targeted LUN resets and other functions inherent to the StorPort driver specification. SCSIport was at one point supported for two-node clusters, but if a StorPort driver is available, it should be used to ensure support from the hardware vendors and Microsoft.

• All shared storage HBAs and back-end storage devices, including iSCSI targets, Fibre, and SAS storage arrays, must support SCSI-3 standards and must also support persistent bindings or reservations of LUNs.

• All shared storage HBAs must be deployed with matching firmware and driver versions. Failover clusters using shared storage require a very stable infrastructure and applying the latest storage controller driver to an outdated HBA firmware can cause very undesirable situations and might disrupt access to data.

• All nodes in the cluster should contain the same HBAs and use the same version of drivers and firmware. Each cluster node should be an exact duplicate of each other node when it comes to hardware selection, configuration, and driver and firmware revisions. This allows for a more reliable configuration and simplifies management and standardization.

• When iSCSI software initiators are used to connect to iSCSI software- or hardware-based targets, the network adapter used for iSCSI communication should be connected to a dedicated switch, should not be used for any cluster communication, and cannot be a teamed network adapter as teamed adapters are not supported with iSCSI.

For Microsoft to officially support failover clusters and shared storage, in addition to the hardware meeting the requirements listed previously, the entire configuration of the server brand and model, local disk configuration, HBA or network card controller firmware and driver version, iSCSI software initiator software, storage array, and storage array controller firmware or SAN operating system version must be tested as a whole system before it will be considered a “Windows Server 2008 R2 Failover Cluster Supported Configuration.” The point to keep in mind is that if a company really wants to consider using failover clusters, they should research and find a suitable solution that will meet their budget. If a tested and supported solution cannot be found within their price range, the company should consider alternative solutions that can restore systems in about an hour or a few hours if not within a few minutes. The truth is that failover clusters are not for everyone, they are not for the faint of heart, and they are not within every organization’s information technology budget from an implementation, training, and support standpoint. Administrators who want to test failover cluster configurations to gain knowledge and experience can leverage several low-cost shared storage alternatives, including using the Windows iSCSI initiator and a software-based iSCSI target, but they must remember that the configuration may not be supported by Microsoft in case a problem is encountered or data loss results.

Serial Attached SCSI (SAS) Storage Arrays

Serial Attached SCSI or SAS storage arrays provide organizations with affordable, entry-level, hardware-based direct attached storage arrays suitable for Windows Server 2008 R2 clusters. SAS storage arrays commonly are limited to four hosts, but some models support extenders to add additional hosts as required. One of the major issues with direct attached storage is that replication of the data within the storage is usually not achievable without involving one of the host systems or software provided by the hardware vendor.

Fibre Channel Storage Arrays

Using Fibre Channel (FC) HBAs, Windows Server 2008 R2 can access both shared and nonshared disks residing on a SAN connected to a common FC switch. This allows both the shared storage and operating system volumes to be located on the SAN, if desired, to provide diskless servers. In many cases, however, diskless servers might not be desired if the operating system performs many paging actions because the cache on the storage controllers can be used up very fast and can cause delays in disk read and write operations for dedicated cluster storage. If this is desired, however, the SAN must support this option and be configured to present the operating system dedicated LUNs to only a single host exclusively. The LUNs defined for shared cluster storage must be zoned and presented to every node in the cluster, and no other systems. The LUN zoning or masking in many cases is configured on the Fibre Channel switch that connects the cluster nodes and the shared storage device. This is a distinct difference between direct attached storage and FC or iSCSI shared storage. Both FC and iSCSI require a common fiber or Ethernet switch and network to establish and maintain connections between the hosts and the storage.

A properly configured FC zone for a cluster will include the World Wide Port Number (WWPN) of each cluster host’s FC HBAs and the WWPN of the HBA controller(s) from the shared storage device. If either the server or the storage device utilizes multiple HBAs to connect to a single or multiple FC switches to provide failover or load-balancing functionality, this is known as Multipath I/O (MPIO) and a qualified driver for MPIO management and communication must be used. Also, the function of either MPIO failover and/or MPIO load balancing must be verified as approved for Windows Server 2008 R2. Consult the shared storage vendor, including the Fibre Channel switch vendor, for documentation and supported configurations, and check the cluster Hardware Compatibility List (HCL) on the Microsoft website to find approved configurations.

iSCSI Storage

When organizations want to utilize iSCSI storage for Windows Server 2008 R2 failover clusters, security and network isolation is highly recommended. iSCSI utilizes an initiator on the host that requires access to the LUNs or iSCSI targets. Targets are located or hosted on iSCSI target portals. Using the target portal interface, the target must be configured to be accessed by multiple initiators in a cluster configuration. Both the iSCSI initiators and target portals come in software- and hardware-based models, but both models utilize IP networks for communication between the initiators and the targets. The targets need to be presented to Windows as a basic disk. When standard network cards will be used for iSCSI communication on Windows Server 2008 R2 systems, the built-in Windows Server 2008 R2 iSCSI initiator can be used, provided that the iSCSI target can support the authentication and security options provided, if used.

Regardless of the choice of the Microsoft iSCSI initiator, software- or hardware-based initiators, or targets, iSCSI communication should be deployed on isolated network segments and preferably dedicated network switches and network interface cards. Furthermore, the LUNs presented to the failover cluster should be masked and secured from any systems that are not nodes participating in the cluster, by using authentication and IPSec communication, when possible. Within the Windows Server 2008 R2 operating system, the iSCSI HBA or designated network card should not be used for any failover cluster configuration and cannot be deployed using network teaming software—or it will not be supported by Microsoft.

Hopefully by now, it is very clear that Microsoft only wants to support organizations that deploy failover clusters on tested and approved entire systems, but in many cases, failover clusters can still be deployed and can function, as the Create a Cluster Wizard will allow a cluster to be deployed that is not in a supported configuration.

Multipath I/O

Windows Server 2008 R2 supports Multipath I/O to external storage devices such as SANs and iSCSI targets when multiple HBAs are used in the local system or by the shared storage. Multipath I/O can be used to provide failover access to disk storage in case of a controller or HBA failure, but some drivers also support load balancing across HBAs in both standalone and failover cluster deployments. Windows Server 2008 R2 provides a built-in Multipath I/O driver for iSCSI that can be leveraged when the manufacturer conforms to the necessary specifications to allow for the use of this built-in driver. The iSCSI initiator built in to Windows Server 2008 R2 is very user friendly and makes adding iSCSI targets simple and easy by making new targets reconnect by default. Multipath I/O (MPIO) support is also installed by default, and this is different from previous releases of the iSCSI initiator software.

Volume Shadow Copy for Shared Storage Volume

The Volume Shadow Copy Service (VSS) is supported on shared storage volumes. Volume Shadow Copy can take a point-in-time snapshot of an entire volume, enabling administrators and users to recover data from a previous version. Furthermore, failover clusters and the entire Windows Server Backup architecture utilize VSS to store backup data. Many of today’s services and applications that are certified to work on Windows Server 2008 R2 failover clusters are VSS compliant; careful choice and consideration should be made when choosing an alternative backup system, unless the system is provided by the shared storage manufacturer and certified to work in conjunction with VSS, Windows Server 2008 R2, and the service or application running on the failover cluster.

Failover Cluster Node Operating System Selection

Windows Server 2008 R2 supports only the 64-bit operating systems but the nodes must be running either the Enterprise or Datacenter Edition. If any services or applications require deployment on 32-bit operating systems, and if this application is deployed on a Windows Server 2008 R2 failover cluster, performance of that application might suffer and should be performance tested thoroughly before deploying these applications on production failover clusters. Also, verify that these 32-bit applications are indeed supported on Windows Server 2008 R2 failover clusters and not just on Windows Server 2008 failover clusters or Windows Server 2003 server clusters.