Patent Grant
10169948
The present invention relates generally to the field of storage systems and particularly, a system and methodology for satisfying storage system requests based on service levels.
Conventionally, a storage system receives requests to store, retrieve, and modify data from various sources. For example, a first device can request that a word processing file be stored on a storage system. A second device can request to read a previously stored web-formatted file, such as HTML, and display it on the requesting device's display. As devices that produce storage operation requests proliferate, sometimes with multiple requests originating from the same device, it is difficult to choose which request to satisfy. Prior solutions include satisfying the first request to be received by the storage system and subsequently creating a queue of incoming requests. Alternatively, the requests may be collected and sorted by a network router or gateway for prioritization before the storage system satisfies the storage operation request. These solutions however, incur processing and hardware overhead when managing the prioritization of the storage operation requests. There is a need to be able to differentiate and satisfy storage operation requests with a simple and efficient mechanism.
Embodiments of the present invention disclose a method, system and computer program product for prioritizing storage operation requests. The method includes at least one processor creating a storage operation request, such that the storage operation request may be originated by an initiator and transmitted to a target. Further, at least one processor identifies a priority value for the storage operation request, such that the priority value may be associated with a request of the initiator. Moreover, at least one processor receives the storage operation request at the target, such that the target selects at least one storage operation request from the storage operation requests based on a highest priority value. Subsequently, at least one processor of the target satisfies the storage operation request having the highest priority value.
Sometimes, storage operation requests from any device of a computing environment are numerous and frequent. In particular, if there is a high frequency need to store, retrieve, or modify data, then recipient storage systems have to easily and quickly decide in which order to satisfy storage operation requests, such as when two requests occur to retrieve identical data. The solution is to prioritize storage operation requests at the end device instead of any intermediary device or enabling a complex ordering algorithm. Specifically, there can exist defined service levels assigned to various users, applications, computing devices, or the like, that initiate storage operation requests. By creating service levels that can be quickly identified by the storage end device, such as a Hard Disk Drive (HDD), Solid-State Device (SSD), or the like, a high priority level identifier associated with one operation request can be quickly distinguished from a lower priority level identifier associated with a second storage operation request.
The storage on a cloud model consists of similar storage services which serve consumers of different needs. Some applications/users can afford longer service time than other applications/users. Differentiation in required service time allows price differentiation. The hereinafter described system and method will serve premium customers faster than it serves customers who paid less. Examples of some embodiments describing such differentiation in storage service time follows.
For example,
Unless otherwise specifically defined herein, all terms are to be given their broadest possible interpretation including meanings implied from the specification as well as meanings understood by those skilled in the art and/or as defined in dictionaries, treatises, etc. It must also be noted that, as used in the specification and the appended claims, the singular forms “a,” “an” and “the” include plural referents unless otherwise specified. It will be further understood that the terms “comprises” and/or “comprising,” when used in this specification, specify the presence of stated features, integers, steps, operations, elements, and/or components, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and/or groups thereof.
At a high level, the following description discloses several preferred embodiments of systems, methods and computer program products that identify a data storage device such as a disk, disks, or other storage media in a storage system that are deemed to handle at least one storage operation request. For simplicity if there are two storage operation requests, then the solution described herein can be used to distinguish which storage operation request to handle first. By default, even a single storage operation request can function within the contours of the hereafter described solution.
In one general embodiment, a method implemented by a computing device, such as a computer, includes communicating with a plurality of data storage end devices. Data is caused to be stored on first ones of the data storage end devices. A backup copy of the data may be stored/replicated on the first and/or on second ones of the data storage end devices. In another general embodiment, a system includes a manager configured to communicate with a plurality of data storage end devices. The manager includes hardware for communicating with the plurality of data storage end devices, and logic configured to perform various steps of the foregoing method. In another embodiment, a computer program product includes a computer readable storage medium having program code embodied therewith, the program code readable/executable by a processor to perform, by the processor, various steps of the foregoing method.
As will be appreciated by one skilled in the art, aspects of the present invention may be embodied as a system, method or computer program product. Accordingly, aspects of the present invention may take the form of an entirely hardware embodiment, an entirely software embodiment (including firmware, resident software, micro-code, etc.) or an embodiment combining software and hardware aspects that may all generally be referred to herein as “logic,” “circuit,” “module” or “system.” Further, aspects of the present invention may take the form of a computer program product embodied in one or more computer readable medium(s) having computer readable program code embodied thereon.
Any combination of one or more computer readable medium(s) may be utilized. The computer readable medium may be a computer readable signal medium or a computer readable storage medium. A computer readable storage medium may be, for example, but not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any suitable combination of the foregoing. More specific examples (a non-exhaustive list) of the computer readable storage medium would include the following: an electrical connection having one or more wires, a portable computer diskette, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or Flash memory), an optical fiber, a portable compact disc read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing. In the context of this document, a computer readable storage medium may be any tangible medium that can contain, or store a program for use by or in connection with an instruction execution system, apparatus, or device.
A computer readable signal medium may include a propagated data signal with computer readable program code embodied therein, for example, in baseband or as part of a carrier wave. Such a propagated signal may take any of a variety of forms, including, but not limited to, electro-magnetic, optical, or any suitable combination thereof. A computer readable signal medium may be any computer readable medium that is not a computer readable storage medium and that can communicate, propagate, or transport a program for use by or in connection with an instruction execution system, apparatus, or device.
Program code embodied on a computer readable medium may be transmitted using any appropriate medium, including but not limited to wireless, wired, optical fiber cable, RF, etc., or any suitable combination of the foregoing. Computer program code for carrying out operations for aspects of the present invention may be written in any combination of one or more programming languages, including an object oriented programming language such as Java, Smalltalk, C++ or the like, and conventional procedural programming languages, such as the “C” programming language or similar programming languages. The program code may execute entirely on the user's computer, partly on the user's computer, as a stand-alone software package, partly on the user's computer and partly on a remote computer or entirely on the remote computer or server. In the latter scenario, the remote computer may be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or the connection may be made to an external computer (for example, through the Internet using an Internet Service Provider).
Aspects of the present invention are described below with reference to flowchart illustrations and/or block diagrams of methods, apparatus (systems) and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and/or block diagrams, and combinations of blocks in the flowchart illustrations and/or block diagrams, can be implemented by computer program instructions. These computer program instructions may be provided to a processor of a general purpose computer, special purpose computer, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions/acts specified in the flowchart and/or block diagram block or blocks.
These computer program instructions may also be stored in a computer readable medium that can direct a computer, other programmable data processing apparatus, or other devices to function in a particular manner, such that the instructions stored in the computer readable medium produce an article of manufacture including instructions which implement the function/act specified in the flowchart and/or block diagram block or blocks.
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.
The flowchart and block diagrams in the Figures of this document illustrate the architecture, functionality, and operation of possible implementations of systems, methods and computer program products according to various embodiments of the present invention. In this regard, each block in the flowchart or block diagrams may represent a module, segment, or portion of code, which comprises one or more executable instructions for implementing the specified logical function(s). It should also be noted that, in some alternative implementations, the functions noted in the block may occur out of the order noted in the Figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. It will also be noted that each block of the block diagrams and/or flowchart illustration, and combinations of blocks in the block diagrams and/or flowchart illustration, can be implemented by special purpose hardware-based systems that perform the specified functions or acts, or combinations of special purpose hardware and computer instructions.
In use, the gateway 101 serves as an entrance point from the remote networks 102 to the proximate network 108. As such, the gateway 101 may function as a router, which is capable of directing a given packet of data that arrives at the gateway 101, and a switch, which furnishes the actual path in and out of the gateway 101 for a given packet.
Further included is at least one data server 114 coupled to the proximate network 108, and which is accessible from the remote networks 102 via the gateway 101. It should be noted that the data server(s) 114 may include any type of computing device/groupware. Coupled to each data server 114 is a plurality of user devices 116. Such user devices 116 may include a desktop computer, laptop computer, handheld computer, mobile computing device, printer or any other type of computing device. It should be noted that a user device 111 may also be directly coupled to any of the networks, in one embodiment.
A peripheral 120 or series of peripherals 120, e.g., facsimile machines, printers, networked and/or local storage units or systems, etc., may be coupled to one or more of the networks 104, 106, 108. It should be noted that databases and/or additional components may be utilized with, or integrated into, any type of network element coupled to the networks 104, 106, 108. In the context of the present description, a network element, may refer to any component of a network, such as a storage system, or storage array of a storage system.
According to some approaches, methods and systems described herein may be implemented with and/or on virtual systems and/or systems which emulate one or more other systems, such as a UNIX system, a *nix system, an IBM z/OS environment, a MICROSOFT WINDOWS environment, a MacOS environment, a mobile device OS environment, etc. This virtualization and/or emulation may be enhanced through the use of any hypervisor software, in some embodiments.
In more approaches, one or more networks 104, 106, 108, may represent a cluster of systems commonly referred to as a “cloud.” In cloud computing, shared resources, such as processing power, peripherals, software, data, servers, etc., are provided to any system in the cloud in an on-demand relationship, thereby allowing access and distribution of services across many computing systems. Cloud computing typically involves an Internet connection between the systems operating in the cloud, but other techniques of connecting the systems may also be used.
The device 200, which may be mobile or stationary, as shown in
The device 200 may have resident thereon an operating system such as the Microsoft Windows® Operating System (OS), a MAC OS, a UNIX OS, etc. It will be appreciated that a preferred embodiment may also be implemented on platforms and operating systems other than those mentioned. A preferred embodiment may be written using JAVA, XML, C, and/or C++ language, or other programming languages, along with an object oriented programming methodology. Object oriented programming (OOP), which has become increasingly used to develop complex applications, may be used.
The device 200 generates storage operation requests that are ultimately received and satisfied by a recipient storage end device (not shown). Specifically, a logical and/or physical hardware module of the device 200 can set and change a priority level of a storage operation request. For example, if a user of the device 200 is considered a premium user, instead of a non-premium user, wherein the premium user pays (monetarily, or some other valuation) for higher priority handling, then the premium user's storage operation requests are assigned higher priority values than a non-premium user's storage operation requests. This basic example of a service level includes a premium user being distinguished from a non-premium user. In other examples, service levels can include any number or defined categories that distinguish between users, groups, organizations, types of devices, types of communication paths, types of software applications, mobile apps, or the like.
It should be appreciated that priority values (or data attributes) can be binary, or a range of values, such as from 0 through 15, such as can be represented in hexadecimal notation, or some other valuation, such as 0 through 255, such as 8-bit ASCII code. Any coding is possible to represent a range of priority values where 0 can represent the low priority value with monotonically increasing values for higher priority values, or conversely, 15 can represent the low priority value with monotonically decreasing values for higher priority values.
Similar to providing higher priority values for storage operation requests, if the owner of a file or set of data blocks is a premium user, then a specific port of the communication adapter 234 to access the network 235 for transmitting the file or set of data blocks to the storage end device can be selected for higher priority transmission. For example, the port may have a higher bandwidth than other ports, and/or the port may have a direct communication path to the storage end device.
Another possibility is when an owner of a file, or set of data blocks is a premium user, then the user's files, or set of data blocks can be assigned higher priority than storage end device recovery operations that may be ongoing at the storage end device. Moreover, if the file or set of data blocks is an operating system file, then the file, or set of data blocks can be assigned a higher priority than all other users. Alternatively, even a premium user can obtain a higher priority value over a system file, depending on the critical importance of the system file during the continued operation of the device 200. Finally, any combination of the examples above can exist in an embodiment, such as for example, setting a higher priority value for being both a premium user whose file and port are selected according to a selected high priority value.
As described with respect to
The priority values 244 can be assigned to any range of values. For illustrative purposes, a metadata value can be defined as a “COMMAND— PRIORITY” priority value identifier having a range of hexadecimal values, “0h” to “fh” (where “fh” equals “15h”). This range of sixteen priority values can be assigned as “0h” meaning a storage operation request with either no priority or a storage operation request with a vendor-specific level of scheduling importance, such as IBM Tivoli Storage Manager (TSM) designating a particular file, or set of data blocks for handling. The next value, “1h” can mean a storage operation request with the highest scheduling importance. Thereafter, subsequent priority values from “2h” to “15h” indicate decreasing importance in priority values, with “15h” meaning the lowest priority value. It should be appreciated that the values can be stored in tabular form implemented in a database, and in any format, such as a flat-file, or hierarchical, depending on the resilience of the structure including the priority values 244. Further, the priority values 244 can reside in volatile and/or non-volatile memory, as needed.
Storage subsystem 380 comprises a clustered storage controller 334 coupled between the SAN 26 embodiment and a private network 346 using data connections 330 and 344, respectively, and incorporating adapters 332 and 342, again respectively. In some configurations, adapters 332 and 342 may comprise host bus adapters (HBAs). Clustered storage controller 334 implements clusters of storage modules 336, each of which includes an interface 338 (in communication between adapters 332 and 342), and a cache 340. Each storage module 336 is responsible for a number of storage end devices 350 by way of a data connection 348 as shown.
As described previously, each storage module 336 further comprises a given cache 340. However, it will be appreciated that the number of caches 340 used in storage subsystem 320 and in conjunction with clustered storage controller 334 may be any convenient number. While all caches 340 in storage subsystem 380 may operate in substantially the same manner and comprise substantially similar elements, this is not a requirement. Each of the caches 340 may be approximately equal in size and is assumed to be coupled, by way of example, in a one-to-one correspondence with a set of physical storage end devices 350, which may comprise disks, whether known as HDDs or SSDs. In one embodiment, physical storage devices may comprise such disks. Those skilled in the art will be able to adapt the description herein to caches of different sizes.
Each set of storage end devices 350 comprise multiple slow and/or fast access time mass storage devices, herein below assumed to be multiple hard disks or SSDs.
Each storage module 336 is operative to monitor its state, including the states of associated caches 340, and to transmit configuration information to other components of storage subsystem 380 for example, configuration changes that result in blocking intervals, or limit the rate at which I/O requests for the sets of physical storage are accepted.
Routing of commands and data from HBAs 328 to clustered storage controller 334 and to each cache 340 may be performed over a network and/or a switch. Herein, by way of example, HBAs 328 may be coupled to storage modules 336 by at least one switch (not shown) of SAN 326, which can be of any known type having a digital cross-connect function. Additionally or alternatively, HBAs 328 may be coupled to storage modules 336.
In some embodiments, data having contiguous logical addresses can be distributed among modules 336, and within the storage devices in each of the modules. Alternatively, the data can be distributed using other algorithms, e.g., byte or block interleaving. In general, this increases bandwidth, for instance, by allowing a volume in a SAN or a file in network attached storage to be read from or written to more than one given storage device 350 at a time. However, this technique requires coordination among the various storage devices, and in practice may require complex provisions for any failure of the storage devices, and a strategy for dealing with error checking information, e.g., a technique for storing parity information relating to distributed data. Indeed, when logical unit partitions are distributed in sufficiently small granularity, data associated with a single logical unit may span all of the storage devices 350.
While such hardware is not explicitly shown for purposes of illustrative simplicity, clustered storage controller 334 may be adapted for implementation in conjunction with certain hardware, such as a rack mount system, a midplane, and/or a backplane. Indeed, private network 346 in one embodiment may be implemented using a backplane. Additional hardware such as the aforementioned switches, processors, controllers, memory devices, and the like may also be incorporated into clustered storage controller 334 and elsewhere within storage subsystem 380, again as the skilled artisan will appreciate. Further, a variety of software components, operating systems, firmware, and the like may be integrated into one storage subsystem 380.
Storage devices 350 may comprise a combination of high capacity hard disk drives and solid state disk drives (SSDs). In some embodiments each of storage devices 350 may comprise a logical storage device. In storage systems implementing the Small Computer System Interface (SCSI) protocol, the logical storage devices may be referred to as logical units, or LUNs. While each LUN can be addressed as a single logical unit, the LUN may comprise a combination of high capacity hard disk drives and/or solid state disk drives.
Examples of adapters 332 and 342 include switched fabric adapters such as Fibre Channel (FC) adapters, Internet Small Computer System Interface (iSCSI) adapters, Fibre Channel over Ethernet (FCoE) adapters and Infiniband™ adapters. Such adapters 332 and 342 can be utilized to include logic to recognize prioritization values 244 from
The storage device 350 comprises a non-volatile storage media 366 and a controller software 368. Storage media 366 comprises non-volatile devices and/or materials configured to store data. Examples of storage media 366 include platters for a hard disk drive and non-volatile random access memory (NVRAM) modules for a solid state drive (SSD).
Controller 368 comprises a controller processor 370, a non-volatile memory 372 and a volatile memory 374. Controller processor 370 is configured to execute a controller application 376 from non-volatile memory 372 that enables module 336 to access (i.e., read/write) data on storage media 366 in order to process I/O requests received from module processor 360. In embodiments where storage device 350 comprises a hard disk, processor 370 executes controller application 376 to control motors (not shown) on the storage device, and to command disk heads (not shown) to read or write data.
In an embodiment, volatile memory 374 comprises a read command queue 378 and a write command queue 380. Upon receiving a read data request, controller processor 370 is configured to store the read data request to read command queue 378, and upon receiving a write data request, the controller processor is configured to store the write data request to write command queue 380. In operation, controller processor 370 is configured to retrieve read data requests from read command queue 378, retrieve the requested data from storage media 366, and convey the requested data to processor 360. Likewise, controller processor 370 is configured to retrieve write data requests from write command queue 380, store the write request data to storage media 366, and convey a write completion acknowledgement to processor 360.
Processor 360 and/or controller processor 370 can also be configured to perform the satisfaction of prioritized storage operation requests that have assigned priority values. Processors 360 and 370 typically comprise general-purpose central processing units (CPU), which are programmed in software to carry out the function of prioritizing storage operation requests by recognizing a priority value and appropriately queuing a storage operation request to an appropriate command queue, placing higher priority requests at the head of a queue.
The software may be downloaded to module 336, or controller 368 and module 336 in electronic form, over a network, for example, or it may be provided on non-transitory tangible media, such as optical, magnetic or electronic memory media. Alternatively, some or all of the functions of processors 360 and 370 may be carried out by dedicated or programmable digital hardware components, or using a combination of hardware and software elements.
Thereafter, in operation 440, the computing device communicates the requests to a storage subsystem, which is in communication with the storage device. When the storage device controller recognizes the assigned priority value, then in operation 450, the storage subsystem performs the storage device access request according to the assigned priority level. Accordingly, in the example of receiving a “1h” priority designation, the requests is queued for read or write ahead of other requests having lower priority values, such as “5h.” When identical priority levels are designated for some or all incoming requests to the storage subsystem, then the method may operate for example by having multiple priority queues with higher priority queues having precedence over lower priority queues. Of course, by default, one queue can operate in a similar way as long as the ordering of the requests can be made to the queue.
One of ordinary skill will also recognize that in one embodiment where all requests are assigned priority value “1h” the satisfaction of the storage operation requests operates on a first come first served behavior. Additionally, although the language of queues is used for examples, other implementations can include stacks, trees, or other abstract data type to organize data.
It will be appreciated that the embodiments described above are cited by way of example, and that the present invention is not limited to what has been particularly shown and described hereinabove. Rather, the scope of the present invention includes both combinations and sub-combinations of the various features described hereinabove, as well as variations and modifications thereof which would occur to persons skilled in the art upon reading the foregoing description and which are not disclosed in the prior art.
| Number | Name | Date | Kind |
|---|---|---|---|
| 6301639 | Cleavinger | Oct 2001 | B1 |
| 6587433 | Borella et al. | Jul 2003 | B1 |
| 6944128 | Nichols | Sep 2005 | B2 |
| 6944166 | Perinpanathan et al. | Sep 2005 | B1 |
| 7480754 | Priborsky | Jan 2009 | B2 |
| 7573819 | Krzanowski et al. | Aug 2009 | B2 |
| 8223642 | Curry et al. | Jul 2012 | B2 |
| 20030097443 | Gillett et al. | May 2003 | A1 |
| 20040039803 | Law | Feb 2004 | A1 |
| 20050076154 | Chambliss | Apr 2005 | A1 |
| 20080244590 | Chambliss | Oct 2008 | A1 |
| 20110246665 | Vange et al. | Oct 2011 | A1 |
| 20140129744 | Muppirala | May 2014 | A1 |
| Entry |
|---|
| Ghandeharizadeh, Shahram et al., “A Cost Driven Disk Scheduling Algorithm for Multimedia Object Retrieval,” IEEE Transactions on Multimedia, vol. 5.2, 2003, pp. 186-196. |
| Radhika, T. V. et al., “Resource Allocation Model for Efficient Management in Cloud Computing,” International Journal on Advanced Computer Theory and Engineering (IJACTE), vol. 2, Issue 4, 2013, pp. 63-71. |
| Number | Date | Country | |
|---|---|---|---|
| 20150220463 A1 | Aug 2015 | US |
