Source: 09 Jan 2008 | Greg SchulzLUNs transform raw storage into usable space, accessible from any attached operating system. However, creating and implementing LUNs can be a challenge. In this handbook you’ll learn what LUNs are, how they’re used, how to implement LUNs, how to manage LUNs, how to partition LUNs and the concepts involved in LUN migration.
LUN basics
For open systems environments, including Windows, fixed-block architectures or fixed-block addressing is the most common basis for performing I/O operations to and from a disk drive. The most common I/O command protocol for open systems is the
SCSI command set, not to be confused with parallel SCSI cabling, as there is a difference. The
SCSI command set is implemented on different network and storage I/O interfaces or transports, such as
Fibre Channel,
iSCSI,
SAS, InfiniBand and others.
Part of the SCSI command set protocol is an initiator (source) that requests an I/O operation (read, write or status inquiry) and a target (destination) device with a subaddress known as a
LUN. The target can be a single disk in a JBOD array with each HDD having a different SCSI target and possibly a unique or selectable LUN of the device supports it. A common use of LUNs is in storage systems or arrays that incorporate some type of controller, usually with
RAID where multiple HDDs are configured and aggregated into a RAID or volume group and then assigned a unique LUN and accessed via a SCSI target ID.
For example, assume you have a storage system with 32 300 GB HDDs configured into two separate RAID groups, each with 16 HDDs. One RAID group is a RAID 5 14+1 and a hot spare, the other being a RAID 10 (8+8). The RAID 5 group would have about 4.2 TB of usable capacity, while the RAID 10 group would be about 2.4 TB. The storage system could present a single LUN or volume to a server or servers for each of the RAID groups or, the RAID groups could be subdivided into multiple smaller LUNs for more granular access of the storage depending on specific application needs or preferences.
To learn more, check out chapters 3 (Networking with your Storage) and 4 (Storage and I/O Networks) in my book “Resilient Storage Networks” (Elsevier) along with other SearchStorage.com and
Storage magazine tips and FAQs, including
Tracking down those missing bytes.
Implementing LUNs
LUNs can be created and implemented in various configurations, such as capacity, address, or boot device, along with what host servers can see or access the LUN or volume. Creation of a LUN can be done using vendor supplied management tools or third-party tools. LUNs can be created on storage systems and virtualization appliances along with other storage devices, including virtual tape libraries (VTL). Some third-party storage management tools enable you to create LUNs on different vendor’s storage systems, while other tools simply provide tracking and storage resource management (SRM) information for LUNs.
There are a few generic steps for creating a LUN. First, it is necessary to create a
RAID group or volume group on the storage system or virtualization appliance mapping some number of unused HDDs or devices together. The next step is assigning a RAID level and then subdividing or “carving” out LUNs from the RAID group assigning manually or automatically address numbers.
The number of LUNs supported by a storage system will vary by vendor implementation and storage I/O interface, such as
Fibre Channel,
SAS, Parallel SCSI, iSCSI, etc., being used. Likewise, various operating systems and virtual servers, including VMware, will have different limits on how many LUNs can be accessed in total and per adapter port on the physical server. Some operating systems also have a default or preference that certain storage, including boot devices, is on certain targets and LUNs. For example, older versions of Windows NT would not recognize nonzero LUNs until upgraded to newer versions and registry entry adjustments.
Some storage systems support the notion of partitions where a group of LUNs or volume groups can be mapped into a partition that appears to the host servers as a unique storage system with indicial LUNs. For example, 20 servers could be attached to an LSI/Engenio-based storage system that has four Fibre Channel ports. Assuming that the storage system has 40 total LUNs (or more), 20 partitions could be created with each partition containing two LUNs with one of the LUNs being LUN 0 as a boot device and mapped to a particular server adapter address. Each server would think that it has its own unique LUN 0 for a boot device yet in reality, there are 20 LUN 0s, each isolated from the other in a shared storage environment.
LUN management
Some storage systems support partitions to help allocate unique
LUNs to different servers. Depending on implementation, some vendors support partitions that incorporate LUNs from different volume or
RAID groups for flexibility, or if a LUN can span multiple storage enclosures and I/O busses inside the storage system to avoid performance contention.
Another feature that will vary by vendor implementation is how LUN expansion takes place if supported. For example, vendors will often support on-line growth of RAID or volume groups to facilitate creation of additional LUNs, while others support dynamic expansion of existing LUNs. However, do not assume that all implementations are the same and that dynamic expansion means while data is being read or written to a LUN. Check the details and ask vendor-specific questions as to what it does or does not support and if there are any extra fees for enhanced LUN functionality.
In addition to the number of LUNs supported, the size of LUNs supported will also vary by storage system and operating systems. Most storage devices and operating systems today should be able to support at least a 2 TB LUN. Some operating systems can support addressing and accessing of LUNs larger than 2 TB either natively or via upgrade patch kits.
For storage systems, look at the total number of LUNs supported by a particular solution or if that vendor has guidelines or restrictions on the number of LUNs that can be accessed on a given physical or adapter port. Also, check to see what limitations on addressing or flexibility exists with volume mapping and masking software features in storage systems to enable specific LUNs to be seen or hidden from different servers.
For LUNs being accessed by nonclustered or failover server nodes, typically you would hide those LUNs from other servers so that they are not seen and accessed. Similarly on the server, path management software from vendors, such as Microsoft’s MPIO, IBM’s SDD, Symantec Corp.’s DMP and EMC Corp.’s Powerpath, should be configured to access and support path failover to LUNs accordingly.
Advanced LUN topics
Many storage systems support data migration or
LUN migration, however, the devil is in the details. Some vendors support movement of data while a LUN is being read and written, while others can automatically move data based on policies when there is no write activity. Ask your vendor if it supports movement of the data in an entire LUN while applications are actively reading and writing to the LUN and what its caveats are.
Investigate how a vendor supports LUN affinity and cache coherency. Even though a LUN may be accessible via two or more controllers, nodes or processors, find out if one controller owns or acts as a primary to maintain data integrity and if so, how are the I/Os moved or “shipped” between the controllers to maintain cache coherency without negatively impacting performance.
Besides using host-based third-party or operating system supplied volume managers, LUNs can be created from standalone storage devices that support selectable subaddressing, in addition to specifying SCSI target addresses. LUNs can also be created and run on standard servers as appliances or on special purpose services blades in SAN switches.
Below are some important things to remember:
Avoid performance contention between LUNs by avoiding allocating LUNs from the same RAID group to active and competing workloads if possible
Exercise caution creating RAID groups factoring in where HDDs exist in enclosures and on what internal busses to avoid contention
Exercise caution intermixing various types of HDDs of different capacity, speeds and interfaces adhering to vendor recommendations and guidelines
Understand what performance impacts to LUNs when re-sizing, migrating or performing other operations including snapshot copies or replication
Follow vendor guidelines pertaining to creating large RAID groups of many HDDs vs. multiple smaller ones factoring that vendor’s specific architecture capabilities or limitations.
To learn more, check out chapters 3 (Networking with your Storage) and 4 (Storage and I/O Networks) in my book
Resilient Storage Networks (Elsevier) along with other SearchStorage and Storage Magazine tips and FAQs including
Tracking down those missing bytes., or send me a note with your questions.
Recent Comments