November 20, 2011 at 9:03 am
Hi guys, I'm hoping one of you can help me with some advice regarding a win 2008 enterprise SQL cluster I'm going to build.
I've got 2 dell poweredge 610's (with perc h800a cards installed on each) and a powervault md3200 to build this with. Connections to the md3200 will be mini Sas from the h800 cards on each server to the in port of each of the md3200's controllers.
I am a bit confused on best practice for splitting up the md3200's disks. Say I have 12 x 300gb Sas drives in the md3200, what should I be doing with regards quorum, msdtc, SQL data, and logs?
-quorum drive. Best practice 500-1gb size? If so, and to keep this on it's own spindle, as a raid1 (for example) this wastes a huge amount of disk space.
-msdtc. Is this absouktely essential in a cluster configuration? Again I've heard that it's best to keep this on it's own spindle too. Size of around 2gb?!? Then again-if used as a raid1, wastes a huge amount of remaining space on the drives.
-SQL data. Use raid 10 across 4 drives?
-SQL logs. Use raid 10 across 4 drives?
This uses all 12, and keeps each component on it's own spindle (best practice?)
I'd like to hear what you guys think is best practice to splitting up the Sas storage disk in regards to this SQL /win 2008 active/passive cluster. Particularly with the waste of space in splitting the quorum (500mb-1gb size, of a raid 1 300gb disk) and same for the msdtc.
What would you do? I'm not familiar with clustering using directly attached Sas storage, and how to split it. This avoids any disk partitioning which I hear is not great practice.
November 20, 2011 at 3:09 pm
MSDTC and quorum are metadata drives, they should both be around 1 GB in size. Carve them out of the shared storage, they have no performance requirement.
Depending on the number of nodes you could opt for file share majority incorporating a witness server and do away with the quorum drive.
-----------------------------------------------------------------------------------------------------------
"Ya can't make an omelette without breaking just a few eggs" 😉
November 21, 2011 at 3:05 pm
Perry, many thanks for your input.
It's going to be a 2 node cluster, active/passive. So the quorum has no performance impact on the drives? I read some other posts in forums saying that its not best practice to have them on the same drive.
You think it would be okay to have the first raid 1 drive set with 3 partitions- quorum, msdtc and the remainder of the storage as data storage space? With this, I could then split up the rest of the disks for SQL data and logs.
Partitioning drives that the quorum is on does not cause any issues in clustering?
Much obliged!
November 21, 2011 at 4:31 pm
corbett (11/21/2011)
Perry, many thanks for your input.It's going to be a 2 node cluster, active/passive. So the quorum has no performance impact on the drives? I read some other posts in forums saying that its not best practice to have them on the same drive.
You think it would be okay to have the first raid 1 drive set with 3 partitions- quorum, msdtc and the remainder of the storage as data storage space? With this, I could then split up the rest of the disks for SQL data and logs.
Partitioning drives that the quorum is on does not cause any issues in clustering?
It is no longer required that you cluster the DTC so you may not even need to deal with this. And even if you do then it doesn't need to be al lthat big unless you are doing an OBSCENE amount of Distributed Transactions, which if you are I think a refactor needs to be considered..
As far as quorum, I generally set aside 1GB, with a 2 node cluster it is recommended you use the quorum config "Node and Disk Majority" Which can keep the cluster active with the loss of 1 node. I would not put a lot of thought into its location, the disk access associated with the quorum is really very small and on a 2 node cluster I have is almost non-existent.
In the case of an Active/Passive cluster I would probably use the most spindles I could for data, log and tempdb. I would probably leave 1 disk out as a hot spare, but thats me.. Do you have any stats on how your app currently accesses data/log/tempdb? This may give you insight as to how to slice it up.
CEWII
November 21, 2011 at 11:12 pm
Ok, with the 2 node cluster you would generally look at the disk and node majority. However, if you wish to remove the dependency on the wuorum disk, as I pointed out you may also use a node file share with witness majority. More can be found on quorum at this link
I would still provide a clustered DTC resource for my clustered SQL group. The improvements in Windows 2008 DTC do make it possible to have multiple instances of MSDTC.exe running (including local). This is designed to provide local DTC for applications that do not require the failover capability. More can be found on DTC at this link
-----------------------------------------------------------------------------------------------------------
"Ya can't make an omelette without breaking just a few eggs" 😉
November 22, 2011 at 8:58 am
I generally agree. I have not had cases where I felt clustering the DTC was advantageous, YMMV. As far as Quorum this is a little less clear, you can use "Node and File Share Majority" and this is very similar to "Node and Disk Majority". In both cases you can lose either 1 node OR the Quorumy drive/share and the cluster will continue to run. Since my quorum is on the same SAN as the drives that contain my data I really don't worry about it and I didn't want to involve yet another machine for the share. If my quorum becomes unavailable the whole SAN is just as likely unavailable too and it doesn't matter if the cluster is running because my SQL won't be.
We are certainly free to disagree and that is alright.
CEWII
November 22, 2011 at 1:38 pm
Perry & Elliot many thanks for taking the time to answer my question.
I think I'm going to take the advice and go for a Node & Disk Majority, the default instance.
The only real resources that have to be configure for the application that will be running on the cluster is Microsoft Message Queues and Generic Service Resources for the application and its dependancies. I don't think MSDTC is really required, at least not in the installation procedure I have been told.
Are there any things to watch out for in the actual SQL 2008 itself install? THe SQL public IP? Or what the SQL service runs under in the Domain- ie Mixed Mode or Domain account? I feel that last bit may provide potential hickups.
Thank you guys.
November 22, 2011 at 4:01 pm
I've seen some issues if you are not a domain admin getting the SQL Virtual name to come online correctly. But I use a domain account (required) with only user rights on the local machines, I grant full access to the domain account on the (shared) database drives.
CEWII
November 22, 2011 at 11:12 pm
Sure, node and disk majority are the default and the easiest to implement, go with what you're comfortable on.
Since your OP raised concerns around the quorum disk and it's sizing that's why I suggested the more robust node and file share majority as it negates the need and indeed removes the storage as a single point of failure, although it is genrally a more advanced\special configuration.
It is fairly straight forward to swap quorum configs post install and could always be implemented at a later date if you felt the need.
-----------------------------------------------------------------------------------------------------------
"Ya can't make an omelette without breaking just a few eggs" 😉
November 22, 2011 at 11:18 pm
Elliott Whitlow (11/22/2011)
If my quorum becomes unavailable the whole SAN is just as likely unavailable too and it doesn't matter if the cluster is running because my SQL won't be.
IMHO not true and unwise to assume. In my experience I have seen many cases where LUNs are accidentally removed, taken offline either manually or automatically. It's storage and literally anything can happen to the LUN level without affecting the whole SAN.
I prefer to remove this single point of failure whenever possible.
-----------------------------------------------------------------------------------------------------------
"Ya can't make an omelette without breaking just a few eggs" 😉
November 23, 2011 at 8:39 am
Perry Whittle (11/22/2011)
Elliott Whitlow (11/22/2011)
If my quorum becomes unavailable the whole SAN is just as likely unavailable too and it doesn't matter if the cluster is running because my SQL won't be.IMHO not true and unwise to assume. In my experience I have seen many cases where LUNs are accidentally removed, taken offline either manually or automatically. It's storage and literally anything can happen to the LUN level without affecting the whole SAN.
I prefer to remove this single point of failure whenever possible.
Unless you are using separate disk for your data as well and replicating the underlying blocks disk will ALWAYS be a single point of failure. The quorum mode you are referencing is designed for this condition. But hardly anybody actually does it this way. Yes you can use it to break your quorum off but a quorum failure doesn't translate into a cluster failure anymore. Onto your next point, given the OPs arrangement all his storage is dedicated to this machine, involving yet another machine for Quorum doesn't make sense to me.
In large organizations I would conceed it is more likely that the SAN guys would remove the quorum LUN, however, in the SAN interfaces I've seen it slows them down when that SAN LUN is in use. However I would go a step further and say than this is a possibility for any LUN.
As a point, all clustering services is looking for is a majority, whether it be 1 machine and 1 quorum or 2 machines and no quorum. Quorum just isn't what it used to be.
And I guess on this topic we have at least a partially different view and thats ok, on those differences we'll just have to agree to disagree.
CEWII
Viewing 11 posts - 1 through 11 (of 11 total)
You must be logged in to reply to this topic. Login to reply