ISCSI is a great new technology in the world of storage. It is the standard which provide storage interface by carrying SCSI command over TCP/IP network. It helps organizations to consolidate storage and provide host with a illusion of locally – attached disk storage. Microsoft fully supports Microsoft SQL Server when it is deployed on ISCSI storage that has received the “Designed for Windows” Logo Program qualification. Microsoft windows server presents the ISCSI storage as ordinary drives attached to computer. To users and applications, including SQL Server, the remote destination is encapsulated.  There are certain points which needs o be remember before using ISCSI technology with Sql server 2005 or later. Some of them are as follows

• Server clustering supports iSCSI clustered shared storage on Windows Server 2003 Service Pack (SP) 1 or higher only. 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.

• Although, 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. But the 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.

• 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)

• Please note that ,Service Pack 1 or higher is required for all Windows Server 2003 iSCSI cluster deployments to be supported

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

• iSCSI is not supported with windows server 2000. 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.

• Microsoft ISCSI software initiator  is fully supported with no restrictions for full eight-node cluster

• These are the recommendations for the Gigabit Ethernet switch to be use with ISCSI

• 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

• If the cluster is using Fibre Channel storage behind an iSCSI-to-Fibre Channel bridge device then still it is considered as an iSCSI cluster. Following are the guidelines for a ISCSI  cluster

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

• There are no differences between iSCSI and Fibre Channel testing requirements. Vendors may use the latest released Cluster DTM test kit.

• the Microsoft recommended requirements for ISCI specific clusters 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 and 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.

• 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

• 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
• Private: A network card that is used for internal cluster communication. This NIC must be on a physically separate network
• 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

• 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
• 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