Logical unit numbers (LUNs) are standard in most data storage management software. Although extremely helpful in large data storage enterprises, LUNs are just as important for small- to medium-sized businesses (SMBs). This tip explores the background of LUNs in an SMB data storage environment, the different LUN features vendors have to offer and how to determine what type of LUN is best for your environment.
A LUN is a chunk of virtualized storage that is treated the same way as a disk. LUNs can include part of a physical disk or span several disks or arrays. Furthermore, by using volume manager software, such as Veritas Volume Manager from Symantec Corp., LUNs can be combined into larger logical volumes. The benefit of this is better control over virtualized storage without having to carve up your storage again with a new schema of LUNs. It can also aid performance if the LUNs that are combined into a single logical volume to support, say, a database, are on different physical disks or arrays.
LUNs are used for basic data management in an SMB and managing data in large enterprises. A typical enterprise may have hundreds or thousands of LUNs encompassing thousands or tens of thousands of physical disks and solid-state storage devices.
LUN management is a standard feature in storage management software. Most data storage products can handle the basics of creating LUNs. But having more than just the basics of LUN management is something many vendors aim for. Many products come equipped with additional and helpful LUN features. For example, Hewlett Packard (HP) Co.'s StorageWorks XP LUN Configuration and Security Manager offers standard LUN management features, as well as LUN size expansion and volume size configuration. It also prevents unauthorized servers from accessing the data.
What's the difference between a LUN and a volume?
LUNs versus volumes is a little tricky because the terms are sometimes used synonymously -- hence referring to a "logical" volume. The simplest explanation is that a logical volume can contain more than one LUN.
LUN masking and zoning in data storage management
Masking and zoning are key features of logical unit number management. In a well-managed system using LUN masking and zoning, users and servers can only see the storage resources they are allowed to access.
Zoning involves configuring the storage area network (SAN) fabric so LUNs are matched to the proper servers. Generally, end devices such as hosts can only see and access storage in the same zone. In addition to the obvious security advantages of limiting access to certain areas of storage to those servers who need it, zoning also allows allocating bandwidth by assigning particular ports to a zone. This ensures the ability to meet service levels.
Masking carries the concept of zoning a step further. Zoning limits a server's ability to see and access storage to certain ports on the SAN. However, each of those ports may serve more than one LUN. For example, if a port attaches to a storage array and the array has four or five LUNs, simple zoning may leave all those LUNs visible to any server which is given access to those ports.
Masking by server allows further subdividing access to the port. Only the LUNs authorized to access a specific server can then have access to the corresponding port. Then, even if several LUNs are accessed through the same port, the server masks can be set to limit each server's access to the appropriate LUNs. Also, LUN masking is typically done at the host bus adapter (HBA) or at the switch level.
Purchasing a LUN
Since LUN management is so central to modern storage management, it is seldom a separate purchase. Most enterprises use their data storage management software (the software you're using to manage storage) or sometimes software supplied with their switches or HBAs to handle LUNs.
Keep in mind that although LUN management is a basic feature in storage management software, vendors tend to implement separate LUN functions differently, such as zoning and masking. It is important to be thoroughly familiar with the way your software performs these operations before you begin to set up or manage LUNs. You need to understand the implementation as well as the functionality.
For example, different storage management packages can use a different sequence of operations to establish LUN zones and may have different naming conventions -- requiring a Zone 0 vs. a Zone 1, for example. Having the first zone be Zone 1 when the software is expecting it to be Zone 0 is likely to cause a problem. This is explained in the software management documentation, but it will be different for different software packages. You not only need to understand what a zone is, you have to follow the docs to set one up in your specific software.
Basic operations such as creating LUNs are usually extremely simple. Many programs, such as NetApp's System Manager have wizards to guide you through the process. But knowing which LUNs you want to create is more complicated. It's important to spend some time figuring out how you want to carve your data storage pool up into LUNs for best performance.
Respecting the physical data storage device
Although logical unit numbers are an example of virtualized storage and greatly simplify storage management on a SAN, it's important to remember that there are physical storage devices underlying them. This is especially true when it comes to deciding how you will carve that physical storage up using LUNs.
Because LUNs are so central to the process of managing enterprise data storage, their performance can have a major impact on storage I/O. This is especially true when supporting databases and other applications that put high demands on storage systems. A well-designed LUN schema can help to balance the load on the storage system and improve performance. But be careful when designing a LUN schema, because if you build one that tries to run too many competing LUNs through the same channel -- for example off the same set of spindles in an array -- it can bottleneck your system and degrade performance.
Another consideration in designing a LUN schema is the performance of the underlying physical storage. For high performance applications such as transactional databases, it's a good idea to use the fastest storage you have, i.e., 15000 rpm disks with direct Fibre Channel (FC) connections. Less demanding applications can use LUNs containing less expensive storage such as 7,200 rpm SATA disks.
While storage management software is seldom chosen just on its ability to manage LUNs, and all the SAN storage management products out there handle the basics of LUNs, there are some optional features you may want in your SMB data storage environment. One of the most useful is the ability to reallocate storage to LUNs "on the fly," without reconfiguring the entire LUN schema. This is especially useful for load balancing since it makes it easier to assign storage where it is needed on an ongoing basis. Products such as Cisco's Data Mobility Manager offer this feature.