Why lun is Not a LUN

In part one of this discussion, I provided a brief answer on differences between LUN and lun, then began a longwinded historic narrative that delved into the time when dinosaurs were still roaming the SCSI landscape. There came a time when SCSI was no longer sufficient to satisfy the voracious growth in demand for large data storage capacity. What was deemed advantageous was centralized, highly reliable, and highly available storage architecture. That is where fibre channel SAN came in. In this continuation of part one we will discuss how the SCSI convention was adapted for the FC world.

SCSI Address
In SCSI, a lun is only unique under each target, and is not an independently unique identifier. If a computer has multiple SCSI adapters (buses), each adapter is represented by a unique ID. Therefore, specific communication with any SCSI device is accomplished using a precise address consisting of adapter ID, target ID, and lun – ASL for short.

Before fibre channel, some SCSI vendors attempted to insert more than one bus in a single adapter by adding a parameter called “channel.” The complete address then became ACSL. Although the “channel” feature was eventually dropped (and is therefore always zero), to this day almost all operating systems use the ACSL convention when addressing a device. For example, in a Linux machine, typing “cat /proc/scsi/scsi” at the console will list the ACSL of every storage device.

This SCSI convention is deeply ingrained in all current operating systems, no matter if the connectivity is FC, SATA, SAS, or USB. All storage devices use the SCSI convention and protocol when accessing disks, even though there is hardly any real SCSI hardware present anymore. When LUNs are provisioned to hosts in an FC SAN, they must do so using the old SCSI addressing scheme. Fortunately, the mapping from LUN to SCSI address is reasonably straightforward.

The Fibre Channel SAN
As mentioned earlier, SAN stands for “Storage Area Network,” and the key word is “network.” The advantage of SAN is that a centralized storage system can provision logical disks – or LUNs – to many hosts. This is performed in a “network” manner via fibre channel switches, with multiple hosts typically connected to the storage system through these switches. The storage systems in SAN are mostly RAID, or some similar virtualized storage system, where logical disks are created for and assigned to specific hosts by the storage controller.

Since “logical disk” is too awkward a term to use, and “LU” is too vague, “LUN” has become the preferred nickname for these disks. LUNs are created as independent logical disks which are then assigned to hosts. Once assigned to a host, it’s as if there is a SCSI cable directly connected between the host and these disks. As far as the hosts are concerned, these are SCSI disks, just like old times.

From the SAN, each host get its own LUNs. These LUNs are not necessarily permanently provisioned to specific hosts. The assignment can be easily changed. Also, in a cluster configuration, the same set of LUNs are provisioned to all the nodes of the same cluster. To these hosts, it’s as if they each have a SCSI cable connected to the same set of LUNs. How does the provisioning, or assignment work? That leads to the concept of LUN Masking.

LUN Masking & lun
In an FC SAN, each host has one or more FC initiator ports, and each port has a WWPN (World Wide Port Name). A host is identified by its initiator WWPNs. An FC storage system has multiple FC target ports, also identified by WWPNs. When a set of LUNs are provisioned to a host, this is accomplished by “LUN Masking” the LUNs to the initiator WWPNs of that host, through certain target ports.

What this means is that the storage controller is instructed to only allow commands from specified initiators to be able to access these LUNs. Some storage may even allow administrators to specify to which target ports these commands are allowed. This “masking” allows the LUNs to be only visible to the assigned initiators.

Furthermore, when these LUNs are provisioned to the host, a unique logical unit number (lun), is assigned to each LUN. The assignment is usually handed out in a consecutive manner, but this is not mandatory. One can see this addressing scheme fits right into the original SCSI addressing convention, with initiator, target, lun, forming what we call the I-T-L, providing a unique SCSI address.

Multipath & GUID
Since there are often multiple initiators in a host, and since storage may be provisioned through multiple targets, it follows that the same set of LUNs may be accessed by multiple I-T-L paths. Most of the time, only the I and T are different, but it is possible (though rare) that the lun assignment number can be different when assigned to different initiators, even on the same host.

This further demonstrates how tenuous the logical unit number is and shows how some rules of the old SCSI world no longer apply. When multiple paths can lead to the same set of LUNs, a unique identifier must be used to make sure the correct LUN is being accessed through various paths. This is where the various types of “Vital Product Data” of the LUN is required, so that globally unique identity information is provided for each individual logical unit.

One of the most common types of unique identifiers used is the NAA identifier string, which can be loosely called GUID, or UID, or global unique ID. The NAA, however, doesn’t seem to have a standard nomenclature, other than it is generally a 16 byte number, and that it is represented by a 32 digit hexadecimal string.

This identification information is what the multipath driver uses to consolidate the paths for individual LUNs. It is retrieved in the form of an inquiry command from various pages. From there, regardless what the ACSL paths are, the “GUID” is the only identity it uses to decide which LUN comes from what paths. In this sense the logical unit number is not even part of the identity information.

After all this protracted rambling, I assume these concepts of lun, LUN, and GUID are now as clear and self-explanatory as Fermat’s Last Theorem. As we mentioned, this information is provided for the intention of paving the way for the subsequent descriptions on the new and groundbreaking product features coming up for the data migration product, DMS, from Cirrus Data. They are for destination auto-storage allocation, and for true zero-downtime migration, including cutting over to new storage. These features will bring the technology of data migration to a whole new level.