| Author |
Topic |
|
cabledguy2006
Starting Member
9 Posts |
 Posted - 2009-03-29 : 00:29:03
|
| Hi AllOur DBAs group is very nix/oracle focussed. So having setup a couple of small MS SQL clusters before, I've been tasked with building one on blades that will allow us to run apps out of my group (ASAP) and probably consolidate a number of small scale SQL backed departmental applications down the track.Since the scoping is so vague I'm trying to design for max performance and scale out by adding more blades/nodes down the track. It will be win 2003 ent 64 bit with SQL 2005 Ent 64bit since unfortunately the blades aren't supported for win 2008.I'm doing it on 8 core blades with 32 GB of RAM and plenty of NICs so disk I/O is likely to be my only bottleneck. So I'm hoping for a bit of advice from people who run mult-node SQL clusters.My storage guy is saying since they are 15k disks on the array make as few drive letters/LUNs as I can get away with to do the cluster.RAID level not relevant as this array will only do RAID 5.But having done a bit of study everyone says keep logs, databases and indexes on separate disks if possible.And that if you have more than two databases on a LUN with autogrow you're in for a lot of fragmentation.So do I lump it all in together - hope the hardware will cover it and concentrate on detecting/remdiating fragmentation or do I split it up and accept I'll lose a few disks by having a number of small RAID 5s. |
|
|
tkizer
Almighty SQL Goddess
38200 Posts |
Posted - 2009-03-29 : 12:56:20
|
| We use mount points to solve this issue. We have a 4-node cluster that is active/active/active/active and has 11 SQL instances on it. If we separated data, logs, indexes, tempdb, etc..., we wouldn't have enough letters in the alphabet. Mount points solve this issue. SQL Server 2005 is the first version of SQL Server that supports it. Here is what our mount points look like:F:F:\BackupF:\DataF:\LogThese are four mount points. We put the system databases, including tempdb, on the system mount point which is the root F. All backups go in Backup mount point, the MDFs go in Data mount point, and the LDFs go in Log mount point.We are using Veritas for this.Tara KizerMicrosoft MVP for Windows Server System - SQL Serverhttp://weblogs.sqlteam.com/tarad/Subscribe to my blog"Let's begin with the premise that everything you've done up until this point is wrong." |
 |
|
|
cabledguy2006
Starting Member
9 Posts |
Posted - 2009-03-30 : 03:36:49
|
| Thanks TaraI think I'd got a bit confused. Since each cluster resource will need a disk resource of course you'll need a lot of drive letters.But what size do you make your LUNs. I'm going to end up with a wide mixture of DBs and I trying to figure out if I should have tiers of luns e.g.50 GB small DBs100 GB medium DBs300 GB large DBsOr is there some other way of sensibly dividing up the storage? |
|
|
|
tkizer
Almighty SQL Goddess
38200 Posts |
Posted - 2009-03-30 : 10:41:45
|
| Well you definitely need one drive letter per cluster resource that has SQL Server. But you don't need anymore than one if you use mount points.The size luns you'd use would depend on what is needed. I would start off small and then add space as needed. I wouldn't have tiers of LUNs. Add the space according to what you have now for databases and what you have in the very near future. Then add as needed.Tara KizerMicrosoft MVP for Windows Server System - SQL Serverhttp://weblogs.sqlteam.com/tarad/Subscribe to my blog"Let's begin with the premise that everything you've done up until this point is wrong." |
|
|
|
cabledguy2006
Starting Member
9 Posts |
Posted - 2009-05-09 : 07:34:49
|
| So given that this is a consolidated SQL environment i.e. a bucket and I have no idea what DBs they'll migrate, what size LUNs do people use for their database and log luns?I'm also a bit confused on the virtual server layout. I presume each resource group has a DNS entry e.g. hs-sql-v1 which is what will failover.So in cluster admin it would look like---hs-sql-v1 |_ _ _Instance1 (with its own disk resources) |_ _ _Instance2 (with its own disk resources)Is this correct?Now some apps its recommended to give their own instance e.g. System Center Ops Manager because you don't want some other app pulling your monitoring down. And some apps have tight SLAs so you might give them their own instance/res group. Whereas small apps might share an instance.I'm wondering what rules people use to organise their cluster resource groups and instances? |
|
|
|
cabledguy2006
Starting Member
9 Posts |
Posted - 2009-05-09 : 07:49:24
|
| Pls ignore the Q about virtual server layout. Tara's already answered that here: http://www.sqlteam.com/forums/topic.asp?TOPIC_ID=91053&SearchTerms=cluster,lun "...Each SQL instance gets its own virtual server. You'll need to set that up inside Cluster Administrator and also have your network admins provide an IP address for it." So what this suggests to me is it's best to have plenty of instances and small LUNs to put each instance on. Say 150 GB for DBs and 30 GB for logs? |
|
|
|
tkizer
Almighty SQL Goddess
38200 Posts |
|
|
cabledguy2006
Starting Member
9 Posts |
Posted - 2009-05-11 : 06:53:46
|
| yes it is a bit problematic - perhaps I'm over thinking it. But how do people organise their consolidated servers? I mean I know SCOM as an app. MS say 50 GB max for the OpsMgr database and 150 GB max for the data warehouse DB. So do I simply provision a 200 GB lun and then treat each app case by case? |
|
|
|
|
What size to make LUNs