This document claims priority to Indian Patent Application No. 4308/CHE/2013 (filed on Sep. 23, 2013) entitled DYNAMIC STORAGE VOLUME CONFIGURATION BASED ON INPUT/OUTPUT REQUESTS, which is hereby incorporated by reference.
The invention generally relates to field of storage system optimization.
Storage systems create storage volumes from storage devices, such as the hard disk drives (HDDs) and solid-state drives (SSDs), to store and manage data. The storage systems process input/output (I/O) requests with one or more storage controllers to direct data to and from the storage volumes. The size and the configuration of the storage volumes are generally static, regardless of the type or size of the I/O request. Thus, there is no assurance where I/O requests are to be written. For example, in a server based storage system, the server may generate I/Os containing large chunks of continuous data as well as smaller/random “burst-like” I/Os. When the logical volumes are statically configured from SSDs and HDDs, the storage system endures latency because there is no way to distinguish between the faster albeit costlier SSDs from the higher density HDDs.
Systems and methods presented herein provide for optimizing storage space of logical volumes based on I/O requests. In one embodiment, a storage system includes a plurality HDDs and a plurality of SDDs and a storage controller operable to manage the HDDs and SDDs as a plurality of logical volumes, and categorize input/output requests to the logical volumes into types based on sizes of the input/output requests (e.g., smaller and larger). The storage controller is also operable to reconfigure the logical volumes from the HDDs and the SDDs based on the types of the input/output requests to the logical volumes. A first of the reconfigured logical volumes occupies a first portion of at least one of the SDDs and a first portion of at least one of the HDDs. The storage controller is further operable to direct the first type of the input/output requests to the first portion of the SDD occupied by the first reconfigured logical volume.
The various embodiments disclosed herein may be implemented in a variety of ways as a matter of design choice. For example, the embodiments may take the form of computer hardware, software, firmware, or combinations thereof. Other exemplary embodiments are described below.
Some embodiments of the present invention are now described, by way of example only, and with reference to the accompanying drawings. The same reference number represents the same element or the same type of element on all drawings.
The figures and the following description illustrate specific exemplary embodiments of the invention. It will thus be appreciated that those skilled in the art will be able to devise various arrangements that, although not explicitly described or shown herein, embody the principles of the invention and are included within the scope of the invention. Furthermore, any examples described herein are intended to aid in understanding the principles of the invention and are to be construed as being without limitation to such specifically recited examples and conditions. As a result, the invention is not limited to the specific embodiments or examples described below.
The controller 102 is any system, device, software, or combination thereof operable to process I/O requests to the drives 105 and 106 and dynamically optimize configurations of the logical volume 110 from various combinations of the drives 105 and 106 based on the I/O requests. The controller 102 may be configured within the host 101 (e.g., as a host bus adapter) or as a separate storage controller. The controller 102 may be used to also implement various forms of Redundant Array of Independent Disks (RAID) methodologies with the logical volume 110.
The storage system 100 may also include an interface 104 operable to communicatively couple the drives 105 and 106 to the controller 102. For example, the interface 104 may be a switched fabric, such as that found in a Serial Attached Small Computer System Interface (SAS) topology employing SAS expanders and other SAS and/or Peripheral Computer Interface (PCI) devices.
Although shown and described with respect to a certain number of SSDs 105, HDDs 106, and logical volumes 110, the invention is not intended to be limited to the exemplary drawing. Those skilled in the art would readily recognize that the storage system 100 may be configured in a variety of ways with a variety of different devices to implement the inventive concepts described herein. Discussion of the storage system 100 will now be directed to the flowchart 200 of
After processing multiple I/O requests to the logical volume 110, the controller reconfigures the logical volume 110 based on the types of the I/O requests to the logical volume 110, in the process element 203. That is, the controller 102 analyzes the I/O requests to the logical volume 110 occupying the HDDs 106-1 and 106-2 in this example. The controller 102 determines that some of the I/O requests (e.g., the smaller/random I/O requests) could be better handled by the SSDs 105. The controller 102 then reconfigures the logical volume 110 to occupy at least a portion of one or more of the SSDs 105 to accommodate those I/O requests, as shown by the SSD 105-3 in
In reconfiguring the logical volume 110, the controller 102 may analyze the storage space requirements for the logical volume 110 to determine how much storage space of the HDDs 106 is still required by the logical volume 110. Thus, the controller 102 may use some portion of the allocated storage space of the HDDs 106-1 and 106-2, as shown in this example in
With the logical volume 110 reconfigured, the controller 102 then directs the I/O requests to the logical volume 110 that are better suited for the SSDs 105 to the allocated space of the SSD 105-3 as illustrated in
After the logical volumes 110-1 and 110-2 are configured, the controller 102 manages the logical volumes 110-1 and 110-2 and processes I/O requests from the host 101 to the logical volumes 110-1 and 110-2. In processing I/O requests to the logical volumes 110-1 and 110-2, the controller 102 analyzes the types of I/O requests, the sizes of the I/O requests (e.g., the size of the data in the request), and/or frequencies of certain types of I/O requests. For example, the controller 102 may receive a write I/O request and extract the data associated with the I/O request and thus determine the size of the data to be stored in the logical volume 110-2. The controller 102 may then write the data of the I/O request to one or more of the HDDs of the HDD group 256-3 that make up the logical volume 110-2. Over time, the controller 102 compiles statistical information of the I/O requests to the logical volume 110-2 such that the controller 102 can optimize I/O requests to the logical volume 110-2 by dynamically allocating space on other drive groups 255 and 256.
In
Again, the invention is not intended to be limited to any particular type of logical volume optimization and/or creation. The embodiments presented herein reserve a total volume space from an available drive pool of HDDs and SSDs. Subsequently, in the context of an I/O, the controller 102 analyzes the I/O pattern and allocates blocks dynamically from the drive pool, either from HDDs/SSDs. In some instances, the controller 102 analyzes the incoming I/O requests to the logical volumes using statistical analysis and/or mathematical optimization techniques. In any case, the inventive concepts herein provide optimal I/O performance and deterministic latency for different I/O request types and provide dynamic allocation of storage space depending on the I/O requests.
Additionally, the dynamic allocation features herein pertaining to logical volumes can be flexibly configured such that the controller 102 can revert back to its original static logical volume configurations. For example, the controller 102 may retain a map of the data for previous logical volumes that were statically created. The controller 102 may compare the map for the static logical volumes to the reconfigured logical volumes to restore the logical volumes to their previous drive groups 255 and 256 upgraded with the newer data of the reconfigured logical volumes. Thus, the controller 102 can reconfigure a logical volume into a homogeneous array of HDDs and/or a homogeneous array SDDs after configuring the logical volume from a heterogeneous array of HDDs and SDDs.
The invention can take the form of an entirely hardware embodiment, an entirely software embodiment or an embodiment containing both hardware and software elements. In one embodiment, the invention is implemented in software, which includes but is not limited to firmware, resident software, microcode, etc.
Furthermore, the invention can take the form of a computer program product accessible from the computer readable medium 306 providing program code for use by or in connection with a computer or any instruction execution system. For the purposes of this description, the computer readable medium 306 can be any apparatus that can tangibly store the program for use by or in connection with the instruction execution system, apparatus, or device, including the computer system 300.
The medium 306 can be any tangible electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system (or apparatus or device). Examples of a computer readable medium 306 include a semiconductor or solid state memory, magnetic tape, a removable computer diskette, a random access memory (RAM), a read-only memory (ROM), a rigid magnetic disk and an optical disk. Current examples of optical disks include compact disk-read only memory (CD-ROM), compact disk-read/write (CD-R/W) and DVD.
The computing system 300, being suitable for storing and/or executing program code, can include one or more processors 302 coupled directly or indirectly to memory 308 through a system bus 310. The memory 308 can include local memory employed during actual execution of the program code, bulk storage, and cache memories which provide temporary storage of at least some program code in order to reduce the number of times code is retrieved from bulk storage during execution. I/O devices 304 (including but not limited to keyboards, displays, pointing devices, etc.) can be coupled to the system either directly or through intervening I/O controllers. Network adapters may also be coupled to the system to enable the computing system 300 to become coupled to other data processing systems, such as through host systems interfaces 312, or remote printers or storage devices through intervening private or public networks. Modems, cable modem and Ethernet cards are just a few of the currently available types of network adapters.
| Number | Date | Country | Kind |
|---|---|---|---|
| 4308/CHE/2013 | Sep 2013 | IN | national |