| Author |
Topic |
|
imarchenko
Yak Posting Veteran
57 Posts |
 Posted - 2009-11-19 : 18:38:40
|
| Hello! We will be installing SQL Server 2008 Active/Active Cluster on Windows 2008. SAN engineer told us that all space will be allocated across the same set of drives. I know this is not recommended because of potential IO issues, but I guess this is something we would have to live with. The question we would have to answer right now is whether we should create one LUN per Node (my understanding is that the same LUN can not be shared by two nodes) and then create logical drives from single LUN or one LUN per logical drive. I suppose there will be no difference performance wise since LUNs will be connected to the same set of drives, correct?Also, SAN engineer told us that RAID level is irrelevant which I have hard time believing to.Thank you in advance,Igor |
|
|
robvolk
Most Valuable Yak
15732 Posts |
Posted - 2009-11-19 : 18:48:27
|
quote:
Also, SAN engineer told us that RAID level is irrelevant which I have hard time believing to.
Your SAN Engineer is an idiot, and you should replace him. Get someone who's actually done a SQL Server installation. Any mid-level book (including Books Online) will have enough detail on SQL Server storage and access patterns to show how it matters.This book is a good reference for SAN and cluster hardware for SQL Server:http://www.amazon.com/Pro-Server-2005-High-Availability/dp/159059780X/There's also a Kindle edition if you want to get it quickly. |
 |
|
|
imarchenko
Yak Posting Veteran
57 Posts |
Posted - 2009-11-19 : 19:10:59
|
| Basically, you are saying that creating LUNs across single set of drives is a bad idea or that RAID is relevant regardless of SAN configuration (or both)? Should I create one LUN per logical drive?Thanks,Igor |
|
|
|
russell
Pyro-ma-ni-yak
5072 Posts |
Posted - 2009-11-19 : 19:38:08
|
Actually RAID level is irrelavent when it comes to SANs. At least high-end ones.Mature SANs like those from NetApp can dynamically allocate drives as needed and will do a better job than the average DBA will allocating drives.I'm not saying your SAN engineer isn't an idiot, but his claim about RAID levels is true.  |
|
|
|
robvolk
Most Valuable Yak
15732 Posts |
Posted - 2009-11-19 : 21:13:48
|
quote:
Actually RAID level is irrelavent when it comes to SANs. At least high-end ones.Mature SANs like those from NetApp can dynamically allocate drives as needed and will do a better job than the average DBA will allocating drives.
Allocating drives in what way? Adding new, empty drives to an existing RAID set? Moving data from one type of RAID volume to another based on access patterns? I'm not clear on what you're trying to say, and dynamic allocation does not by itself improve performance or reliability (it is, in fact, irrelevant to RAID level)  |
|
|
|
russell
Pyro-ma-ni-yak
5072 Posts |
Posted - 2009-11-19 : 22:26:58
|
| Ok, generally, with a SAN, we don't implement RAIDs. The SAN does. We can create logical drives. I believe (though could be wrong here) that EMC SANs utilize a RAID 5 configuration. This is not something the DBA changes, or is particularly interested in. A NetApp SAN uses a RAID 6 config.When we create LUNs, this isn't creating a disk array in the normal sense. The striping and parity is handled by the SAN, not by us.What we are really attempting to do is to configure our drives in a way to optimize I/O (and of course create fault tolerance). The SAN handles this for us. And the high end SAN can do this in a far more efficient manner than pre-allocating disks to RAID 5 or RAID 10 arrays.The SAN will allocate I/O accross the disks as it sees fit. We can have a virtually unlimited number of disks to spread the I/O accross.As a DBA, I want to slice up the disks in the way we've all been taught over the years. But the SAN will do this for us and do it more efficiently. When I said "Allocate Disks" I should have said "Allocate I/O." But in fact the SAN can dynamically allocate unused disks as well (though that is really out of the scope of this discussion).Finally, and you probably already know this, multiple LUNs can and do share the same physical disks in many configurations. This creates a paradox for the DBA: Should I still be concerned about sperating my log files, tempddb, and mdf/ndf files? The short answer is yes. This is because the OS can't tell the difference between a logical drive and a physical one, but the I/O throughput of the SAN wouldn't be changed at all if we didn't.Ok, sorry for being so long winded here. I need to catch my breath, go pick up my kids and then maybe have a beer lol. |
|
|
|
russell
Pyro-ma-ni-yak
5072 Posts |
Posted - 2009-11-19 : 23:56:21
|
| Whoops, small (but critical) mistake in above post. Distinct LUNs don't share drives with each other...logical drives do.Phew, good thing it's late and no one called me out on that yet lol.As long as I'm at it, another huge advantage of a SAN is the caching. This means that in many cases when SQL Server needs to go to disk to retrieve data, it can grab it from the SAN's cache instead, dramatically improving I/O performance. |
|
|
|
imarchenko
Yak Posting Veteran
57 Posts |
Posted - 2009-11-20 : 11:40:17
|
| Gentlemen, Thanks for your feedback! But I am still unclear whether:1. I should create one LUN per each drive.2. Create RAID following best practices (RAID10 for data, etc.). Since all LUNs will be sharing the same set of drives (bad I know), I suppose performance will suffer (log, tempdb, data files on the same set of disks). I am not sure how big the impact would be though.Thanks,Igor |
|
|
|
russell
Pyro-ma-ni-yak
5072 Posts |
Posted - 2009-11-20 : 12:23:25
|
| what SAN is it? |
|
|
|
imarchenko
Yak Posting Veteran
57 Posts |
Posted - 2009-11-20 : 12:51:43
|
| 3PAR |
|
|
|
russell
Pyro-ma-ni-yak
5072 Posts |
Posted - 2009-11-20 : 13:00:42
|
| never used 3PAR. generally, you create luns for each logical drive you need. |
|
|
|
support.sql
Starting Member
15 Posts |
|
|
|
LUN configuration