Patent Publication Number: US-8972613-B2

Title: System and method for increasing input/output throughput in a data storage system

Description:
BACKGROUND 
     This section is intended to introduce the reader to various aspects of art, which may be related to various aspects of the present invention that are described and claimed below. This discussion is believed to be helpful in providing the reader with background information to facilitate a better understanding of the various aspects of the present invention. Accordingly, it should be understood that these statements are to be read in this light, and not as admissions of prior art. 
     Computer usage has increased dramatically over the past few decades. With the advent of standardized architectures and operating systems, computers have become virtually indispensable for a wide variety of uses from business applications to home computers. In fact, for some businesses, a loss of computer data can result in severe financial penalties for the business (e.g., loss of customers, bad publicity, and so-forth). 
     For this reason, many businesses now employ data back-up or data protector systems to ensure that a hardware failure (e.g., a broken storage unit) does not result in lost data. One of these back-up systems is known as mirroring. In mirroring, also known as RAID 1, every bit of data is written to two separate and independent storage units. In this way, if one of the devices is damaged, no data is lost because identical data is stored on the “mirror” device. As can be appreciated, however input/output (“I/O”) throughput (e.g., retrieving and storing data) with two separate mirrored storage units can be slower than the I/O throughput with a single storage unit. 
     Improving the I/O throughput to a mirrored storage system would be desirable. 
    
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         FIG. 1  is a block diagram of an exemplary data storage system configured for increased I/O throughput in accordance with one embodiment of the present invention; and 
         FIG. 2  is a flowchart illustrating an exemplary technique for increasing I/O throughput in a data storage system in accordance with one embodiment of the present invention. 
     
    
    
     DETAILED DESCRIPTION 
     One or more specific embodiments of the present invention will be described below. In an effort to provide a concise description of these embodiments, not all features of an actual implementation are described in the specification. It should be appreciated that in the development of any such actual implementation, as in any engineering or design project, numerous implementation-specific decisions must be made to achieve the developers&#39; specific goals, such as compliance with system-related and business-related constraints, which may vary from one implementation to another. Moreover, it should be appreciated that such a development effort might be complex and time consuming, but would nevertheless be a routine undertaking of design, fabrication, and manufacture for those of ordinary skill having the benefit of this disclosure. 
     As described above, mirrored back-up system may store data in two locations: a primary storage location (such as a storage unit) and a back-up (or mirror) storage location. Many of these mirrored back-up systems, however, only read data from the primary storage location unless there is a problem with the primary storage location and the back-up storage location is needed. In one embodiment of this type of back-up system, a plurality of storage location may be subdivided amongst two storage unit controllers (referred to in  FIG. 1  as controller A and controller B). Typically, in this configuration, each storage location is assigned to one or the storage unit controllers has a corresponding storage location (its mirror) assigned to the other controller. 
     However, because only the primary storage locations are typically read, in one embodiment, the primary storage locations may be balanced between the two controllers with one of the controllers having roughly half of the primary storage location, while the other controller has roughly the other half of the primary storages location. In this way, read transactions may be split between the two storage unit controllers. It will be appreciated that the primary/back-up distinction is not as significant for write transactions, because, unlike read transactions, write transactions are performed on both the primary storage location and its mirror. Moreover, it will be appreciated that in other embodiments, the primary storage location may be split using other techniques or may be assigned to a single controller. 
     One type of storage system that may operate as described above is known as an asymmetric active/active storage system. In a conventional asymmetric active/active storage system, a host computer (such as host computer  12  illustrated in  FIG. 1 ) is configured to ignore the distinction between primary and mirrored storage location and to send both read and write transactions to either controller based on an appropriate load balancing scheme (I/O response time, shortest queue depth, round robin, and so-forth). If the transaction is a write transaction, the receiving controller would execute the write transaction and then transmit the write transaction to the other controller to also perform the write transaction. If, however, the transaction is a read transaction, the controller receiving the transaction would first determine whether the read transaction involved one of its primary storage locations. If the transaction does involve one of that controller&#39;s primary storage locations, the controller would execute the read transaction. If the transaction does not involve one of that controller&#39;s primary storage locations, the controller would transmit the read transaction to the other controller for execution. This retransmission may be referred to as a “proxy read.” 
     As can be appreciated, a significant percentage of the time, the load balancing scheme of the host computer will not direct read transactions to the correct controller (known as the owning controller of the primary storage unit or as the “optimized” path in SCSI-based systems) and extra cycle time may be lost transmitting the read transaction to the other controller. For example, proxy reads may generate system demerits. Accordingly, one or more of the embodiments described herein may be directed towards a system or method for determining the owning controller associated with a particular read transaction and directing that read transaction to the owning controller. 
     Turning now to the drawings and looking first at  FIG. 1 , a block diagram of an exemplary data storage system configured to increase I/O throughput in accordance with one embodiment is illustrated and generally designated by reference numeral  10 . In one embodiment, the storage system  10  may include a modified version of the Enterprise Virtual Array (“EVA”) system produced by Hewlett-Packard Company. In another embodiment, the storage system  10  may include a modified version of the Modular Smart Array (“MSA”) system produced by Hewlett-Packard Company. In still other embodiments, other suitable storage systems may be employed. 
     As illustrated in  FIG. 1 , the storage system  10  may include the host computer  12 . The host computer  12  may be any one of a number of suitable personal or business computers. For example, in various embodiments, the host computer  12  may include a PC, a Macintosh compatible computer, a Unix machine, and so-forth. 
     The host computer  12  may be coupled to a dispatcher  14 . As will be described in further detail below, the dispatcher  14  may be configured to determine an owning controller associated with a particular read transaction and to direct that read transaction to the associated owning controller. In one embodiment, the host computer  12  may include the dispatcher  14 . However, in alternate embodiments, the dispatcher  14  may be external to the host computer  12 . 
     As shown in  FIG. 1 , the dispatcher  14  may be coupled to one or more channels  16   a ,  16   b ,  16   c , and  16   d  (hereafter referred to as “ 16   a - d ”). The channels  16   a - d  may include any suitable form of computer or electronic interconnect. For example, in one embodiment, the channel  16   a - d  may be Fibre channels. In alternate embodiments, however, the channels  16   a - d  may include a Peripheral Component Interface (“PCI”) bus, a Small Computer Systems Interface (“SCSI”) bus, an Ethernet or gigabit Ethernet connection, or other suitable interconnect technology. 
     The channels  16   a - d  may be connected to ports  18   a ,  18   b ,  18   c , and  18   d  (hereafter referred to as “ 18   a - d ”) respectively. The ports  18   a - d  may be configured to receive and relay data received from the channels  16   a - d  into controller  20   a  and  20   b . As such, the ports  18   a - d  are compatible with the channels  16   a - d . For example, if the channels  16   a - d  are Fibre channels, the ports  18   a - d  may comprise Fibre ports. 
     As shown, the ports  18   a - d  may be coupled to or integrated into storage unit controllers  20   a  and  20   b  (illustrated in  FIG. 1  as controller A and controller B, respectively). In particular, ports  18   a  and  18   b  may be coupled to controller A and ports  18   c  and  18   d  may be coupled to controller B. As will be appreciated, the controllers  20   a  and  20   b  may be configured to control the flow of data to and from a plurality of storage units. For example, in the embodiment illustrated in  FIG. 1 , the controller  20   a  may be configured to control storage units  22   a ,  22   b ,  22   c ,  22   d ,  22   e , and  22   f  (hereafter referred to as “ 22   a - f ”). Similarly, the controller  20   b  may be configured to control storage units  24   a ,  24   b ,  24   c ,  24   d ,  24   e , and  24   f  (hereafter referred to as “ 24   a - f ”). Although each of the controllers  20   a  and  20   b  are illustrated in  FIG. 1  as controlling six storage units  22  and  24 , it will be appreciated, as indicated by the ellipsis in  FIG. 1 , that any suitable number of storage units  22  and  24  may be employed. For example, in one embodiment, the controllers  20   a  and  20   b  may each control a single storage unit  22  and  24  or in other embodiments, the controllers  20   a  and  20   b  may control ten or more storage units  22  and  24 . 
     Although not illustrated in  FIG. 1 , those of ordinary skill in the art will appreciate that each of the controllers  20   a  and  20   b  may include one or more processors, cache, memory, and/or other appropriate hardware, firmware, or software appropriate for controller the storage units  22  and  24 . For example, in one embodiment, the controllers  20   a  and  20   b  may be EVA Hierarchical Storage Virtual Controllers Model 210 produced by Hewlett Packard Company. In alternate embodiments, however, other suitable controllers  20   a  and  20   b  may be employed in the system  10 . 
     In addition, the controllers  20   a  and  20   b  may also include mirror ports  26   a  and  26   b , respectively. As described above, the controllers  20   a  and  20   b  may be configured to transmit write instructions between each other to enable write transactions to be performed on both a primary storage unit and its mirror storage unit. Accordingly, controllers  20   a  and  20   b  may include the ports  26   a  and  26   b  as well as mirror connection  28  to enable this inter-controller communication. In one embodiment, the ports  26   a  and  26   b  may be similar to the ports  18   a - d  and the mirror connection  28  may be similar to the channels  16   a - d . However, in alternate embodiments, other suitable port types and/or interconnect types, as described above with regard to the channels  16   a - d  and the ports  18   a - d , may be employed to interconnect the controllers  20   a  and  20   b.    
     As described above, the controllers  20   a  and  20   b  may be coupled to one or more storage units  22   a - f  and  24   a - f . In various embodiments, the storage units  22   a - f  and  24   a - f  may include any one of a number of suitable data storage units. For example, in one embodiment, the storage units  22  and  24  may include hard drives or other magnetic storage devices. However, in alternate embodiments, the storage units  22  and  24  may include optical storage devices, solid state storage devices, such as memories, or other suitable types of data storage device. Moreover, it will be appreciated that the storage units  22   a - f  and  24   a - f  may be physical storage devices, logical storage units, or some combination thereof. More specifically, in one embodiment, one or more of the storage devices  22   a - f  and  24   a - f  may include logical storage units (“LUs”) or logical storage volumes partitioned from one or more physical hard disk devices. For example, in one embodiment, the storage units  22  and  24  illustrated in  FIG. 1  may represent a logical view of individual ports on a physical disk drive. More specifically, in this embodiment, storage units  24   a  and  24   b  may be two ports on the same physical storage device. 
     As described above, the storage system  10  may be configured to determine an owning controller associated with a particular read transaction and then to direct that read transaction to the owning controller. Accordingly,  FIG. 2  is a flowchart illustrating an exemplary technique  40  for increasing I/O throughput in a data storage unit by directing read transactions to the appropriate owning controller. In one embodiment, the technique  40  may be executed by the dispatcher  14  within the storage system  10 . 
     As illustrated by block  41  of  FIG. 2 , the technique  40  may begin by determining the owning controller for each of the storage unit s  22   a - f  and  24   a - f  as indicated by block  48 . In one embodiment, determining the owning controller includes sending a REPORT TARGET PORT GROUPS SCSI command to each of the storage unit s  22   a - f  and  24   a - f  and/or along each of the channels  16   a - d.    
     Next, the technique  40  may include receiving a transaction for the storage system, as indicated by block  42 . This received transaction may be generated by the host computer  12 , by another computer coupled to the host computer  12 , and/or any other suitable source in communication with the controllers  20   a  and  20   b . After receiving a transaction for the storage system, the technique  40  may include determining whether the received transaction is a read transaction, as indicated by block  44 . If the transaction is not a read transaction (e.g., it is a write transaction), the dispatcher may send the transaction to either the controller  20   a  or  20   b  via any of the channels  16   a - d . In one embodiment, the dispatcher  14  determines the appropriate controller  20   a  and  20   b  and appropriate channel  16   a - d  using a load balancing algorithm, such as I/O response time, shortest queue depth, round robin, and the like. 
     If, on the other hand, the transaction is a read transaction, the technique  40  may include selecting a path to the owning controller, as indicated by block  48 . In one embodiment, selecting a path to the owning controller may comprise selecting one of a plurality of ports and/or channels to the owning controller. For example, if the owning controller were the controller  20   a , the dispatcher  14  may select between the channel  16   a  and  16   b  in determining a path to the controller  20   a , which is the owning controller. In one embodiment, the dispatcher  14  may be configured to select between one or more available ports using any one of a number of suitable load balancing algorithms, such as I/O response time, shortest queue depth, round robin, and the like. 
     After selecting a path to the owning controller, the technique  40  may include executing the received read transaction on the owning controller over the selected path. In this way, the technique  40  enables read transactions to be directly routed to the owning controller. Advantageously, such direct routing may decrease response time for read transactions to the storage system  10 , and, thus, increase the overall throughput of the storage system  10 . Moreover, the technique  40  may reduce inter-controller communication between the controllers  20   a  and  20   b  over the mirror connection  28 , which may also increase the I/O throughput of the storage system  10 . 
     While the invention described above may be susceptible to various modifications and alternative forms, specific embodiments have been shown by way of example in the drawings and have been described in detail herein. It should be understood, however, that the invention is not intended to be limited to the particular embodiments disclosed.