Dynamically tracking logical units moving between input/output ports of a storage area network target

A technique for operating a storage area network includes detecting an input/output operation failure associated with a logical unit number, which is associated with a first target port. The technique also includes determining, subsequent to the detected input/output operation failure, whether the logical unit number is associated with a second target port. Finally, the technique includes routing subsequent input/output operations for the logical unit number to the logical unit number via the second target port, in response to determining that the logical unit number is associated with the second target port.

BACKGROUND

This disclosure relates generally to a storage area network (SAN) and, more particularly, to techniques for dynamically tracking logical unit numbers moving between input/output (I/O) ports of a SAN target.

In computer system storage, a logical unit number (LUN) is a number used to identify a logical unit, which is a device addressed by a small computer system interface (SCSI) protocol or a protocol that encapsulates SCSI, such as Fibre Channel (FC). SCSI is a set of standards for physically connecting and transferring data between computer systems and peripheral devices. The SCSI standards define commands, protocols, and electrical and optical interfaces. The SCSI protocol defines communication from host-to-host, host-to-peripheral device, and peripheral device-to-peripheral device. Typically, most peripheral devices are SCSI targets that are incapable of acting as SCSI initiators, i.e., unable to initiate SCSI transactions themselves.

FC protocol is a transport protocol that predominantly transports SCSI commands over FC networks. FC supports a number of protocols, including SCSI, asynchronous transfer mode (ATM), and Internet protocol (IP). FC is a popular storage area network (SAN) protocol that allows organizations to consolidate storage into data center storage arrays, while providing hosts (such as database and web servers) with the illusion of locally-attached disks. A SAN is a dedicated storage network that provides access to consolidated block level data storage. A SAN architecture is typically used to attach remote computer storage devices (e.g., disk arrays, tape libraries, and optical jukeboxes) to servers in such a way that the devices appear locally attached, with respect to an operating system (OS). In general, a SAN only provides block-level operations, as contrasted with file abstraction. However, file systems may be built on top of SANs to provide file abstraction. Protocols employed in SANs include SCSI, FC, advanced technology attachment (ATA), and ATA over Ethernet (AoE), among other protocols.

LUNs may be used with any peripheral device that supports read/write operations, but are most often used to refer to logical disks created on a SAN. Peripheral device storage (or secondary storage) differs from primary storage in that secondary storage is not directly accessible by a central processing unit (CPU) of a server computer system (server). That is, a server usually employs input/output (I/O) channels to access secondary storage and transfers desired data to a CPU using an intermediate area in primary storage. Unlike most primary storage, secondary storage does not lose data when a storage device is powered down, i.e., secondary storage is non-volatile. In general, modern computer systems typically have two orders of magnitude more secondary storage than primary storage. In modern computer systems, secondary storage usually takes the form of hard disk drives (HDDs) or solid state drives (SSDs).

FC host bus adapters (HBAs) are generally available for all major computer architectures and buses. Each FC HBA has a unique world wide name (WWN), which is similar to an Ethernet media access control (MAC) address in that the WWN uses an organizationally unique identifier (OUI) that is assigned by the Institute of Electrical and Electronics Engineers (IEEE). A first type of WWN is a world wide node name (WWNN), which can be shared by some or all ports of a peripheral device. A second type of WWN is a world wide port name (WWPN), which is necessarily unique to each port of a peripheral device.

SUMMARY

According to one aspect of the present disclosure, a technique for operating a storage area network (SAN) includes detecting an input/output (I/O) operation failure associated with a logical unit number (LUN), which is associated with a first target port. The technique also includes determining, subsequent to the detected I/O operation failure, whether the LUN is associated with a second target port. Finally, the technique includes routing subsequent I/O operations for the LUN to the LUN via the second target port, in response to determining that the LUN is associated with the second target port.

DETAILED DESCRIPTION

The computer program instructions may also be loaded onto a computer, other programmable data processing apparatus, or other devices to cause a series of operational steps to be performed on the computer, other programmable apparatus or other devices to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide processes for implementing the functions/acts specified in the flowchart and/or block diagram block or blocks. As may be used herein, the term “coupled” includes both a direct electrical connection between blocks or components and an indirect electrical connection between blocks or components achieved using one or more intervening blocks or components.

Logical unit numbers (LUNs) exported from a port of a storage server may have to be remapped to another port for various reasons. As one example, when a storage administrator needs to take down a port of a target (e.g., a hard disk drive (HDD) array), all LUNs for the port that is to be taken down need to be exported to another port in the array. As another example, when one port is heavily loaded with I/O operations and other ports are relatively less loaded (which is possible in a storage area network (SAN) where storage is shared by multiple hosts, especially in a cluster environment), it may be desirable to remap at least some LUNS of the heavily loaded port to one or more of the other ports.

