September 28, 2010 at 12:18 pm
According to my SAN Admin, RAID 5 is perfectly fine for SQL Server, since the SAN has a huge cache. Our SAN is an EMC NS480, with 73 450GB disks, 4Gb/s and 15k RPM.
My project has a requirement for over 5 TB.
Here was my question to my SAN Admin -
"....will you be carving out LUNs for the database files (Data, Log, TempDB, backups) from the same group of disks?"
And the answer was -
Yes it will plus be shared by other systems like VM and other Windows/Linux systems. As I stated on the phone if you want to be on your on disk this should either be local attached storage or disk that everyone agrees is to be only for your project.
Comments anyone?
Thanks!
KU
September 28, 2010 at 2:22 pm
Logical disks are only useful for logical storage. It will give you no performance boost. Regarding the giant RAID 5 array, you'll want to find out if the cache will store writes while waiting on reads and allowing writes to go ahead later if the data isn't requested.
In general, that's a pretty beefy system, but dealing with others on your disks means that you can't be sure of load regarding optimization later. It may be 'good enough'. It's also a lazy assed design.
You want separate spindles, physical, for your log and data, at the very least. You want to make sure your spindles are dedicated to the SQL server. Especially for needing that much data. If possible, try to get a series of RAID 10s for your logs, and each of your largest databases having that log, and only that log, sitting on that spindleset.
RAID 5 is write heavy. If you've got high input vs. output, you're gonna find that disk write might be a slowdown. Again, depends on usage.
The only way to really argue with the SAN admin, though, is to put your system into his array and put it through its paces. Then show him, specifically, that the majority of your waits are disk-system waits, and explain that you need a physically independent spindleset, and go through it inch by inch in design.
Never stop learning, even if it hurts. Ego bruises are practically mandatory as you learn unless you've never risked enough to make a mistake.
For better assistance in answering your questions[/url] | Forum Netiquette
For index/tuning help, follow these directions.[/url] |Tally Tables[/url]
Twitter: @AnyWayDBA
September 29, 2010 at 8:02 am
Thank you!...excellent information
KU
September 30, 2010 at 3:08 am
As a starting point, I would also recommend that you share the article http://msdn.microsoft.com/en-us/library/dd758814%28SQL.100%29.aspx with your SAN administrator (and have a read of it yourself). With a title of "Disk Partition Alignment Best Practices for SQL Server", and being on the MSDN web site it *has* to apply in some fashion - plus it gives quite a few other links.
September 30, 2010 at 3:08 am
As a starting point, I would also recommend that you share the article http://msdn.microsoft.com/en-us/library/dd758814%28SQL.100%29.aspx with your SAN administrator (and have a read of it yourself). With a title of "Disk Partition Alignment Best Practices for SQL Server", and being on the MSDN web site it *has* to apply in some fashion - plus it gives quite a few other links.
September 30, 2010 at 3:09 am
As a starting point, I would also recommend that you share the article http://msdn.microsoft.com/en-us/library/dd758814%28SQL.100%29.aspx with your SAN administrator (and have a read of it yourself). With a title of "Disk Partition Alignment Best Practices for SQL Server", and being on the MSDN web site it *has* to apply in some fashion - plus it gives quite a few other links.
September 30, 2010 at 6:34 am
We recently had this discussion and, after bringing in a well-respected consultant, it was decided that having a large pool of disks assigned specifically to SQL Server, configured as RAID 10, would be best for us. We have an EMC SAN, though not as big as the one that you specified. When we originally set it up last summer, we set up dedicated disks for each of the servers attached to it. Now we're adding a new tray and will be using this single pool configuration for several servers which will have minmal load and one SharePoint installation. The consultant, and EMC, both contend that having a lrage pool of disks helps spread the load. The consultant did say to avoid sharing disks between SQL Server and other applications like VMWare or Exchange. Check back in a few months and I can tell you how it's worked out.
September 30, 2010 at 7:04 am
The argument I hear is "....unless the customer wants to pay for dedicated disk, it will be shared..." Another point my SAN Admin says is with 16GB of cache, performance will be fine.
KU
September 30, 2010 at 8:01 am
Without dedicated disk you'll have to send him all the performance problem related to disk IO.
Dedicated disk = predictable stable performance, shared disk = You won't be able to tell your clients why their application sometime times out and sometime works fine.
It's better to have less spindles on dedicated disk than more on shared disk.
The money you save on shared disk (if you even save anything) will be lost many time on support.
October 1, 2010 at 12:59 pm
Shared disk may be cheaper, and is absolutely simpler on the SAN side.
Shared disk with non-SQL apps, however, means that you cannot guarantee SLA's on query performance; if some other app hammers the disk for a time, SQL's going to slow down too.
Shared disk is, simplistically, trading better average utilization and much better maximum performance for much worse minimum performance and unpredictable performance.
Viewing 10 posts - 1 through 9 (of 9 total)
You must be logged in to reply to this topic. Login to reply