February 27, 2008 at 10:13 am
I'm still trying to understand the differences in performance between fiber channel (FC) SAN drives and SCSI. I've been told that SAN performance is much better then SCSI and SAS and that we should consider dividing drives into LUNs to better utilize disk space. We have an EMC SAN and our smallest drives are 73GB. In allocating disk space for tempdb a RAID 10 made up of (4) 73GB drives is too much space for our needs. One of our SAN people (note the Star Wars reference) suggests dividing the (4) 73GB RAID 10 into multiple LUNs, allocating 36GB to tempdb and the remaining 110GB to SQL Server logs. Should I be concerned with this approach or is SAN performance with LUNs much better then SCSI and SAS?
Thanks, Dave
February 27, 2008 at 12:51 pm
we are migrating to a new DMX next week
EMC told us that when you put devices on LUN's mix and match with high I/O apps to low I/O apps for the same drives
February 27, 2008 at 1:20 pm
welcome to the world of vendor bull ****. Shared luns are the biggest causes of performance issues on a san for sql server. Just think about what you're actually doing here - this is the same as dividing the hard drive on your PC into 6 drives and expecting to get better performance!
It is also largely a myth about SAN performance too - the raw disks still perform the same regardless of where they are, bandwidth may be slightly better on fibre channel but sql server is io intensive not bandwidth intensive and you'll likely struggle to swamp a 4 gb fibre. Now I'm not going to bad mouth any SAN vendor, as it doesn't really achive anything, but we had some posts about vendor missconfigured luns not so long ago, and I've just had a san migration for my prod cluster and the vendor consultant had not alligned the luns ( see diskpart from microsoft ) or considered the buffer / queue depth on the HBAs - I dread to think about how the switches are configured!
They'll probably also tell you about how wonderful the cache is and how that negates lun performance - more popular myths - it might help for fileservers but products like exchange and sql server need dedicated spindles - I'm sure there's some ms whitepapers on io performance.
[font="Comic Sans MS"]The GrumpyOldDBA[/font]
www.grumpyolddba.co.uk
http://sqlblogcasts.com/blogs/grumpyolddba/
February 27, 2008 at 1:22 pm
I just noticed you mentioned SAS - watch out for sata drives in your SAS trays! Sata and sas drives spin slower usually 7.2k and 10k this decreases response time and volume of supported io throughput.
[font="Comic Sans MS"]The GrumpyOldDBA[/font]
www.grumpyolddba.co.uk
http://sqlblogcasts.com/blogs/grumpyolddba/
February 27, 2008 at 1:48 pm
On our SQL Servers we only use SAS drives that are 15k.
Does anyone know of any good links that explain the basics of SAN technology? I need to better understand how to configure a SAN for SQL Server, what are the most common bottlenecks, what are the components of a SAN, etc...
Thanks, Dave
February 27, 2008 at 3:10 pm
it's a bit black box - I did two levels of snia training in fibre channel architecture to help me understand http://www.snia.org - in the uk there's a dummies guide to storage area networks - see http://www.grumpyolddba.co.uk/reading/reading.htm for links - the two books are very good.
I have to finish my blog post about lun alignment but you might find this of interest http://www.microsoft.com/technet/solutionaccelerators/wssra/raguide/StorageDevices/strgDvcBG_9.mspx
I don't usually like posting lots of links but sans are such a major bottleneck. yup I do recall smaller sas disks are just availble at 15k
[font="Comic Sans MS"]The GrumpyOldDBA[/font]
www.grumpyolddba.co.uk
http://sqlblogcasts.com/blogs/grumpyolddba/
February 28, 2008 at 9:29 am
colin Leversuch-Roberts (2/27/2008)
I just noticed you mentioned SAS - watch out for sata drives in your SAS trays! Sata and sas drives spin slower usually 7.2k and 10k this decreases response time and volume of supported io throughput.
anandtech and other websites did testing and the rotational speed doesn't really improve performance that much. the actual drive electronics do. HP uses SATA drives with NCQ and they perform same as SAS.
the tests they did with western digital sata drives with NCQ outperformed SCSI drives with faster rotational speeds in some cases
February 28, 2008 at 9:38 am
DBADave (2/27/2008)
On our SQL Servers we only use SAS drives that are 15k.Does anyone know of any good links that explain the basics of SAN technology? I need to better understand how to configure a SAN for SQL Server, what are the most common bottlenecks, what are the components of a SAN, etc...
Thanks, Dave
SAN is unfortunately more of a concept than a specific architecture. There are radically different "under the covers" implementations, depending on Vendor AND price point. EMC (the one I've had most exposure to) had at least 2 separate radically different internal "architectures" depending on whether you're buying the "expensive" model or the "ludicrously expensive" model.
----------------------------------------------------------------------------------
Your lack of planning does not constitute an emergency on my part...unless you're my manager...or a director and above...or a really loud-spoken end-user..All right - what was my emergency again?
February 28, 2008 at 3:55 pm
beware of tests showing disk performance - for sql server the most important factor is io/sec and this is largely a factor of rotational speed. You need to do the maths based upon the manuafacters spec to calculate disk performance, for instance most sata drives quote performance based upon 1gb sequential reads and writes - this does not match general sql server io throughput - anyway i don't want to get into another argument about disks.
I agree with the comment about SANs , most people only see the physical disk arrays whereas a san is actually a storage area network - note the area and network.
[font="Comic Sans MS"]The GrumpyOldDBA[/font]
www.grumpyolddba.co.uk
http://sqlblogcasts.com/blogs/grumpyolddba/
February 29, 2008 at 12:07 am
I second Matt's comment: the only thing you can really say that's common between all SANs is that they are a block-level abstraction over a pool of disk resources (as distinct from NAS for example which is file-level). This pool of disk is often connected by a range of network fabrics to a number of hosts which are allocated chunks of the pool.
*** DISCLAIMER: I've not actually used any form of SAN myself, so all this is based on lots of reading and could be total bollocks ***
The typical setup seems to be:
- Your disk arrays (shelves) are fairly standard enclosures you are familiar with from DAS. The disks themselves can be anything from SCSI to SAS to FC-AL to SATA.
- Each array is connected to one or more storage controllers (connection depends on disk type, eg FC-AL for fiber SAN, etc.), which are really just specialized servers with RAID controllers, running a custom OS (often *IX-based), with most of their RAM dedicated to disk caching. Some of these are even rebadged line servers (Dell PE28xx for example) using standard components.
- Your client hosts are connected to the storage controllers via a network or loop: this is typically either FC-AL (using FC adapters) or gigabit ethernet (using either standard NIC with a software initiator or dedicated iSCSI HBAs with an onboard initiator), or sometimes SAS for a poor-man's mini-SAN.
The basics are still the same as with DAS: you use some form of RAID at the storage controller level, the advantage is in the mass interconnect you get from being able to plug many hosts into the same disk pool, plus some (hopefully) smart software that allows you to easily manage the pool and allocate it where it's needed.
Performance-wise, FC-AL has traditionally had an edge as you theoretically have a fast fiber pipe from HBA all the way to the actual disks themselves - the aggregate bandwidth available in a loop has gone from 1GBs to 2GBs to 4GBs as the technology matured. But the big downside was (and still is) the sheer expense of every part of an FC SAN. The disk themselves cost big $.
In the last few years we've seen iSCSI SANs become practical in the mid-performance range, especially with SAS backends (eg SAS from array to storage controller, and multiple GbE NICs to the hosts) with fabric bandwidths of 3Gbs possible now and higher coming with 10GbE soon.
The software seems to be a big differentiator between the vendors - some of the bells-and-whistles like block-level WAN replication and snapshots are something that is very tricky to do right without a SAN and IMHO one of the major reasons to jump from DAS to SAN. Some of them however charge an arm and a leg for these extras...
Architecturally you have the "all-drives-in-one-big-black-box-pool" approach at one end (Equalogic for example, and I think HP's EVA?) where the SAN software and controllers manage resource allocation and IO routing fairly automatically, and your EMC Clarions, etc. at the other where you have a fairly fine-grained control (and corresponding admin overhead) over LUN grouping, RAID levels, etc. Each vendor of course touts their method as the best.
I suspect to some degree that if you throw enough spindles and disk cache at it you can make any architecture perform fairly well, but that you can easily misconfigure the whole complex beastie and make your $100K+ SAN give abysmal IO speeds.
Apologies for the length of this - it wasn't supposed to turn into an essay. Can any of you guys with actual SAN experience shed some light on the practical differences between the various vendor's architectures?
Regards,
Jacob
February 29, 2008 at 10:38 am
Any company that implements a SAN for database storage without getting a professional to help them with proper setup and allocation is pissing away a LOT of money. They will absolutely not get anywhere NEAR the performance they should out of the hardware. There are a LOT of things that can and should be done to get optimal performance, most of which newbies to SAN's have no idea even exist.
Best,
Kevin G. Boles
SQL Server Consultant
SQL MVP 2007-2012
TheSQLGuru on googles mail service
February 29, 2008 at 10:50 am
But what about my LUN question? We have SAN experts in-house, but their experience pertains to configuring a SAN for file systems, not SQL Server. I can call EMC, but was hoping to get some info on this forum regarding how dividing a RAID 10 into multiple LUNs can impact SQL Server performance. The problem with calling a vendor like EMC is you never know if you are being sold something you don't really need. Thus the need for a general understanding of how a LUN works so I can at least hold a discussion with a SAN expert and have some idea if what the person tells me is correct. I also need to know what questions to ask.
Thanks, Dave
February 29, 2008 at 11:28 am
Anytime you have more than one 'thing' requiring I/O from a set of physical drives you have the potential for I/O contention and the accompanying performance issues. Having tempdb data and other transaction logs all hitting the same 4 drive RAID10 set can lead to one system (or both) being starved for I/O. It is also completely possible that neither system will have a performance problem because your system isn't that I/O demanding. This is where knowing your data and your data access patterns comes into play. If you have analyzed your existing database system and found tempdb I.O delays then sharing the drives could be problematic. Likewise if you are seeing I/O stalls on your tlogs. Some systems would die a horrible death with only 2 spindles serving up all of that I/O. For others, the 2 active drives is more than plenty.
Best,
Kevin G. Boles
SQL Server Consultant
SQL MVP 2007-2012
TheSQLGuru on googles mail service
February 29, 2008 at 12:13 pm
I'm still not understanding how LUNs impact a SAN. Figuring out tempdb loads is the easy part. Understanding the mechanics of a SAN and how that compares to traditional servers and server storage is a completely different animal. I've been told there are more spindles available when using fiber channel drives then compared to SATA or SAS drives and that a LUN makes it possible to carve up SAN storage into multiple logical units without noticing a performance impact. This is where an explanation of how a LUN physically functions would be beneficial. I also need information on how fibre channel works mechanically. Does it have the same number of spindles as SATA or SAS or does FC have more spindles. What other components exist on a SAN and not on a server utilizing SATA or SAS and how do these components affect performance.
Thanks, Dave
February 29, 2008 at 12:40 pm
(I'm sure that one of the SNIA's will be by shortly to rap my knuckles sharply with a ruler, so let's make this "simple")
I think you're reading too far into the mystique of SAN's. Plainly put - SAN's are essentially a series of RAID disk enclosures, each with their own controllers, connected to each other in some way. You then usually have some type of over-arching controller acting as "traffic cop". Now - once you get into specifics, there are lots of differences on HOW the enclosures are connected to each other, HOW MANY ways there are to connect each enclosure to the "mesh", how the controller takes care of multiple incoming requests, etc... but still - it's not (IMO) so far removed from the concepts of "traditional" directly attached disk arrays. It just takes that basic model, puts it "on steroids" using many redundant very high-speed pathways and a LOT of cache, but the fundamentals don't change.
A LUN is simply a chunk of that space. It's based off of one or more slices from one or more SCSI disk sets in some of the enclosures above. Now - what that LUN is made up of is what will determine how fast it is, and how well it would "do" for your purpose. RAID is still RAID, so RAID5 still essentially has the same performance bottlenecks on random writes as it did "before" SAN's.
Bottom line - if you wouldn't set up your SQL server to "share" disk sets in a locally attached setup, chances are you wouldn't do it in a SAN setup either. If you wouldn't use RAID5 in your disk sets because of the write performance issues, then you wouldn't likely want that in your SAN LUN's either.
Any of the "special attributes" your specific SAN might have or not to gain speed or pre-cache, become relevant only with specific knowledge as you how you intend to use it. That's where the disk specialist comes in. But - even if you don't know all of the specific tricks, if you're at least comfortable talking/dealing with local storage optimization, you should have at least some amount of basis to know if you're being fed sunshine from the wrong end....
----------------------------------------------------------------------------------
Your lack of planning does not constitute an emergency on my part...unless you're my manager...or a director and above...or a really loud-spoken end-user..All right - what was my emergency again?
Viewing 15 posts - 1 through 15 (of 31 total)
You must be logged in to reply to this topic. Login to reply