On the server (host) side, all modern OSs typically employ a multipath I/O (MPIO) solution to balance their I/O load equally on all available paths. As is known, MPIO is a fault-tolerant and performance enhancement technique that provides more than one physical path between a central processing unit (CPU) in a computer system and its mass storage devices through buses, controllers, switches, and bridge devices that connect the CPU to the mass storage devices. Even when an MPIO solution is implemented, it is possible that all or most of the paths utilized by a host are through a given storage port more frequently than other storage ports. In general, hosts are not aware of a load distribution on I/O ports of a target in a SAN and, as such, cannot make intelligent path selections as one host in a SAN is not aware of the I/O operations generated by other hosts to the target.

As such, a SAN administrator may be required to remap LUNs from time-to-time to balance I/O loads at ports of a SAN target. A storage administrator may also remap LUNs on a SAN when maintenance of the SAN is required. Conventionally, in-flight I/O operations on LUNs that are moved from one port to another port are adversely effected when maintenance activities interfere with ongoing application activity. In general, it is desirable to minimize disruption to applications that are using LUNs that are to be remapped. Typically, it is not feasible for a storage administrator to bring an application down or keep track of all I/O operations and trigger maintenance only when there are no active I/O operations to any LUNs of a SAN. Data integrity/reliability issues can occur if maintenance activities, such as dynamic LUN remapping, are initiated when there is a heavy I/O load on a LUN to be remapped.

Conventionally, an operating system (OS) fails an I/O operation when a port associated with a LUN is disconnected. In the event there are any pending I/Os in-flight, an associated application has retried all of the pending I/Os. It should be appreciated that retrying pending I/Os may adversely impact performance when there are a relatively large number of I/Os in-flight. Some conventional SANs provide an option of migrating a LUN. However, conventional LUN migration involves a block-by-block copy of data from a source LUN to a destination LUN, prior to changing LUN location information from the source to destination LUN. Using this conventional solution, a host I/O is not disrupted as a location of the LUN and a connection path (an initiator-target-LUN (ITL) nexus) are unchanged. However, using the conventional solution to address port unavailability is expensive and time consuming, as the conventional solution involves copying all LUN blocks on a block-by-block basis.

I/O virtualization is a methodology that is typically implemented to simplify management, lower costs, and improve performance of servers. I/O virtualization environments are created by abstracting upper layer protocols from physical connections. I/O virtualization enables one physical adapter card to appear as multiple virtual network interface cards (vNICs) and virtual host bus adapters (vHBAs). vNICs and vHBAs function as conventional NICs and HBAs and are designed to be compatible with existing OSs, hypervisors, and applications. To networking resources (e.g., LANs and SANs), the vNICs and vHBAs appear as normal cards and adapters. Virtual I/O provides a shared transport for all network and storage connections. Virtual I/O addresses performance bottlenecks by consolidating I/O to a single connection, whose bandwidth ideally exceeds the I/O capacity of an associated server (to ensure that an associated I/O link is not a bottleneck). Bandwidth is then dynamically allocated in real-time across multiple virtual connections to both storage and network resources. In I/O intensive applications, I/O virtualization can help increase both virtual machine (VM) performance and the number of VMs that may execute on a given server.

Storage virtualization refers to the process of abstracting logical storage from physical storage. In general, physical storage resources are aggregated into storage pools, from which logical storage is created. Storage virtualization presents a logical space for data storage and transparently handles the process of mapping the logical space to the actual physical location. Storage virtualization is typically implemented in modern HDD arrays using vendor proprietary solutions. However, the goal of storage virtualization is usually to virtualize multiple disk arrays from different vendors, scattered over a network, into a single monolithic storage device, which can be managed uniformly.

File systems, which are the most common means of accessing disk storage, are abstractions of a physical storage object (e.g., rotating magnetic media, solid-state electronic devices, directory structured magnetic tapes) into a more human friendly format, where data can be organized into files, folders and other similar objects. Many modern OSs, including those derived from the UNIX or Windows OSs, abstract the final connection between the file system into, for example, a device switch, a device array, or a device control block. Each physical device, as well as each type of physical device (which may also include network connected storage, virtualized disk storage, etc.) has a different handle, identifier, or other type of object. These data structures or objects include the information needed by the OS or disk I/O subsystem to convert requests for disk I/O into actual data transfer (i.e., either reading or writing).

Remapping a logical unit number (LUN) to a different port of a SAN, according to the present disclosure, provides a less expensive and time consuming option than conventional LUN migration. According to the present disclosure, dynamically remapping a LUN on a target (e.g., HDD array) from an old storage port to a new storage port (on the same SAN target) advantageously minimizes disruption of application input/output (I/O) operations, as the application I/Os are seamlessly routed to the new storage port. In general, the existing problem of application I/O operation disruption due to dynamic LUN remapping can be mitigated without breaking a communication path between a host and a SAN.

