Storage Area Networks (SAN) questions

Applies To: Windows Server 2003, Windows Server 2003 R2, Windows Server 2003 with SP1, Windows Server 2003 with SP2

Q. What is a Storage Area Network (SAN)?

A. A storage area network (SAN) is defined as a set of interconnected devices (e.g. disks and tapes) and servers that are connected to a common communication and data transfer infrastructure such as a fibre channel. The common communication and data transfer mechanism for a given deployment is commonly known as the storage fabric. The purpose of the SAN is to allow multiple servers access to a pool of storage in which any server can potentially access any storage unit. Clearly in this environment, management plays a large role providing security guarantees (who is authorized to access which devices) and sequencing or serialization guarantees (who can access which devices at what point in time).

Q. Why use a SAN?

A. Storage area networks provide a broad range of advantages over locally connected devices. They allow compute units to be detached from storage units, thereby allowing flexible deployment and re-purposing of both servers and storage dynamically to suit the current business needs without having to be concerned about buying the right devices for a given server or without re-cabling a datacenter to attach storage to a given server.

Q. Can a cluster be connected to a SAN?

A. Yes, Microsoft fully supports storage area networks both as part of the base Windows platform and as part of a complete Windows Clustering high availability solution.

Q. Can a cluster co-exist on a SAN with other servers?

A. One or more Server clusters can be deployed in a single SAN environment along with standalone Windows servers and/or with other non-Windows platforms.

Q. What additional SAN configuration is required to put a cluster on a shared SAN?

A.

• The cluster disks for each cluster on a SAN MUST be deployed in their own zone. All host bus adapters (HBAs) in a single cluster must be the same type and at the same firmware revision level. Many storage and switch vendors require that ALL HBAs on the same zone, and in some cases the same fabric, are the same type and have the same firmware revision number.

• All storage device drivers and HBA device drivers in a cluster must be at the same software version.

• When adding a new server to a SAN, ensure that the HBA is appropriate for the topology. In some configurations, adding an arbitrated loop HBA to a switched fibre fabric can result in widespread failures of the storage fabric. There have been real-world examples of this causing serious downtime.

Q. What is LUN masking or selective presentation?

A. LUN masking (also implemented as selective presentations) allows users to express at the controller level a specific relationship between a LUN and a host. Only the hosts that are configured to access the LUN should be able to see it.

Q. What is hardware zoning verses software zoning?

A. Zoning can be implemented in hardware/firmware on controllers or on software on the hosts. Microsoft recommends that controller based (or hardware) zoning be used since this allows for uniform implementation of access policy that cannot be interrupted or compromised by node disruption or failure of the software component.

Q. Why is zoning needed to isolate a Server cluster in a SAN?

A. The cluster uses mechanisms to protect access to the disks that can have an adverse effect on other clusters that are in the same zone. By using zoning to separate the cluster traffic from other cluster or non-cluster traffic, there is no chance of interference.

The diagram shows two clusters sharing a single storage controller. Each cluster is in its own zone. The LUNs presented by the storage controller must be allocated to individual clusters using fine-grained security provided by the storage controller itself. LUNs must be setup so that every LUN for a specific cluster is visible and accessible from all nodes of the cluster. A LUN should only be visible to one cluster at a time. The cluster software itself takes care of ensuring that although LUNs are visible to all cluster nodes, only one node in the cluster accesses and mounts the disk at any point in time.

The multi-cluster device test used to qualify storage configurations for the multi-cluster HCL list tests the isolation guarantees when multiple clusters are connected to a single storage controller in this way.

Q. Can a cluster server boot from a SAN?

A. Yes, however, there is a set of configuration restrictions around how Windows boots from a storage area network. For more information, see article 305547 in the Microsoft Knowledge Base (https://go.microsoft.com/fwlink/?linkid=67837).

Server clusters require that the startup disk, page file disk and system disk be on a different storage bus to the cluster server disks. To boot from a SAN, you must have a separate HBA for the boot, system and pagefile disks than the cluster disks. You MUST ensure that the cluster disks are isolated from the boot, system and pagefile disks by zoning the cluster disks into their own zone.

Q. Can I use multiple paths to SAN storage for high availability?

A. Microsoft does not provide a generic driver that allows multiple paths to the storage infrastructure for high availability; however, several vendors have built their own proprietary drivers that allow multiple HBAs and SAN fabrics to be used as a highly available storage infrastructure. For a Server cluster that has multi-path drivers to be considered supported, the multipath driver MUST appear as part of the complete cluster solution on the Cluster Hardware Compatibility List (HCL). NOTE: The driver version is VERY important and it MUST match the qualified version on the HCL.

Q. Can the startup disk, pagefile disks and the cluster disks be on the same SAN fabric?

A. No, in Windows Server 2003, there is a registry key that allows the startup disk, pagefile disks, and cluster disks to be on the same bus. This feature is enabled by a registry key, which helps ensure that it is not accidentally enabled by customers who do not understand the implications of this configuration. It is intended for OEMs to ship qualified and tested configurations and not for a typical end-user or administrator to set up in an ad hoc manner.

In the original release of Windows Server 2003, the registry key is:

HKLM\SYSTEM\CurrentControlSet\Services\ClusSvc\Parameters\ManageDisksOnSystemBuses 0x01

In Windows Server 2003 with Service Pack 1 (SP1), the registry key is:

HKLM\SYSTEM\CurrentControlSet\Services\ClusDisk\Parameters\ManageDisksOnSystemBuses 0x01

In Windows Server 2003 SP1, the key path was changed to use “Clusdisk” as a subkey instead of “ClusSvc.” This change was made to avoid issues during setup. However, the change is backward compatible, and systems that use the old key locations do not need to be modified.

Q. Can serverless backup be performed against cluster disks?

A. No, the cluster disk arbitration mechanism uses SCSI reserve and release operations. Once a server arbitrates for a cluster disk, that disk cannot be accessed by any other server on the storage network.