Please start any new threads on our new site at https://forums.sqlteam.com. We've got lots of great SQL Server experts to answer whatever question you can come up with.

 All Forums
 SQL Server 2005 Forums
 High Availability (2005)
 system db and data all on one LUN

Author  Topic 

cabledguy2006
Starting Member

9 Posts

Posted - 2009-03-01 : 04:14:31
Hi All

I've been tasked with creating an SQL cluster which a number of systems will use for database services. What they've given me to work with is a bit different to how I'd lay it out.

What I've been given is two TB LUNs on a mid-level FC SAN all raid5. The raid5 isn't negotiable so I'll have to live with that.

So the SQL binaries will go on local disk and the system databases and a number of databases in named instances will be all sharing one big LUN/(drive in windows).

One issue I can think of is that I could have run out of I/O long before the two terabytes are used up so wasting a lot of storage because at that point I'd need another 2 TB LUN.

Am I likely to run into implementation or performance issues with this setup?

GilaMonster
Master Smack Fu Yak Hacker

4507 Posts

Posted - 2009-03-01 : 07:47:56
You're likely to run into performance issues. Firstly RAID 5 is very bad for log files. Second, all the IO for all the databases (including tempDB) will be going through the same IO channels and using the same spindles.

If the DBs aren't going to be heavily utilised, you'll get away with it. If they are, you're looking at IO bottlenecks in the future.
Ask the storage guys if the drives are dedicated to this LUN or if they're shared with others.

--
Gail Shaw
SQL Server MVP
Go to Top of Page

cabledguy2006
Starting Member

9 Posts

Posted - 2009-05-09 : 08:16:21
Thanks Gail
In terms of being shared, this SAN only has SQL storage at the moment. Its part of our new database tier of storage.

I've got the databases and logs on separate raid grops now. RAID5 is all it will do unfortunately.

I read somewhere that timed filecopies were a reasonably accurate measure of SQL disk perormance.

So I ran 10 simultaneous timed copies of a 20GB file (to saturate the 8GB SAN cache) - between LUNs (so as to get contention) and got about 165 megabytes a second.

Which I think is pretty poor for a moder array. The HBAs are 4Gbps and the blades are dual quad cores so I think I/O will be the bottleneck.

Can anyone point me to any info on how to calculate how many databases this is likely to support or at least simple further tests to run?
Go to Top of Page

GilaMonster
Master Smack Fu Yak Hacker

4507 Posts

Posted - 2009-05-09 : 16:18:49
If you want to test an IO system for SQL Server, file copies are not the way to do it. Use SQLIOSim. It simulates the kind of IOs that SQL Server issues.

Why only RAID 5? It's a pretty poor SAN if it can't do RAID 10. Or is it that the SAN admin refuses?

--
Gail Shaw
SQL Server MVP
Go to Top of Page

cabledguy2006
Starting Member

9 Posts

Posted - 2009-05-09 : 19:34:13
Thanks Gail I knew about sqlio,iometer etc. this was just to get a quick and dirty estimate to see if I was going to run into trouble.

I will go to SUN support about the raid 10. It's a Storagetek 6540. My other problem is that their best practice recommends a max of 8 disks per RAID group. And worse 6 LUNs per raid group so I'm wondering if this array is really suitable for a multiple instance setup?
Go to Top of Page

GilaMonster
Master Smack Fu Yak Hacker

4507 Posts

Posted - 2009-05-10 : 05:48:23
Use SQLIOSim. It doesn't take all that long, and it's better to have an estimate that's related to what you're estimating than one that may be miles off.

I don't know SAN types, so I can't say anything about whether this is suitable.

--
Gail Shaw
SQL Server MVP
Go to Top of Page

cabledguy2006
Starting Member

9 Posts

Posted - 2009-05-11 : 07:22:53
I've just discovered that the 'storage guy' is wrong - never assume the other guy's doing his job :-( This array does do raid 10. So I think the answer is to re-carve - provision the LUNs app by app and I'll try again with SQLIOsim.
Go to Top of Page

TRACEYSQL
Aged Yak Warrior

594 Posts

Posted - 2009-05-17 : 19:51:33
I go back to management with the recommendations for running the data disks on a SAN and give them your facts.

Run the tools as mentioned above to get the number of IOPS the disk can handle. If im not mistaken it is not the number of LUN it is the number of spindles on the LUN and each on of them is capable of 85 iops.

The recommendation defaults for clustering is quorum and mstdc sit o their own disk and not be on the same as your data. The data should be on its own separate disks and the logs and also the tempdb...i am already at 5 separate disks.

Now comes the SQL machine this has to be formatted to use 64 blocks and not the normal default of 4k blocks ...

If the IOPS is not configured correctly then the SQL will not run as fast as you like regardless if you put heaps of memory and cpu...The bottom line is the speed of the IOPS and the network. Are you going to be sharing your SAN disk space with every tom dick and harry request also and having to wait for the entire traffic also. This is not such a good idea either.

I wouldn't just accept the LUNS of Two TB...although this is hugh amount of space i would research the spindles....even ask them why only two luns when there is 14 on a SAN if not more.

Please do not just accept RAID 5 - You need to present this to your managers why it is bad. It really isn't that much to change it to a different raid just raid 10 takes more space because of the stripping.

Just my pennies worth.

Go to Top of Page
   

- Advertisement -