SQL Server Performance Forum – Threads Archive
SAN configuration
I am a database consultant for an imaging software vendor. Many of our customers are moving to SAN solutions to store our software’s SQL database and we’ve often received calls regarding performance issues after this migration. It seems that many of the customer’s DBA’s don’t put much thought into the I/O tuning aspect and the underlying RAID configuration performance benefits. They simply create a large RAID group with a pool of storage that can be allocated to different LUN’s. Most recently, this was case with a customer of ours. They had one large Raid 5 group (30 disks) behind one perc fibre channel controller (1 channel) connected to EMC San Storage unit. This group was broken out into 3 LUN’s. These 3 LUN’s were then seen as 3 separate physical disks through Windows. However, they decided that it would be easier to manage this storage by taking these 3 physical drives and creating a dynamic spanned volume equating to one logical (E<img src=’/community/emoticons/emotion-1.gif’ alt=’
‘ /> drive letter. I had a surprisingly hard time convincing them that this was a bad idea, but I also don’t know enough about SAN storage to provide substantial factual evidence. Perfmon showed average disk queue lengths that were significantly high for long periods of time, so this helped in proving my case.
Hi ya, A spanned volume will cause the load to hit one LUN until that LUN is full and then move onto the next LUN. Not the most efficient way to use the drives… If the drives need to be managed as one logical drive, then consider using drive mounting points to set a directory to really point at another LUN. There are a number of disadvantages with large RAID sets…
– two drives failing will imply losing the entire LUN, and having to go back to
tape.
– Windows NT limit for a single hardware RAID volume is 2TB RAID5 is very bad for write intensive operations… Although I don’t have any concrete proof, I’d suspect that large RAID5 sets will be worse for write performance than small ones, and also worse for read performance since all 30 drives need to find a given block of information… Perhaps mapping a single LUN onto a single RAID set would be more efficient too? Cheers
Twan
I am going to recommended that they map each LUN to a single RAID Set. Unfortunately, a large effort is going to be involved in temporarily moving all of their data so they can reconfigure this SAN storage. The details of this strategy are ultimately the responsibility of the customer’s IT staff. However, as the software vendor who is providing this agressive recommendation, I would like to better substantiate this configuration as the bottleneck. Do you know of any specific documentation/links/resources that I might be able to leverage?
Hi there, sorry but I don’t have any specific papers to point you at… As you have done a bit already, I’d use perfmon to get some statistics about the physical disk counters. Also any performance monitoring that you can do on the SAN itself? A SQL database likes different drives. In an ideal world I’d ahve separate physical RAID sets for:
OS/SQL binaries (internal disk)
tempdb (RAID0 or 1)
SQL logs (RAID 0)
SQL Databases (RAID10 or RAID5 if you can’t afford raid10)
backups (another network drive or RAID1) Cheers
Twan
You can try this link which is a white paper from EMC dealing with SAN and SQL Server. There are many factors to consider.
Link did not copy for some reason http://www.emc.com/pdf/techlib/h601.pdf?emccomjsessionid=208831109205457
]]>