|Publication number||US8046552 B2|
|Application number||US 12/242,087|
|Publication date||Oct 25, 2011|
|Filing date||Sep 30, 2008|
|Priority date||Jan 30, 2008|
|Also published as||US20100082920|
|Publication number||12242087, 242087, US 8046552 B2, US 8046552B2, US-B2-8046552, US8046552 B2, US8046552B2|
|Inventors||Susan L. Larson|
|Original Assignee||Hewlett-Packard Development Company, L.P.|
|Export Citation||BiBTeX, EndNote, RefMan|
|Patent Citations (17), Classifications (10), Legal Events (2)|
|External Links: USPTO, USPTO Assignment, Espacenet|
This Application claims the benefit of U.S. Provisional Application Ser. No. 61/024,560, filed Jan. 30, 2008, titled “Tracking Metadata Changes During Data Copy In A Storage System” which is hereby incorporated by reference herein as if reproduced in full below.
In some storage systems, data in a logical disk residing on a virtual disk array is stored and retrieved from physical disks within a disk array. Mapping information referred to as “metadata” is used to locate the stored data. This metadata can be kept in the disk array controller memory and/or on physical disks within the disk array.
When a logical disk is transferred from one disk array to another disk array, this metadata must also be copied so that the destination disk array can locate the stored data. During the transfer of a logical disk, it is preferable to allow continued host access to the stored data in that logical disk on the source array. However, continued access to the logical disk can cause changes in the source metadata. Problems arise if the source metadata is changed while this metadata is being copied since the destination disk array would not have an accurate copy of the metadata.
In order to guarantee that the metadata is identical on the source and destination disk arrays, some storage systems lock access to the data during an entire time that all of the metadata is being copied. During this time, host computers are denied access to the data during the copy. This process is effective in preventing changes to metadata being copied, but causes problems in applications running on the host computer. Commands can timeout and applications can appear to hang.
Exemplary embodiments are directed to methods, systems, and apparatus for tracking changes to data when ownership or control of the data is transferred from one storage device (such as a controller or disk array) to another storage device (such as another controller or disk array). Transfer of the data occurs without interrupting host access to logical disks associated with the data. When a logical disk is transferred from one storage location to another storage location, the mapping information (i.e., the metadata used to locate the stored data) is copied from the source disk array to a destination disk array. During the transfer of the logical disk, hosts and applications have continuous access to the stored data in the logical disk on the source array.
In order to guarantee that the metadata is identical on the source and destination arrays, exemplary embodiments use starting and ending fences and a bitmap to track changes to the metadata that occur while the transfer is in progress. This structure insures that changes in the source metadata also occur in the destination metadata. Further, the size of the bitmap is scaled to the size of available memory of the source storage device and limited by an amount of data being copied at one time from the source storage device to the destination storage device.
The host computers 102 (shown as host 1 to host N) are coupled to the array controllers 104 through one or more fabrics or networks 110, and the storage devices or arrays 103 are coupled to the storage devices 106 through one or more fabrics or networks 111. For instance, the hosts communicate with an array controller using a small computer system interface (SCSI) or other interface/commands over a fiber channel (FC). By way of example, networks 110 and 111 include one or more of the Ethernet, fibre channel (FC), serial attached SCSI (SAS), iSCSI, internet, local area network (LAN), wide area network (WAN), public and/or private networks, etc. Communications links 112 are shown in the figure to represent communication paths or couplings between the hosts, controllers, and storage devices.
In one exemplary embodiment, the array controller 104 and disk arrays 106 are network attached devices providing random access memory (RAM) and/or disk space (for storage and as virtual RAM) and/or some other form of storage such as magnetic memory (example, tapes), micromechanical systems (MEMS), or optical disks, to name a few examples. Typically, the array controller and disk arrays include larger amounts of RAM and/or disk space and one or more specialized devices, such as network disk drives or disk drive arrays, (example, redundant array of independent disks (RAID)), high speed tape, magnetic random access memory (MRAM) systems or other devices, and combinations thereof. In one exemplary embodiment, the array controller 104 and disk arrays 106 are memory nodes that include one or more servers.
The storage controller 104 manages various data storage and retrieval operations. Storage controller 104 receives I/O requests or commands from the host computers 102, such as data read requests, data write requests, maintenance requests, etc. Storage controller 104 handles the storage and retrieval of data on the multiple disk arrays 106 and disk groups. In one exemplary embodiment, storage controller 104 is a separate device or may be part of a computer system, such as a server. Additionally, the storage controller 104 may be located with, proximate, or a great geographical distance from the disk arrays 106 or from each other.
The array controller 104 includes numerous electronic devices, circuit boards, electronic components, etc. By way of example, the array controller 104 includes firmware 120, an input/output (I/O) scheduler 122, a buffer or queue 124 (for example, used to temporarily store the metadata structures during ownership transfer), one or more interfaces 126, one or more processors 128 (shown by way of example as a CPU, central processing unit), and memory 130 (including read and write cache). CPU 128 performs operations and tasks necessary to manage the various data storage and data retrieval requests received from host computers 102. For instance, processor 128 is coupled to a host interface 126A that provides bidirectional data/communications to one or more host computers 102. Processor 128 is also coupled to an array interface 126B that provides bidirectional data communications to the disk arrays 106.
Memory 130 is also coupled to processor 128 and stores various information used by processor when carrying out its tasks. By way of example, memory 130 includes one or more of volatile memory, non-volatile memory, or a combination of volatile and non-volatile memory. The memory 130, for example, stores applications, data, control programs, algorithms (including software to implement or assist in implementing embodiments in accordance with the present invention), and other data associated with the storage device (example, state data such as mapping metadata, configuration metadata, and cached user data). The processor 128 communicates with memory 130, interfaces 126, and the other components via one or more buses 132.
In at least one embodiment, the storage devices are fault tolerant by using existing replication, disk logging, and disk imaging systems and other methods including, but not limited to, one or more levels of redundant array of inexpensive disks (RAID). Replication provides high availability when one or more of the disk arrays crash or otherwise fail. Further, in one exemplary embodiment, the storage devices provide memory in the form of a disk or array of disks where data items to be addressed are accessed as individual blocks stored in disks (example, 512, 1024, 4096, etc . . . bytes each) or stripe fragments (4K, 16K, 32K, etc . . . each).
In one exemplary embodiment, the I/O scheduler manages and schedules processor time for performing I/O requests. The scheduler balances loads and prevents any one process from monopolizing resources while other processes starve for such resources. The scheduler further performs such functions as deciding which jobs (example, I/O requests) are to be admitted to a ready queue, deciding a number or amount of processes to concurrently execute, determining how performance (example, bandwidth or I/Os per second) is divided among plural initiators (example, applications) so each initiator receives optimal performance.
In one embodiment the storage devices 103A, 103B are disk arrays. Each disk array can have one or more controllers. For instance, an array has two controllers for redundancy. Further, the storage devices include both production disks and backup disks as discussed herein.
In one embodiment, storage devices 103A, 103B are physically located in a same data center. In another embodiment, the storage devices are located a great geographical distance apart in separate data centers. Further, although only two storage devices are shown, a SAN can include hundreds or thousands of such storage devices.
According to block 210, the source disk array receives a request or command to transfer ownership or control of data from a source controller or disk array to a destination controller or disk array.
In one exemplary embodiment, the data in a logical disk residing on a virtual disk is stored and retrieved from a storage device, such as a physical disk. Metadata is used to locate and manage the stored data on the physical storage devices. For example, when a logical disk is transferred from one disk array to another disk array, the source disk array controlling the data transfers ownership to the destination disk array. During this transfer, the metadata associated with the logical disk is transferred from the source disk array to the destination disk array. The actual data residing in the physical disks is not moved. Instead, only the metadata associated with this data is moved or transferred. The metadata is transferred so the destination disk array can locate and manage the data on the physical storage devices.
According to block 220, a bitmap is created. In one embodiment, the bitmap is created by the source controller or disk array and is used to track changes to the metadata while a copy of the metadata is being transferred from the source disk array to the destination disk array. The size of the bitmap is scaled to the size of the available memory or memory actually being used in the source controller or disk array for the transfer. The bitmap can also be sized to allow several bitmaps to reside in memory simultaneously so several data copy operations occur in parallel. In one embodiment, a size of the bitmap is limited by the amount of data to be copied at one time. This size of the bitmap is thus based on, proportional to, or calculated from the size of the memory being used to transfer the metadata.
According to block 230, the metadata is copied to a buffer or other memory in the source controller or disk array. Chunks of metadata or metadata structures are then transferred from the source controller or disk array to the destination controller or disk array according to block 240.
In one embodiment, the number of bits in the bitmap is an even multiple of the number of metadata structures that can fit into a system data buffer. For example, if a system data buffer can hold 256 metadata structures, tracking changes to the metadata structures while they are buffered requires a 256 bit map or 32 bytes of memory. Thus, the size of the bitmap is an even multiple of 32 bytes depending on the number of system data buffers to be used for each copy operation.
Once the metadata temporarily stored in the buffer of the source controller or disk array is transferred, a determination is made as to whether more metadata needs to be transferred according to block 250. If the answer to this question is “yes” then more metadata associated with the data exists, and flow loops back to block 220. If the answer to this question is “no” then no more metadata associated with the data exists. Flow then proceeds to block 260. Here, the source controller or disk array transfers ownership and/or control of the data to the destination controller or disk array.
During the transfer of metadata, data to be copied is bounded with a start fence containing the starting address of the currently buffered data and an end fence containing the ending address of the currently buffered data. If changes are made to the original data between the start and end fences while the copy is in progress, the bit in the bitmap corresponding to the offset of the changed data from the start fence is set. After the copy of the data between the fences completes, the data corresponding to set bits in the bitmap is copied again.
Exemplary embodiments enable the simultaneous transfer of large groups of logical disks from one disk array to another disk array. The metadata associated with these logical disks is transferred without consuming or requiring large amounts of memory in the source controller. Disk array controllers typically have limited memory. Also, logical disk sizes are steadily increasing with each generation of disk arrays. The amount of memory in the bitmap required to track changes in the metadata for a group of disks is relatively small and will not exceed the amount of memory available in the disk array controller (for example, the size of a memory buffer allocated for storing chunks of metadata during the transfer).
One embodiment uses a bitmap and two fences to track changes in only the area of metadata currently being copied. The size of the area being copied is selected so that a bitmap to track changes will not over burden the available memory resources.
In one embodiment, the size of the bitmap is flexible and based on the size of the metadata currently being copied and not based on the size of the entire metadata data mapping. By way of illustration, assume that a single metadata structure tracks eight megabytes of disk space and that a single bit in the bitmap corresponds to one metadata structure. Also assume that a logical disk of two terabytes (2 TB) in size is being transferred from one disk array to another. With exemplary embodiments, a size of the bitmap is adjusted to the number of metadata structures currently being copied in a buffer of the controller. If a controller data buffer holds two hundred and fifty six (256) metadata structures, then the size of the bitmap is set at two hundred and fifty six (256) bits. So, the size of the bitmap corresponds with a buffer memory size being used to transfer chunks of metadata from one disk array to another disk array. The size of the bitmap is not required to be large enough to accommodate the entire metadata mapping structure. In other words, a bitmap of 32K would be needed to track changes to the entire metadata structure for a logical disk of up to the 2 TB in size. Exemplary embodiments, however, can track this 2 TB transfer by using a much smaller bitmap (for example, a 256 bit bitmap assuming the controller simultaneously buffers 256 metadata structures).
According to block 300, the bitmap is allocated and cleared. Then the start and end fences are set according to block 305. In one embodiment, the start fence is set to the starting index of the beginning of the portion of currently buffered metadata to be copied, and the end fence is set to the index of the end of the portion of currently buffered metadata to be copied.
According to block 310, appropriate flags are set. In one embodiment, a “copy in progress” flag is set for the affected logical disk. The “copy in progress” flag and a “duplicate metadata” flag are cleared by default when the logical disk is created.
According to block 315, metadata is copied from the start fence through the end fence in block 325. Flow then continues to block 390 in
A virtualization process also separately executes in parallel with the copying of metadata. This virtualization process commences at block 319 in
During normal ongoing array operations (block 319), if a metadata update is required a check or verification is made to determine if metadata changes should be duplicated to a copy by checking the “duplicate metadata” flag for the affected logical disk. If the “duplicate metadata” flag is set, then updates are applied to both the source and destination metadata.
If the answer to the question in block 330 is “no” then flow proceeds to block 340 where a determination is made as to whether a metadata copy is in progress for the affected logical disk. If the metadata copy is in progress, then flow proceeds to block 345 and updates are applied. In other words, if the “duplicate metadata” flag is not set, check the “copy in progress” flag to see if a metadata copy is in progress for the affected logical disk. If a metadata copy is in progress, then apply updates. In one exemplary embodiment, these updates include:
If the answer to the question in block 340 is “no” then flow proceeds to block 350, and metadata updates are only applied to the source metadata. In other words, if neither flag is set, apply the metadata updates only to the source metadata. Flow then proceeds to block 351 where the source metadata is unlocked.
According to block 355, the start fence is saved an updated. In one embodiment, after the copy started in block 315 completes, save the start fence off and then update the active start fence to the end fence+1. One embodiment updates the start fence at this point so that the bitmap does not change while it is being processed. Also, updates to this portion of the metadata can now be safely made to both the source and destination metadata at and below the end fence.
According to block 360, a determination is made as to whether a bit in the bitmap is set. If the answer to this question is “yes” then flow proceeds to block 365 and the metadata corresponding to the set bit is locked. The source metadata is then re-read according to block 370, and the destination metadata is re-written according to block 375. Once the metadata is written, the source metadata is unlocked according to block 380. According to block 382, a question is asked whether all set bits are processed. If the answer to this question is “no” then flow proceeds back to block 365. If the answer to this question is “yes” then flow proceeds to block 385 and the bitmap is cleared. Flow then proceeds to block 390.
By way of example, the bitmap is checked for set bits that indicate metadata changes during processing. Use the saved off start fence and the offset to the set bit from the beginning of the bitmap to find the metadata index of the updated metadata. Any metadata structures with a bit set in the bitmap are read again from the source copy and rewritten to the destination copy. The individual metadata structure in the source can be locked to guard against changes to the source metadata during this second copy to the destination. If so, the source metadata structure is unlocked as soon as the second copy completes.
If the answer to the question in block 360 is “no” then flow proceeds to block 390 where a determination is made as to whether more metadata needs to be copied. If the answer to this question is “yes” then flow proceeds to block 392. Here, the end fence is updated to the ending index of the next portion of metadata to be copied. Flow then continues back to block 315 in
If the answer to the question in block 390 is “no” then flow proceeds to block 394 where the flags are set and cleared. By way of example, after all of the metadata has been copied, set the “duplicate metadata” flag for the affected logical disk then clear the “copy in progress” flag. Finally, according to block 396, deallocate the bitmap.
Exemplary embodiments are easily portable to hardware platforms with varying amounts of memory and different system data buffer sizes. Exemplary methods can be used without modification for logical disks of any size. This will result in a development cost savings in an evolving product line. Allowing continuous access to data in logical disks while they are being transferred from one disk array to another will also result in greater customer satisfaction. Furthermore, tracking changes using the bit map allows bulk processing of the metadata structures during the copy operation without the need to lock the source metadata structures. The bulk copy makes the overall operation faster and more efficient than the prior single fence solution by amortizing the messaging overhead across the entire batch of metadata structures.
As used herein, the term “storage device” means any data storage device capable of storing data including, but not limited to, one or more of a disk array, a disk drive, a tape drive, optical drive, a SCSI device, or a fiber channel device. As used herein, a “disk array” or “array” is a storage system that includes plural disk drive, a cache, and controller. Arrays include, but are not limited to, networked attached storage (NAS) arrays, modular SAN arrays, monolithic SAN arrays, utility SAN arrays, and storage virtualization.
As used herein, a “virtual disk” is a virtual logical disk or volume to which a host or application performs input/output (I/O) operations. By way of example, vdisks are used in Fibre channel and SAN infrastructures. Disks are virtual due to the method by which they are mapped to the physical storage capacity. In some virtual storage systems, a meta-data mapping table translates an incoming (virtual) disk identifier and LBA (logical block addressing) to a physical disk identifier and LBA. The virtualization granularity depends on the implementation. Some virtualized systems provide disk aggregation and so the granularity is a physical disk itself. Other virtualization systems actually break down the physical disks into smaller chunks or extents. These latter systems spread a single virtual disk across many physical disks, obtain more concurrent access than a non-virtualized system, and provide a performance benefit.
As used herein, “metadata” is information or data about data. Metadata is data that describes characteristics of other data stored on a storage device and includes information that aids in identifying, discovering, assessing, and/or managing the other stored data.
As used herein, a “bitmap” is a data structure (such as an array data structure) that stores individual bits (Boolean values) as an array. For example, in a bitmap that stores kw bits, w is the number of bits in the unit of storage (such as a byte or word) and k is an integer.
In one exemplary embodiment, one or more blocks or steps discussed herein are automated. In other words, apparatus, systems, and methods occur automatically. As used herein, the terms “automated” or “automatically” (and like variations thereof) mean controlled operation of an apparatus, system, and/or process using computers and/or mechanical/electrical devices without the necessity of human intervention, observation, effort and/or decision.
The methods in accordance with exemplary embodiments of the present invention are provided as examples and should not be construed to limit other embodiments within the scope of the invention. For instance, blocks in diagrams or numbers (such as (1), (2), etc.) should not be construed as steps that must proceed in a particular order. Additional blocks/steps may be added, some blocks/steps removed, or the order of the blocks/steps altered and still be within the scope of the invention. Further, methods or steps discussed within different figures can be added to or exchanged with methods of steps in other figures. Further yet, specific numerical data values (such as specific quantities, numbers, categories, etc.) or other specific information should be interpreted as illustrative for discussing exemplary embodiments. Such specific information is not provided to limit the invention.
In the various embodiments in accordance with the present invention, embodiments are implemented as a method, system, and/or apparatus. As one example, exemplary embodiments and steps associated therewith are implemented as one or more computer software programs to implement the methods described herein. The software is implemented as one or more modules (also referred to as code subroutines, or “objects” in object-oriented programming). The location of the software will differ for the various alternative embodiments. The software programming code, for example, is accessed by a processor or processors of the computer or server from long-term storage media of some type, such as a CD-ROM drive or hard drive. The software programming code is embodied or stored on any of a variety of known media for use with a data processing system or in any memory device such as semiconductor, magnetic and optical devices, including a disk, hard drive, CD-ROM, ROM, etc. The code is distributed on such media, or is distributed to users from the memory or storage of one computer system over a network of some type to other computer systems for use by users of such other systems. Alternatively, the programming code is embodied in the memory and accessed by the processor using the bus. The techniques and methods for embodying software programming code in memory, on physical media, and/or distributing software code via networks are well known and will not be further discussed herein.
The above discussion is meant to be illustrative of the principles and various embodiments of the present invention. Numerous variations and modifications will become apparent to those skilled in the art once the above disclosure is fully appreciated. It is intended that the following claims be interpreted to embrace all such variations and modifications.
|Cited Patent||Filing date||Publication date||Applicant||Title|
|US6385626||Nov 19, 1998||May 7, 2002||Emc Corporation||Method and apparatus for identifying changes to a logical object based on changes to the logical object at physical level|
|US6460054||Dec 16, 1999||Oct 1, 2002||Adaptec, Inc.||System and method for data storage archive bit update after snapshot backup|
|US6516327||Sep 24, 1999||Feb 4, 2003||International Business Machines Corporation||System and method for synchronizing data in multiple databases|
|US6549921||Aug 1, 2000||Apr 15, 2003||Emc Corporation||Method and apparatus for performing point in time backup operation in a computer system|
|US6993530||Feb 28, 2003||Jan 31, 2006||Emc Corporation||Method and apparatus for obtaining an identifier for a logical unit of data in a database|
|US7103796||Sep 3, 2002||Sep 5, 2006||Veritas Operating Corporation||Parallel data change tracking for maintaining mirrored data consistency|
|US7133985||Sep 29, 2003||Nov 7, 2006||Emc Corporation||System and method for managing data associated with copying and replication procedures in a data storage environment|
|US7165155||Aug 29, 2003||Jan 16, 2007||Emc Corporation||System and method for tracking changes associated with incremental copying|
|US7225307||May 4, 2004||May 29, 2007||International Business Machines Corporation||Apparatus, system, and method for synchronizing an asynchronous mirror volume using a synchronous mirror volume|
|US7320100 *||May 19, 2004||Jan 15, 2008||Cray Inc.||Apparatus and method for memory with bit swapping on the fly and testing|
|US7395378 *||Jan 4, 2005||Jul 1, 2008||Symantec Operating Corporation||System and method for updating a copy-on-write snapshot based on a dirty region log|
|US20030177325||Mar 15, 2002||Sep 18, 2003||Joefon Jann||Method and structure for low memory relocation for dynamic memory reconfiguration|
|US20030182322 *||Mar 19, 2002||Sep 25, 2003||Manley Stephen L.||System and method for storage of snapshot metadata in a remote file|
|US20050091283 *||Nov 3, 2004||Apr 28, 2005||Microsoft Corporation||Meta data management for media content objects|
|US20050177692||Feb 5, 2004||Aug 11, 2005||Boyd Kenneth W.||Shared data mirroring apparatus, method, and system|
|US20070300025 *||Jun 27, 2006||Dec 27, 2007||Pavan Kumar Korlepara||Maintaining A Change Map Of A Block Level Storage Device|
|USRE37601||Nov 15, 1995||Mar 19, 2002||International Business Machines Corporation||Method and system for incremental time zero backup copying of data|
|U.S. Classification||711/162, 711/111, 711/156, 707/640, 711/165, 711/161|
|Cooperative Classification||G06F11/1662, G06F11/1466|
|Mar 25, 2015||FPAY||Fee payment|
Year of fee payment: 4
|Nov 9, 2015||AS||Assignment|
Owner name: HEWLETT PACKARD ENTERPRISE DEVELOPMENT LP, TEXAS
Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:HEWLETT-PACKARD DEVELOPMENT COMPANY, L.P.;REEL/FRAME:037079/0001
Effective date: 20151027