FC reservation and clusters

[JPS-LTU]

Hi there,

I was wondering if somebody could explain what FC reservation is? If i look at the properties of a vdisk and select presentation. I see a FC Reservation State.

If i have a vdisk presented to 2 hosts (in an MS cluster) and the FC reservation is set to Regular. Does this mean that when the cluster fails over, the other node is allowed to see the vdisk?. How does the reservation state get set?

Basic reason im asking is that we have a 2-node ms (exchange) cluster with 4 vdisks - presented to each node. We are using MPIO Basic as the multipathing solution. If we fail over one of the nodes 1 of the disks doesnt appear on the newly active node. the remaining 3 appear as expected. All vdisks are presented to the hosts the same (ie: each vdisks have the same LUN on each host). All FC reservations are set to regular. It appears to be more of an MS issue, but id like to discount the EVA as a culprit.

the cluster nodes and the storage array are in their own zone.

cheer, and thanks for any advice!
Jason

[Ruslan]

Hi Jason!

I check status of disk presented on EVA5k to Win cluster in our lab and all Vdisk have FC reservation NONE. I think it is configureable parameter of Vdisk via "Preferred path/mode". Note that If you are running an operating system that requires Secure Path software (HP-UX, IBM AIX, Linux, Novell NetWare, Sun Solaris, or Microsoft Windows) and want to designate a preferred path, use the Failover
only settings. The Failover/failback settings are not supported with Secure Path. The Failover only settings allow the host to control when a virtual disk moves to a preferred path. If you are running an operating system that does not require Secure Path software (OpenVMS or Tru64
UNIX), all preferred path settings are supported.

[Ivan Ferreira]

I think that the FC reservation is NOT a configurable parameter.

In our environment, the VDISKS are in FC reservation state PERSISTENT.

The FC reservation are used to avoid simultaneous access to the same VDISK by different systems. Acts like an I/O barrier.

Verify/recheck your zoning configuration, maybe the VDISK that cannot be accessed is peferred for the other controller, and you cannot access to that controller from your server.

Are disks basic/dynamic? MS recomendation is to have basic disk on the SAN and dynamic disks on the local bus, or vice versa. But NOT to have dynamic disks at the SAN and internally.

[Uwe Zessin]

Right, the FC reservation in CV-EVA is a *status information*. Persistent reservation is used by Tru64 Unix Trucluster servers.

[Florian Heigl (new acc)]

I very much doubt MS Cluster's can handle FC/SCSI reservation :))

[Uwe Zessin]

Your doubt is not warranted, I am afraid.

-----
http://www.microsoft.com/technet/prodtechnol/windows2000serv/deploy/confeat/clustsrv.mspx

...""The quorum resource is a physical disk in the common cluster disk array and has the following attributes:

* Supports low-level commands for persistent ownership arbitration enabling a single node to gain and defend physical control of the quorum resource. For example, the SCSI disk Reserve and Release commands enable persistent arbitration."...
-----

SCSI reservation is a basic part of MSCS. MSCS also uses SCSI reservations on the quorum disk as a last-resort challenge/respond protocol to find out if the other node is still active when all LAN paths have failed.

Has always been that way, even 8 years or so ago when shared parallel SCSI busses were used. Well, I don't remember the year MSCS was introduced, but it's predecessor named "Digital Clusters for Windows NT" already used this mechanism in 1996.

I've spent half a saturday to debug a problem that prevented a proper failover when one node was simply turned off. Turned out that SCSI bus resets did not work any longer and nobody from the customer had found it out, because they always did a manual failover.

[JPS-LTU]

Hi guys,

thanks for all the responses...

in answer to you Ivan, VDisk in question *should* be able to access the other controller, as it is configured exactly the same as all other vdisks presented to the cluster.

All disks in EVA presented to cluster are Basic disks.

Maybe i should clarify 'failover'. At the moment we are testing failover from the OS itself (not from the EVA point of view). IE: we are failing over the node manually from the OS. Not having worked with clusters before, im not sure of the terminology - so sorry for any confusion.

Im pretty sure its something not configured properly on the nodes themselves, but am struggling trying to find any info on configuring cluster storage for the EVA.

Im waiting to find out from Windows admin whether he used the Platform kit to install, or just installed the drivers for the HBA (Qlogic)

thanks again for replies
jason