LUNs

Basher

Basher

Basher

Soldato
Joined
18 Oct 2002
Posts
9,158
Hi Guys,

Right - I'm trying to learn about storage/SAN's very quickly and was wondering about LUNS. I've read a few definitions online but if anything, they're confusing me.

So could someone in the know briefly outline:

  • What LUNs are
  • The benefits LUNs bring
  • Typical scenarios for implementation

Many Thanks,
James
 
Lets keep it simple - Open my computer on your PC.

See your C drive.

That's a LUN.

It's a logical device presented to a host (aka "Server"). To the host ("server") it's just a blob of storage. In the background it can be a RAID 5 protected volume spread over five different drives and replicated to a seond site a hundred miles away.
 
Basher said:
Ok, that makes sense - how about multiple LUNs on one device (target) why would you do that over just partitioning?
Click to expand...

Sometimes you do. Some applications or application owners may take that single 100GB lun you give them and split it into partitions themselves using their application. Mostly they don't -

One reason not to is different requirements - for example on an exchange server I want to provision three different LUNs:

C: Drive - Boot from SAN volume, 40GB, RAID 5 4+1
D: Drive - Exchange Datbase, RAID 1 Mirrored, Replicated
E: Drive - Exchange Logs, RAID 10, Replicated

So I can use my array to present three different LUNs, with three different RAID types and different levels of replication. These can all be on three sets of different spindles if I want. All this is handled by the array without the owner of Exchange caring.
 
Last edited:
Its also slightly dodgy running an exchange DB on RAID 1 :/

RAID 5 minimum surely unless failure isn't "that" much of a problem.
 
Sp00n said:
Its also slightly dodgy running an exchange DB on RAID 1 :/

RAID 5 minimum surely unless failure isn't "that" much of a problem.
Click to expand...

It's not just failure, if you have a large Exchange deployment then you have to take into consideration to performance hit from the parity calculation of RAID 5 upon writes (of which Exchange is 30-40% of). RAID 1 doesn't have this overhead.

Read performance will be better IF you use more drives for the RAID 5 layout....however what people tend to do is take the capacity and use LESS drives....which means the read benefits are reduced!

This isn't to say that Exchange DB's shouldn't be done in RAID 5 - a huge number *are* and depending on requirements this is fine.
 
Last edited:
log files are written to sequentially, only read when the the database has to check for consistency. so a mirrored pair is fine.

databases are written to randomly,
databases are read randomly,

typical read/writes are 80/20%



on a system where your using
Raid 10 for your logs
Raid 1 for your databases.

is in my opinion "crazy"
 
the_jetsetwilly said:
log files are written to sequentially, only read when the the database has to check for consistency. so a mirrored pair is fine.

databases are written to randomly,
databases are read randomly,

typical read/writes are 80/20%



on a system where your using
Raid 10 for your logs
Raid 1 for your databases.

is in my opinion "crazy"
Click to expand...

Logs are written to sequntially yes, but you need to consider recovery.

You have 20000 users on Exchange. You have recovery SLA's that must be met or you will be fined. Exchange goes down and you need to load an old version of the DB, run ESEUTIL to get support from Microsoft, and use various tools to run the Database back to the time you want in a consistent state and supported - using the logs.

With logs on RAID 10 the recovery time is heavily reduced - all for just adding a few more drives. You use RAID 1, for the example given above, where the write level is so high that the parity calculation will affect the overall performance and the array - not because the DB needs the performance like I said above but the write penalty (4 write for RAID 5, 2 writes for R1) will have a negative impact on the array (remember an array is shared storage, lumping an app like Exchange on it can affect the other apps).

Prett much all the vendors recommend logs on RAID 10 even if the DB is RAID 5, 1 or 10.

As said above, it depends on your requirements but given the example above it doesn't sound so crazy does it? :)
 
i agree with you that if recovery time is important use raid 10 for logs if the solution doesn't allow using multiple storage groups etc, raid 1 on the database would limit the throughput of not only the restore but also the speed in which the users can access their data in an operational state.

The bit im having difficulty is with, setting a system up with Raid 1 for the database and Raid 10 for the log files.

are you really setting up exchange servers with Raid 10 for Logs and Raid 1 for the database?

bit of a digress from the original posters question :)

("crazy" was probably the wrong word to use)
 
the_jetsetwilly said:
i agree with you that if recovery time is important use raid 10 for logs if the solution doesn't allow using multiple storage groups etc, raid 1 on the database would limit the throughput of not only the restore but also the speed in which the users can access their data in an operational state.

The bit im having difficulty is with, setting a system up with Raid 1 for the database and Raid 10 for the log files.

are you really setting up exchange servers with Raid 10 for Logs and Raid 1 for the database?

bit of a digress from the original posters question :)

("crazy" was probably the wrong word to use)
Click to expand...

It's one example and i'll explain. If an Exchange DB is heavy in write and RAID 5 this puts an overhead on performance. Writes happen 4 times instead of twice and the parity calc is another overhead.

On a shared mid-range array this hits the cache and overall I/O. Other apps start to suffer (mostly due to the cache, exchange itself really bleeds without decent cache) so one way to avoid the high writes and the cache usage is to use RAID 1. It uses more drives but there's no parity calc.

it's not so much an exchange benefit decision as an array decision :)
 
agreed about the raid 5 having a greater IO hit but thats not my area of "concern" "mis-understanding"

its setting up a Database as a mirror. there must be some heavy caching going on for the users not to "feel it" after all theres just 2 disks for all the random access going on.
 
the_jetsetwilly said:
agreed about the raid 5 having a greater IO hit but thats not my area of "concern" "mis-understanding"

its setting up a Database as a mirror. there must be some heavy caching going on for the users not to "feel it" after all theres just 2 disks for all the random access going on.
Click to expand...

lol I see, I didn't mean a single mirrored pair. In the SAN world having a RAID 1DB doesn't mean just two drives! You can spread the whole volume over many drives - in the example I gave above (which is actually a real scenario) the Exchange DB is spread over 128 x 300GB 15k drives that are Raid 1 protected and the logs over 8 x 146GB 15k drives in R10.
 
Ok so it's all about a layer of abstraction? So how does that fit into this explanation? http://www.webopedia.com/TERM/L/LUN.html

This explanation seems to suggest that it's [FONT=Verdana, Arial, Helvetica, sans-serif]to distinguish among up to eight devices (logical units) with the same SCSI ID.[/FONT]

James.
 
Last edited:
You must log in or register to reply here.
Back
Top Bottom