With reference toFIG. 1, an example data processing environment100is illustrated that includes a client110and a client130that may be in communication with various file servers and web page servers, via an Internet/Intranet122. Clients110and130may take various forms, such as workstations, laptop computer systems, notebook computer systems, smart phones, web-enabled portable devices, or desktop computer systems. For example, client110may correspond to a desktop computer system of a computer system user and client130may correspond to a web-enabled device of another computer system user.

Client110includes a processor102(which may include one or more processor cores for executing program code) coupled to a data storage subsystem104, a display106(e.g., a cathode ray tube (CRT) or a liquid crystal display (LCD)), one or more input devices108(e.g., a mouse, keyboard, haptic device, and/or a touch screen), and an input/output adapter (IOA)109. IOA109supports communication of client110with one or more wired and/or wireless networks utilizing one or more communication protocols, such as 802.x, hypertext transfer protocol (HTTP), simple mail transfer protocol (SMTP), etc, and further facilitates communication between clients110and130. IOA109may be virtualized as: a Fibre Channel (FC) adapter, a small computer system interface (SCSI) adapter, or an InfiniBand (IB) adapter, among other adapters. Data storage subsystem104may include, for example, an application appropriate amount of volatile memory (e.g., dynamic random access memory (DRAM)), non-volatile memory (e.g., read-only memory (ROM) or static RAM), and/or non-volatile mass storage device, such as a magnetic or optical disk drive. Data storage subsystem104includes an operating system (OS)114for client110, as well as application programs, such as a browser112(which may optionally include customized plug-ins to support various client applications), and application118(which may include an email application, a word processing application, a presentation application, a spreadsheet application, etc.).

Clients110and130are coupled via one or more wired or wireless networks, such as Internet/intranet122, to hosts134and/or136and respective virtualized I/O servers124and126. Hosts134and136may be coupled to optional storage manager128(which may be a SAN manager) via Internet/Intranet122. Virtualized I/O servers124and126provide respective access to data stored on HDD arrays115and125, which may each embody one or more targets. Hosts124and126may be physically located in, for example, a same room of a building, a different room of a building, a different building in a limited geographical area, or a different geographical area (e.g., different cites, counties, states, or countries).

It should be appreciated that hosts134and136may each implement a virtual machine manager (VMM) or hypervisor for controlling operation of the virtualized I/O servers (which may each utilize the same or a different OS), as well as a dynamic tracking application (not separately shown) that, when executed by hosts134and136, facilitates tracking LUNs that are moved between ports of a SAN target. While only two clients and two hosts (i.e., physical platforms) are shown associated with data processing environment100, it should be appreciated that more or less than two clients and more or less than two hosts may be implemented in a data processing environment configured according to the present disclosure. Host134and storage array115may be included within a SAN131. Similarly, host136and storage array125may be included within a different SAN133. Storage arrays115and125may each correspond to, for example, redundant array of inexpensive disks (RAID) arrays.

It should be appreciated that LUN remapping may occur in various scenarios. For example, when a target of a SAN has two ports and a storage administrator changes the cabling for one of the ports of the target, LUNs connected to the port for which the cabling is changed may be assigned to another port on the same target.

As is illustrated inFIG. 2, a SAN200includes a host204that is connected to a target206via a fabric202. SANs131and133ofFIG. 1may, for example, be configured in a manner similar to SAN200. In SAN200, a host bus adapter (HBA) of host204employs a fibre channel (FC) connection to both storage ports (labeled ‘SP1’ and ‘SP2’) of target206. In a typical application, target206includes a HDD array, such as a RAID array that is configured to include one or more targets. In a typical embodiment, host204initiates a login process to storage ports (labeled ‘SP1’ and ‘SP2’) of target206and saves various information (i.e., a world wide node name (WWNN), a world wide port name (WWPN), etc.) related to target206obtained during the login process. For example, host204may be performing I/O operations with respect to LUN A, which is accessed via the SP1port of target206. InFIG. 2, an I/O path for the I/O operations from host206to LUN A may be represented by: host204→fabric202→SP1port of target206→LUN A.

As is illustrated inFIG. 3, LUNs A and B have been unmapped from the SP1port and dynamically remapped to the SP2port of target206by a storage administrator (e.g., using storage manager128ofFIG. 1). In this case, subsequent I/O operations to LUN A on the SP1port of target206fail with an invalid LUN error notification (e.g., a SCSI check condition, or an additional sense code (ASC)/additional sense code qualifier (ASCQ) (ASC/ASCQ) value of 08/04) as LUN A (as well as LUN B) has been remapped to the SP2port of target206. According to the present disclosure, in response to an I/O operation failure to the SP1port, host204will quiesce the failed I/O operation to LUN A on the SP1port and start a recovery process. For example, from the saved login information for each target port host204may compare a WWNN with the WWNN of the failed port (i.e., the SP1port). As any ports with a same WWNN belong to the same target (i.e., target206), host204will issue a query (e.g., Report LUNS) to obtain LUN identifiers (IDs) on all the matched target ports returned.

