SQL Server - LUN configuration

Asked By Igor Marchenko

19-Nov-09 06:40 PM

Hello!

We will be installing SQL Server 2008 Active/Active Cluster on Windows
2008. SAN engineer told us that all space will be allocated accross 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

19-Nov-09 10:05 PM

Well, that really depends upon what SAN you are using, how many spindles are
actually setup and available, the controller (or filer) associated and a lot
of other factors.

For example, using a Netapp SAN with an aggregate using 64 physical drives
that has been configured with RAID-DP - you really do not need to worry too
much about having multiple LUN's.  However, even in that configuration I
would recommend two LUN's and separate them across two different filer's
where you have one dedicated to data files and the other for log files.

Another example is using an HP EVA - with a disk group defined and built
with at least 80 spindles.  You could then present separate LUN's created
from the disk group where you have one as vRAID1, the other as vRAID5 - and
separate the logs from the data.

Not that it is actually necessary on the higher end SAN's - which can most
likely accommodate your activity on a single LUN with no noticeable latency
or throughput issues.

20-Nov-09 09:01 AM

This is typical SAN "engineering".  More spindles = more I/O capacity.
Except most designers use RAID5 and use up the extra I/O ops in RAID
overhead.  Most SAN layouts are designed around maximizing storage space,
not maximizing I/O operations for SQL server.  Unfortunately, most SAN
companies believe in their "Magic SAN Dust" that somehow creates I/O cycles
out of thin air, so you are stuck with this layout.

You must create at least one LUN per instance.  These LUNs get presented to
all cluster Nodes.  The Cluster service arbitrates ownership so that no data
corruption occurs and only one Node "owns" a LUN at any given time.

Partitioning a LUN gains nothing except additional management complexity.

--
Geoff N. Hiten
Principal SQL Infrastructure Consultant
Microsoft SQL Server MVP

20-Nov-09 01:07 PM

Geoff,

I was under impressions I will need separate LUNs (mapped to
corresponding drives) for tempdb, log, data files, etc. You are saying one
LUN per instance is OK. In this case, will I create multple logical drives on
top of single LUN? If so, can I define different RAID level (does RAID level
even matter in the world of high end SAN)?
Sorry, I am pretty novice in the SAN world. I am trying to figure out if
single LUN with multple drives (corresponding RAID levels) is the way to go.

Thank you,
Igor

20-Nov-09 01:25 PM

The only  reason to create separate LUNS is if there are separate sets of
disks behind those LUNS.  Since your SAN engineer told you they all come
from the same pool, further partitioning gains you no benefit.

Again, all the disks get pooled together in a single large RAID set
(according to your engineer).  You get LUNS sliced off of this large RAID
set.  The RAID set, not the LUNS is the physical storage layer.

--
Geoff N. Hiten
Principal SQL Infrastructure Consultant
Microsoft SQL Server MVP

23-Nov-09 08:05 AM

..in our setup we always go for the same number of luns for each sql (and
sql cluster) build purely on "standard" build configuration, even if each
lun does not map directly to a seperate physical array. Generally though I
get to have a large say in the way disks get carved up so thankfully
(usually) each lun maps to a seperate array.

I dont like OS partitioning mostly because I prefer the disk architecture to
be independant of OS (since this can introduce other issues).

24-Nov-09 02:57 PM

Thanks Geoff!

24-Nov-09 02:57 PM

Thanks Mark!