Clustering in a SAN Environment
Running the same application on two or more servers helps ensure high application availability if one of the servers fails. Clustering software controls the fail-over process so that the application continues to run on the second server, without any loss of data and without interruption in service. Clustering offers other benefits too, including greater processing power, access to increased storage capacity, and better I/O performance, due to an increased I/O paths between servers and storage.
Shared storage can be considered a SAN, strict speaking, because clusters require shared access to the same storage device. However, adding a cluster to a preexisting SAN that many other servers have access to is quite different than simply creating an isolated cluster.
On This Page
 | Clustering on a SAN |
| Clustering Solutions for Fibre Channel |
| Clustering Solutions for iSCSI |
Clustering on a SAN
Because of their complexity, correct configuration of clusters on a SAN requires additional attention to the following:
| • | Hardware Interoperability In SAN configurations that deploy hardware from multiple vendors, interoperability issues can cause problems when clustering. For this reason, Microsoft provides a hardware compatibility list of tested hardware configurations known to work with Microsoft clustering solutions. Additionally, it is critical to ensure that host bus adapter (HBA) firmware versions are the same on all hosts on the cluster. |
| • | SCSI Standards Depending on whether the SCSI-2 or SCSI-3 protocol is implemented in the hardware, the identification and management of devices on the SAN may be optimal for correctly allocating storage resources for clustering, especially during failover and recovery operations. |
| • | SAN Standards SANs were originally designed to support only a few hosts, each built on the same operating system. Today SANs are expected to support many hosts, often with different platforms running on them. In clustering scenarios, server access to storage must be controlled both by LUN masking and zoning. Note that not all hardware solutions correctly implement access control solutions. |
Clustering Solutions for Fibre Channel
It is common for devices on the SAN to join and exit the network on a regular basis. How these and other state changes (such as errors) are handled impacts SAN performance. If the SCSI bus that monitors state changes responds by resetting all the other devices that share the same wire, performance is disrupted. Such behavior is highly problematic for clustered devices, because the goal of high availability is compromised. The new Storport miniport driver provides hierarchical reset capabilities, enabling highly reliable clustering solutions on Fibre Channel SANs. For further information, see Storport in Windows Server 2003.
Depending on the topology used to construct the SAN, it may not be recommended to clustering Windows Server operating system applications.
| • | Arbitrated Loop Configurations While manufacturers and vendors allow multiple clusters to be hosted on a single arbitrated loop, this configuration has restrictions that can negatively impact the mechanisms that the cluster service uses to protect disks in a cluster. For this reason, Microsoft does not recommend the use of arbitrated loop configurations. If they must be used with clusters, they should be limited to small, relatively static cluster configurations, and only one cluster should be attached to any single arbitrated loop. | ||||||
| • | Switched Fabrics Because switched fabrics are highly stable, devices can enter or leave the SAN without negatively impacting the remaining devices on the network. For this reason, both single and multiple clusters are fully supported on switched fabrics. he following three precautions must be taken when setting up clusters on the fabric:
|
For further details and precautions in setting up Fibre Channel clusters, see Microsoft Windows Clustering: Storage Area Networks.
Clustering Solutions for iSCSI
iSCSI is designed to work well in clustering environments, for both Windows Server 2003 and Windows 2000 server clusters. LUN masking and zoning are built directly into the iSCSI protocol, making access control on the SAN simpler than on Fibre Channel.
As with Fibre Channel topologies, there are a few restrictions:
| • | The iSCSI SAN must be isolated (physically or virtually with VLANs) |
| • | All iSCSI hardware used in the cluster configuration must be qualified under the Designed for Windows ISCSI Logo Program. |
| • | Microsoft currently supports only customers using iSCSI with Windows Server 2003 clusters. |
For details on support of iSCSI Clusters, refer to the iSCSI Cluster support FAQ. For information on configuring clustering with iSCSI, see the Microsoft iSCSI Deployment whitepaper.