Windows Server Guides

Test

Description

List All Disks

Lists all disks that are visible to one or more tested servers. The test lists:

• Disks that can support clustering and can be accessed by all the servers.

• Disks on an individual server.

List Potential Cluster Disks

Lists disks that can support clustering, and are visible to all tested servers. To support clustering, the disk must be connected through Serial Attached SCSI (SAS), iSCSI, or Fibre Channel. In addition, the test validates that multipath I/O is working correctly, which means that each of the disks is seen as one disk, not two.

Validate Disk Access Latency

Validates that the latency for disk read/write operations is within an acceptable limit for a failover cluster. If disk read/write operations take too long, one possible result is that cluster time-outs might be triggered. Another possible result is that the application attempting to access the disk might appear to have failed, and the cluster might initiate a needless failover.

Validate Disk Arbitration

Validates that:

• Each of the clustered servers can use the arbitration process to become the owner of each of the cluster disks.

• When a particular server owns a disk, if one or more other servers arbitrate for that disk, the original owner retains ownership.

Test

Description

Validate Disk Failover

Validates that disk failover works correctly in the cluster. Specifically, the test validates that when a disk owned by a clustered server is failed over, the server that takes ownership of the disk can read it. The test also validates that information written to the disk before the failover, is still the same after the failover.

If disk failover occurs but the server that takes ownership of a disk cannot read it, the cluster cannot maintain availability of the disk. If information written to the disk is changed during the process of failover, it might cause issues for users or software that require this information. In either case, if the affected disk is a witness disk, (a disk that stores cluster configuration data and participates in quorum,) such issues could cause the cluster to lose quorum and shut down.

Validate File System

Validates that the file system on disks in shared storage is supported by failover clusters.

Validate Microsoft MPIO-Based Disks

Validates that multi-path disks (Microsoft Multipath I/O-based disks,) have been configured correctly for failover cluster.

Validate Multiple Arbitration

Validates that when multiple clustered servers arbitrate for a cluster disk, only one server obtains ownership.

If multiple clustered servers obtain ownership of a cluster disk through disk arbitration, the disk might become corrupted. Failover clusters are designed to operate in circumstances where only one clustered server at a time owns a disk. If multiple servers own a disk at the same time, they might perform write operations in an uncoordinated way, possibly corrupting the disk.

Validate SCSI Device Vital Product Data (VPD)

Validates that the storage supports necessary SCSI inquiry data as well as Vital Product Data (VPD) descriptors, and that they are unique.

Test

Description

Validate SCSI-3 Persistent Reservation

Validates that the cluster storage uses the more recent (SCSI-3 standard) Persistent Reserve commands, which are different from the older SCSI-2 standard reserve/release commands. Because the Persistent Reserve commands avoid SCSI bus resets, they are much less disruptive than the older reserve/release commands. Therefore, a failover cluster can be more responsive in a variety of situations, unlike a cluster running an earlier version of the operating system. In addition, disks are never left in an unprotected state, which lowers the risk of volume corruption.

Validate

Simultaneous Failover

Validates that simultaneous disk failovers work correctly in the cluster. Specifically, the test validates that even when multiple disk failovers occur simultaneously, any clustered server that takes ownership of a disk can read it. The test also validates that information written to each disk before a failover is the same after the failover.

If disk failover occurs but the server that takes ownership of a disk cannot read it, the cluster cannot maintain availability of the disk. If information that is written to the disk is changed during the process of failover, it might cause issues for users or software that requires this information. In either case, if the affected disk is a witness disk, (a disk that stores cluster configuration data and participates in quorum,) such issues might cause the cluster to lose quorum and shut down.