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.
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
Dig deeper on SAN switch
Related Q&A from Christopher Poelker
SAN expert Chris Poelker compares connecting a SAN with wavelength cabling and dark fiber and discusses the pros and cons of each.continue reading
SAN expert Chris Poelker discusses how to change the size of a LUN in a Microsoft cluster server environment.continue reading
Storage expert Chris Poelker outlines WWN basics in order to answer the question: "Why do HBAs in a SAN have same base?"continue reading
Have a question for an expert?
Please add a title for your question
Get answers from a TechTarget expert on whatever's puzzling you.