iSCSI Cluster Support: Frequently Asked Questions

Published: May 28, 2004 | Updated: February 21, 2006
**
**

This FAQ answers commonly asked questions about iSCSI (Internet Small Computer System Interface) support when used with a Microsoft Windows Server 2003 failover cluster. Click a question to view its answer. To view all the answers at one time, select the View all answers check box.


Q.On which platforms is iSCSI supported with Microsoft Cluster Server?
A.

Server clustering supports iSCSI clustered shared storage on Windows Server 2003 Service Pack (SP) 1 or higher. Depending on the configuration, the following are supported:

Up to eight-node clusters, if using Storport with iSCSI Host Bus Adapter (HBA) Storport miniport.

Up to eight-node clusters, if using the Microsoft iSCSI Software Initiator.

Q.Must iSCSI based Server Clusters be on the Windows Server Catalog to be supported?
A.

No, customers with iSCSI Windows Server 2003 cluster environments will be supported as a cluster configuration without submission to the Windows Hardware Quality Labs (WHQL) and being listed on the Windows Server Catalog. Support is contingent on the following provisions:

Customers must contact their vendor to ensure that the vendor has conducted internal testing to validate cluster compatibility and that they fully support the end-to-end solution with Server Clustering.

Customers must be running Windows Server 2003 Service Pack 1 or higher.

Solutions must leverage the Microsoft iSCSI Software Initiator used in conjunction with a logoed network interface card (NIC). Solutions that leverage an iSCSI HBA do not apply for the waived support policy; they must be Hardware Compatibility Test (HCT) qualified and listed on the Windows Server Catalog.

All iSCSI hardware used in the configuration must be qualified under the Designed for Windows Logo Program in their individual device categories (such as HBAs or iSCSI targets). For a complete list of qualified devices, please see the iSCSI Hardware Devices qualified in the Windows Server Catalog of tested products.

Q.Are there any changes to server clusters in Windows Server 2003 Service Pack 1?
A.

Windows Server 2003 SP1 contains a substantial number of improvements for failover handling. Clusdisk enhancements take advantage of SCSI Unique IDs, allowing better disk identification and arbitration when using a Storport miniport or the Microsoft iSCSI Software Initiator. SCSIport does not support individual LUN resets. Individual Logical Unit Number (LUN) resets are critical in multinode cluster scenarios in which disk failovers must occur nondisruptively (leaving the disks not being failed over fully functioning).

Q.Is a minimum of Service Pack 1 required for iSCSI Clusters?
A.

Yes. Service Pack 1 or higher is required for all Windows Server 2003 iSCSI cluster deployments to be supported.

Q.Is disklessWindows boot (storage area network (SAN) boot) supported with the Microsoft iSCSI Software Initiator?
A.

Remotely booting a Windows Server from an iSCSI SAN is supported with either SCSI HBA or the Microsoft iSCSI Software Initiator Boot Version.

Q.Why isn't iSCSI supported with Windows 2000 clusters?
A.

The Microsoft Windows Hardware Compatibility Test (HCT) is no longer accepting any cluster submissions for Windows 2000 to be listed on the Windows Server Catalog. For more information see the Microsoft support life-cycle policy. New cluster deployments should be built on Windows Server 2003.

Q.Is the Microsoft iSCSI Software Initiator supported?
A.

Yes, it is fully supported with no restrictions for full eight-node clusters.

Q.Are there any specific requirements for the Gigabit Ethernet switch? Will any switch we choose to use be ok?
A.

The requirements are:

Use an enterprise class switch

Ensure the switch is of non-blocking design

Recommend using full end-to-end Gigabit Ethernet

If using full GigE, use Ethernet Jumbo Frames for greater throughput and less CPU interruption

Recommend using the highest possible network Maximum Transmission Unit (MTU)

Recommend using a dedicated switch for the iSCSI SAN

Q.Is a cluster that uses Fibre Channel storage behind an iSCSI-to-Fibre Channel bridge device considered a Fibre Channel cluster or an iSCSI cluster?
A.

This cluster is considered an iSCSI cluster. Note that:

The bridge is considered to be an iSCSI bridge device, and must therefore be approved as such under the Designed for Windows Logo Program for iSCSI devices.

You must ensure that the manufacturer of the iSCSI bridge has tested and qualified with the specific Fibre Channel or SCSI redundant array of independent disks (RAID) that is being used in the customer configuration and that the array contain sufficient cache if the iSCSI bridge does not contain cache or has insufficient cache.