For each reported LUN, host204issues an inquiry (e.g., an SCSI INQUIRY) to obtain a device serial number for the reported LUNs. According to one or more aspects, host204then compares the device serial number of LUN A with that of the reported LUNs. In response to a match between a device serial number of a reported LUN and the device serial number for LUN A, host204determines that a storage port associated with the matched LUN is the new owner of the remapped LUN A. In this case, host204then routes the subsequent I/O operations to LUN A via the target port identified (i.e., the SP2port). Host204then updates its configuration information. In this case, future communications between host204and LUN A use the new target port (i.e., host204→fabric202→SP2port of target206→LUN A).

With reference toFIG. 4, a flowchart of an example administrative process400for unmapping LUNs from an old port and remapping the ummapped LUNs to a new port on a same target is illustrated according to one aspect of the present disclosure. Process400is initiated in block402in response to, for example, a storage administrator initiating execution of a mapping routine on storage manager128ofFIG. 1. Next, in block404, the storage administrator selects to unmap one or more LUNs from a port of a target. For example, the storage administrator may choose to unmap LUNs A and B from the SP1port of target206. Next, in block406, the storage administrator selects to remap one or more LUNs to another port of target206. For example, the storage administrator may choose to remap LUNs A and B from the SP1port of target206to the SP2port of target206.

With reference toFIG. 5, a process500for dynamically tracking logical unit numbers (LUNs) between input/output (I/O) ports of a storage area network (SAN) target, according to an embodiment of the present disclosure, is illustrated. For better understanding, process500is discussed in conjunction withFIGS. 2 and 3. Process500is initiated (e.g., in response to host204executing an I/O operation to a logical unit number (LUN), such as LUN A, in block502, at which point control transfers to decision block504. In block504, host204detects whether an I/O operation failure has occurred in response to the I/O operation to the LUN. For example, when the I/O operation is directed to LUN A (seeFIG. 2) via storage port SP1of target206, which may be a hard disk drive (HDD) array, a failure will occur when LUN A has been remapped to a different storage port.

In response to host204not detecting an I/O operation failure in block504, control transfers to block526, where process500terminates until a next I/O operation is initiated by host204. In response to host204detecting an I/O operation failure in block504, control transfers to block506. For example, host204may detect an I/O operation failure to LUN A when a storage administrator has remapped LUN A to storage port SP2of target206and disconnected a cable between port P1of fabric202and storage port SP1of target206(seeFIG. 3).

In block506, host204determines a first identifier (e.g., a world wide node name (WWNN)) for the SP1port of target206. For example, from the saved login information for each target port host204may determine the WWNN of the failed port (i.e., the SP1port). Next, in decision block508host204determines whether a target has been found with the WWNN of the failed port. In response to a target not being found in block508, control transfers to block524where host204reports an error to the storage administrator, e.g., via storage manager128(seeFIG. 1). Following block524, control transfers to block526. In response to a target being found in block508, control transfers to block510where host204issues a report LUN query to target ports with the first identifier (i.e., the SP1and SP2ports of target206, as ports on a same target have a same WWNN). That is, as any ports with a same WWNN belong to the same target (i.e., target206), host204will issue a query (e.g., Report LUNS) to obtain LUN identifiers (IDs) on all the matched target ports returned.

Then, in decision block512, host204determines whether a response to the report LUN query has been received (e.g., within a predetermined time). As the SP1port of target206is not connected to fabric202, no response is received from LUNs associated with the SP1port. In response to not receiving a response to the LUN query in block512, control transfers to block524, where host204reports an error to the storage administrator, e.g., via storage manager128(seeFIG. 1). Following block524, control transfers to block526. In response to receiving a response to the LUN query in block512from LUNs associated with the SP2port of target206, control transfers to block514, where host204issues a device serial number inquiry to each LUN.

Then, in decision block516, host204determines whether a response to the device serial number inquiry has been received. Control loops on block516until a response to the device serial number inquiry is received. In response to a response being received by host204in block516, control transfers to block518. In block518host204receives the device serial numbers for LUNs A-D. Next, in decision block520, host204compares a device serial number for LUN A to the received device serial numbers. In response to none of the received device serial numbers matching the device serial number for LUN A, control transfers to block524where host204reports an error. In response to one of the received device serial numbers matching the device serial number for LUN A in block520, control transfers to block522. In block522host204routes subsequent I/O operations for LUN A to the SP2port of target206. Following block522control transfers to block526.

Accordingly, techniques have been disclosed herein that dynamically tracking logical unit numbers between input/output ports of a storage area network target.