A logical unit number (LUN) is a disk partition or area on a SAN made available in some way to a server. LUNs are the cornerstone of a server's relationship with its attending storage platform. The term LUN dates back to the early days of SCSI when each device was identified by a logical number, up to eight in those days. Now servers with a dozen or more LUNs are common and it's getting less common for them to be connected to a conventional internal SCSI disk array. However, the basic element of storage for the server is still referred to as the LUN.
So, what do you need to consider when creating LUNs?
The very first thing to consider is size. 32 bit Windows 2003 servers are only able to access a LUN of 2 TB or less but 64 bit versions allow access to LUNs of up to 256 TB. That sounds like an enormous leap forward but in reality it doesn't really matter. A single 256 TB LUN on an application server is likely to be nearly pointless, because of the way SAN platforms manage their storage and block-level snapshot backup technologies.
Making LUNs too large also increases the time it takes to recover data, because block pointers on disk need to be updated to reflect the prior state of play on the LUN. The more changed data on the LUN, the more "roll back" work that must be carried out. The general rule, as always, applies. Just because Microsoft tells you that you can do it, doesn't necessarily make it a good idea. Keep the LUN size down to a level that is commensurate with the task required of it.
Separation of information is as important on a SAN as it is with locally attached disks. Keeping the databases away from their transaction logs is desirable -- although by no means mandatory depending on what type of SAN you are using. Without the transaction log files, a failed database cannot be restored from tape and brought up to date. So, if the disks on which both database and logs reside fail in such a way that a restore must be carried out, the recovery point can only ever be as up to date as the time of the last backup.
There are two ways to mitigate this. One way is to use a RAID level that allows for two simultaneous disk failures (RAID6, 10 etc). The other is to use separate disks, create unique LUNs on each and keep careful records as to which LUN is on which set of disks so that there is no potential for permanent data loss.
While it is perfectly possible for many servers to access the same LUN in a SAN based environment, it is not a desirable state of affairs. Ensure that the storage software restricts access to LUNs, so that only the target server is able to read and write to the LUN. The obvious exception to this is with clustering where both (or more) nodes need to be able to use the LUN. Leave the decision on which one is actually accessing the LUN to the operating system of the server in question. All too often storage administrators don't give the right access to servers and when the server is being tested, a failover to the passive node does not work properly, if at all.
About the author: Mark Arnold, MCSE+M, Microsoft MVP, is the principal consultant with LMA Consulting LLC, a Philadelphia, PA-based private messaging and storage consultancy. Mark assists customers in designs of SAN-based Exchange implementations. You can contact him at mark.arnold@msexchange.me.uk.