Mixed storage topologies are not supported within the same cluster--all nodes must use the same protocol. If the cluster configuration is iSCSI, all nodes must use iSCSI only: do not add in Fibre Channel nodes.

Q.Can you create clusters with Virtual Server products using iSCSI?
A.

With the release of Virtual Server 2005 R2, server clusters can be created with Windows Server 2003 SP1, Virtual Server 2005 SP1, and the Microsoft iSCSI 2.0 Initiator in production. See the Virtual Server Host Clustering Step-by-Step Guide for more information:

Q.Do iSCSI clusters use a stand-alone test (as is currently the case for iSCSI targets and initiators), or are they tested as part of the standard HCT test kit?
A.

There are no differences between iSCSI and Fibre Channel testing requirements. Vendors may use the latest released Cluster DTM test kit. Customers can use the Microsoft Cluster Configuration Validation Wizard tool to verify cluster functionality.

Q.Are there any iSCSI-specific requirements?
A.

Yes, the requirements are as follows:

All iSCSI components (HBAs, storage arrays) must comply with the iSCSI device logo program requirements and pass required testing using the appropriate iSCSI HCT kit for the device.

The iSCSI SAN must be on an isolated network, both for security and performance. Any networking standard practice method for achieving this end is acceptable, including:

A physically separate, dedicated storage network. In this recommended configuration, each node contains three different NICs:

a public network for external client communication

a private network for inner-node communication

an iSCSI SAN network

A physically shared network with the iSCSI SAN running on a private virtual local area network (VLAN). The switch hardware must provide Class or Service (CoS) or Qualify of Service (QoS) guarantees for the private VLAN.

If multiple clusters and/or systems are used on the same SAN, proper segregation or device isolation must be provided. In other words, the storage used by cluster A must be visible only to cluster A, and not to any other cluster, nor to a node from a different cluster.

The use of session authentication (Challenge Handshake Authentication Protocol (CHAP) minimum) is mandatory. This provides a degree of security as well as segregation.

Mutual CHAP or Internet Protocol Security (IPSec) can also be used.

Q.Do I need to do anything special when configuring an iSCSI Cluster?
A.

Take the following configuration settings into consideration when using the MS Software Initiator:

Set all clustered volumes as "Persistent Bindings" to ensure they are remapped if the node is rebooted.

Set "Bind Volumes" for all clustered disks to ensure they are fully mounted by the iSCSI service before the Cluster Service attempts to bring them online.

Ensure you are using Microsoft iSCSI Software Initator 2.0 or above.

Q.How many NICs are required for an iSCSI Cluster?
A.

A minimum of three physically different NICs are needed in each node in the cluster:

Public: A network card that is used for connectivity with external clients. For more information, read Server Clusters: Network Configuration Best Practices for Windows 2000 and Windows Server 2003.

Private: A network card that is used for internal cluster communication. This NIC must be on a physically separate network. See the Recommended private "Heartbeat" configuration on a cluster server page for more information.

SAN: A network card that is used for communication to the iSCSI target storage device. This NIC should be on a physically independent network that is not associated with any of the above. This network interface should not be enabled for cluster use.

Q.Is NIC Teaming supported on Server Clusters?
A.

No, NIC teaming is not supported on the iSCSI interface. Please see more info below:

Public: Network card that is used for connectivity with external clients. NIC Teaming is fully supported on this interface. See Network adapter teaming and server clustering for additional information.

Private: Network card that is used for internal cluster communication. NIC Teaming is NOT supported on this interface.

SAN: Network card that is used for communication to the storage device. NIC Teaming is NOT supported on this interface. Instead use Microsoft Multipath I/O (MPIO) or multiple connections per session (MCS per iSCSI specification) to achieve fault tolerance.

Q.What can you tell us about iSCSI and Cluster HCT testing duration?
A.

The test will be the same as that conducted for Fibre Channel, so test duration is expected to be the same. Note that Microsoft will only support Enterprise Qualification Program (EQP) and full cluster qualification. There is no support for the block qualification model for iSCSI.

Q.What qualification programs do you support for iSCSI?
A.

Vendors may still submit and list MS iSCSI Software Initiator based solutions on the Windows Server Catalog if they so choose, but it is not required to be a supported solution. Microsoft supports the following programs

Full cluster qualification

Enterprise Qualification Program (EQP)

Q.
A.
Top of pageTop of page