Dynamic Storage Tiering (DST) is a concept of grouping storage devices into tiers based on their performance characteristics and relocating data dynamically across the devices to leverage their specific capabilities. It is desirable that a DST system perform this relocation while data remains online and accessible.
For performance management, data that has a high activity or load level may be relocated it to high performing storage tiers. Alternately, data with a low activity level may be relocated to lower performing storage tiers in order to provide increased capacity in high-performance storage tiers.
The present disclosure describes systems and methods for dynamic storage tiering
A method for dynamic storage tiering may comprise: creating a point-in-time copy of a virtual volume including a storage hot-spot; copying a virtual volume segment including the hot-spot from a first storage pool to a second storage pool; and reconfiguring a logical block address mapping of the virtual volume to reference the virtual volume segment copy in the second storage pool.
A system for dynamic storage tiering may comprise: means for creating a point-in-time copy of a virtual volume including a storage hot-spot; means for copying a virtual volume segment including the hot-spot from a first storage pool to a second storage pool; and means for reconfiguring a logical block address mapping of the virtual volume to reference the virtual volume segment copy in the second storage pool
The numerous advantages of the disclosure may be better understood by those skilled in the art by reference to the accompanying figures in which:
In the following detailed description, reference may be made to the accompanying drawings, which form a part hereof. In the drawings, similar symbols typically identify similar components, unless context dictates otherwise. The illustrative embodiments described in the detailed description, drawings, and claims may be not meant to be limiting. Other embodiments may be utilized, and other changes may be made, without departing from the spirit or scope of the subject matter presented here.
Referring to
Referring to
In order to enhance overall system performance, it may be desirable to allocate data having a high activity level (e.g. high numbers of I/O requests are addressed to the data) to high performance storage pools while also allocating data with a low activity levels to low performance storage pools. To affect an efficient DST solution, the size of the data blocks moved between storage pools may be smaller than a complete SCSI logical unit (LU).
For a given LU, data with a high activity level may be identified as a logical block address (LBA) range within an LU. Such an LBA range with significant activity load compared to the rest of the LU may be referred to as a hot-spot. A LU may contain more than one hot-spot.
A storage pool in which hot-spot currently exists may be referred to as a source storage pool. A storage pool that a hot-spot may be moved to may be referred to as a destination storage pool. It should be noted that hot-spots may refer data which is accessed frequently and may be moved to a higher-performance storage pool. Alternately, data which is accessed infrequently may be referred to as a cold-spot and may be moved to a lower-performance storage pool utilizing the same systems and methods as described herein with respect to hot-spot movement.
A hot-spot may be identified by the RAID controller 102 by monitoring the address locations for I/O requests received from the host 101. Upon exceeding a I/O request threshold (e.g. exceeding a specified request rate, number of requests, etc.), for a particular segment of LBAs in a given storage pool those LBAs may be designated as a hot-spot and subject to relocation to a storage pool having alternate performance characteristics.
Referring to
Referring to
The mass storage system 100 may further implement snapshot functionality. Snapshot functionality allows for the creation and storage of one or more point-in-time (PiT) copies of a virtual volume (e.g. virtual volume 106A). When a PiT is created for a virtual volume, the contents of the virtual volume may frozen and a PiT Temporary Virtual Volume (PTVV) may be created that records all changes made to the virtual volume after the PiT was taken. Consequently, the original contents of the virtual volume are preserved at the time the PiT was created. Such a snapshot mechanism may be referred to as allocate-on-write or redirect-on-write (collectively “allocate-on-write”) snapshots. Further, subsequent PiTs may be created for a given PTVV where a current PTVV is frozen and a new PTVV is created.
Referring to
Subsequently, a second PiT (e.g. PiT2) may occur which may freeze the contents of PTVV1 and a second PTVV (e.g. PTVV2) may be created. Following creation of the PTVV, write operations from the host to the virtual volume may be directed to the active PTVV (e.g. PTVV2). Read operations from the host to the virtual volume will be directed to the original virtual volume for data that is unmodified since the first PiT (e.g. PiT1), to the first PTVV (e.g. PTVV1) for data which has been modified following the first PiT but prior to a second PiT (e.g. PiT2), and to the active PTVV (e.g. PTVV2) for data which has been modified following the second PiT.
Upon deletion of a PiT (e.g. Pit1), the original virtual volume (e.g. virtual volume 106) may be reconfigured such that the contents of the portions of the original volume which were addressed by write requests during the existence of the PiT are updated to correspond with the PTVV. For example, the LBAs of the virtual volume 106 which were addressed by write requests to during the existence of the PiT may be copied to the LBAs of the virtual volume 106.
Referring to
Referring to
Referring to
Referring to
It is believed that the present invention and many of its attendant advantages will be understood by the foregoing description. It may be also believed that it will be apparent that various changes may be made in the form, construction and arrangement of the components thereof without departing from the scope and spirit of the invention or without sacrificing all of its material advantages. The form herein before described being merely an explanatory embodiment thereof. It may be the intention of the following claims to encompass and include such changes.
The foregoing detailed description may include set forth various embodiments of the devices and/or processes via the use of block diagrams, flowcharts, and/or examples. Insofar as such block diagrams, flowcharts, and/or examples contain one or more functions and/or operations, it will be understood by those within the art that each function and/or operation within such block diagrams, flowcharts, or examples may be implemented, individually and/or collectively, by a wide range of hardware, software, firmware, or virtually any combination thereof. In one embodiment, several portions of the subject matter described herein may be implemented via Application Specific Integrated Circuits (ASICs), Field Programmable Gate Arrays (FPGAs), digital signal processors (DSPs), or other integrated formats. However, those skilled in the art will recognize that some aspects of the embodiments disclosed herein, in whole or in part, may be equivalently implemented in integrated circuits, as one or more computer programs running on one or more computers (e.g., as one or more programs running on one or more computer systems), as one or more programs running on one or more processors (e.g., as one or more programs running on one or more microprocessors), as firmware, or as virtually any combination thereof, and that designing the circuitry and/or writing the code for the software and or firmware would be well within the skill of one of skill in the art in light of this disclosure.
In addition, those skilled in the art will appreciate that the mechanisms of the subject matter described herein may be capable of being distributed as a program product in a variety of forms, and that an illustrative embodiment of the subject matter described herein applies regardless of the particular type of signal bearing medium used to actually carry out the distribution. Examples of a signal bearing medium include, but may be not limited to, the following: a recordable type medium such as a floppy disk, a hard disk drive, a Compact Disc (CD), a Digital Video Disk (DVD), a digital tape, a computer memory, etc.; and a transmission type medium such as a digital and/or an analog communication medium (e.g., a fiber optic cable, a waveguide, a wired communications link, a wireless communication link (e.g., transmitter, receiver, transmission logic, reception logic, etc.), etc.).
Those having skill in the art will recognize that the state of the art may include progressed to the point where there may be little distinction left between hardware, software, and/or firmware implementations of aspects of systems; the use of hardware, software, and/or firmware may be generally (but not always, in that in certain contexts the choice between hardware and software may become significant) a design choice representing cost vs. efficiency tradeoffs. Those having skill in the art will appreciate that there may be various vehicles by which processes and/or systems and/or other technologies described herein may be effected (e.g., hardware, software, and/or firmware), and that the preferred vehicle will vary with the context in which the processes and/or systems and/or other technologies may be deployed. For example, if an implementer determines that speed and accuracy may be paramount, the implementer may opt for a mainly hardware and/or firmware vehicle; alternatively, if flexibility may be paramount, the implementer may opt for a mainly software implementation; or, yet again alternatively, the implementer may opt for some combination of hardware, software, and/or firmware. Hence, there may be several possible vehicles by which the processes and/or devices and/or other technologies described herein may be effected, none of which may be inherently superior to the other in that any vehicle to be utilized may be a choice dependent upon the context in which the vehicle will be deployed and the specific concerns (e.g., speed, flexibility, or predictability) of the implementer, any of which may vary. Those skilled in the art will recognize that optical aspects of implementations will typically employ optically oriented hardware, software, and or firmware.
Filing Document | Filing Date | Country | Kind | 371c Date |
---|---|---|---|---|
PCT/US2009/001991 | 3/31/2009 | WO | 00 | 12/2/2010 |
Publishing Document | Publishing Date | Country | Kind |
---|---|---|---|
WO2010/085228 | 7/29/2010 | WO | A |
Number | Name | Date | Kind |
---|---|---|---|
6170037 | Blumenau | Jan 2001 | B1 |
6311252 | Raz | Oct 2001 | B1 |
7191304 | Cameron et al. | Mar 2007 | B1 |
7225211 | Colgrove et al. | May 2007 | B1 |
7334007 | Cabrera et al. | Feb 2008 | B2 |
7822939 | Veprinsky et al. | Oct 2010 | B1 |
8527720 | Jess | Sep 2013 | B2 |
20020133681 | McBrearty et al. | Sep 2002 | A1 |
20040123031 | Kiselev et al. | Jun 2004 | A1 |
20050169064 | Kiselev et al. | Aug 2005 | A1 |
20060010169 | Kitamura | Jan 2006 | A1 |
20080010284 | Beck | Jan 2008 | A1 |
20080162843 | Davis et al. | Jul 2008 | A1 |
20080189572 | McBride et al. | Aug 2008 | A1 |
20080195826 | Yamazaki et al. | Aug 2008 | A1 |
20110078398 | Jess | Mar 2011 | A1 |
20110283075 | Jess et al. | Nov 2011 | A1 |
20120047108 | Mandel et al. | Feb 2012 | A1 |
20120331261 | Farrell et al. | Dec 2012 | A1 |
20120331264 | Farrell et al. | Dec 2012 | A1 |
Number | Date | Country |
---|---|---|
1826662 | Aug 2007 | EP |
09-006678 | Jan 1997 | JP |
2001-093220 | Apr 2001 | JP |
2002-073383 | Mar 2002 | JP |
2005-85117 | Mar 2005 | JP |
2005-310159 | Apr 2005 | JP |
2007-79787 | Mar 2007 | JP |
2007-220112 | Aug 2007 | JP |
2008-197779 | Aug 2008 | JP |
WO2007009910 | Jan 2007 | WO |
Number | Date | Country | |
---|---|---|---|
20110078398 A1 | Mar 2011 | US |
Number | Date | Country | |
---|---|---|---|
61205810 | Jan 2009 | US |