Q

LUNs and SANs

Is there a reason why an MSCS Cluster Quorum Disk should be on a separate LUN in a SAN? Or, is it acceptable to split a LUN and allow the quorum drive to be assigned to a small visible LUN allowing for a large visible LUN to share the physical SAN LUN?

I am planning to create a 108GB RAID 5 container, then to split the container into two visible drives. A 1GB drive for the quorum drive and the remaining 107GB to a data dump drive. Does this seem right? I am getting different opinions on this.


In practice, it is ALWAYS advisable to use a "separate PHYSICAL device" for the quorum disk. I have seen all kinds of fail over problems if this is not set up properly. I have seen instances when sharing a disk for both resource and quorum, where failing over the cluster resource also fails over the application resource. This is due to only one server being allowed access to each disk in the cluster. (Only one node can "own" any resource at a time.)

The quorum disk provides the sanity check to inhibit a "split-brain" cluster. If cluster communication fails over both the public and private network, the only way to determine who should be the "primary node," is to try a SCSI lock command to the quorum disk. The node that gets the "lock" is the winner, and that node becomes the resource "owner". If the quorum disk is located on a resource drive, and that drive is not virtualized, then both the application resource AND the quorum disk will be moved. This is not good if the resource is exchange and it's the middle of the day!

Certain intelligent storage arrays allow interception of the SCSI lock command through virtualization of partitions. If this is the case, then you can get away with slicing up a single mirror set into partitions, and use those partitions as quorum disks for the clusters in the SAN. Never share a quorum disk as a partition on a resource disk. Keep them separate, especially if there is more than a single resource in your cluster. Also, always use raid on your quorum drive! The quorum drive is the single point of failure in a cluster. Lose that, and you lose your cluster. (Although there are workarounds to rebuild it.)

There is a real good whitepaper on MSCS clusters from Compaq called: "MICROSOFT CLUSTERING: Principles of Operation, Applications and Management"

Digital Equipment along with Tandem sort of invented clusters and that's a good source for tech documentation. (Both companies were bought by Compaq.) Microsoft's Technet is also a definitive source for all things on MSCS. You can access Microsoft's whitepaper at: http://www.microsoft.com/ntserver/ProductInfo/Enterprise/clustering/ClustArchit.asp. There is a link on that page to Technet resources.

Chris

Editor's note: Do you agree with this expert's response? If you have more to share, post it in our Storage Networking discussion forum at --> --> .8DmraOhxbkd^1@.ee83ce4!viewtype=convDate>http://searchstorage.discussions.techtarget.com/WebX?replyToMessage@156.8DmraOhxbkd^1@.ee83ce4!viewtype=convDate


This was first published in November 2001

Dig deeper on SAN switch

Pro+

Features

Enjoy the benefits of Pro+ membership, learn more and join.

Have a question for an expert?

Please add a title for your question

Get answers from a TechTarget expert on whatever's puzzling you.

You will be able to add details on the next page.

0 comments

Oldest 

Forgot Password?

No problem! Submit your e-mail address below. We'll send you an email containing your password.

Your password has been sent to:

-ADS BY GOOGLE

SearchSolidStateStorage

SearchVirtualStorage

SearchCloudStorage

SearchDisasterRecovery

SearchDataBackup

Close