The present invention relates to the field of data storage and, more particularly, to data redundancy.
Remote mirroring is data redundancy technique for coping with failures. A copy of data, sometimes referred to as a ‘primary’ or ‘local’ copy, is updated, for example, by an application program. A redundant copy of the data, sometimes referred to as a ‘secondary’ or 'slave’ copy, usually at a remote site, is updated as well. When a failure occurs that renders the primary copy unusable or inaccessible, the data can be restored from the secondary copy, or accessed directly from there.
A conventional scheme for remote mirroring is synchronous mirroring. Synchronous mirroring is typically performed under control of the site of the primary copy. In response to a write operation initiated by an application program, the primary site writes the data to the primary copy and forwards the data to the site of the secondary copy. The secondary site stores the data and returns an acknowledgement to the primary site. The primary site awaits the acknowledgement from the secondary site before signaling the application that the write operation is complete and before processing a next write request. In this way, the write-ordering of transactions is preserved at both the primary and secondary sites and both sites have up-to-date copies of the data. A drawback to synchronous mirroring is reduced performance caused by delay in awaiting each acknowledgement from the secondary site.
Another scheme for remote mirroring is asynchronous mirroring. In accordance with asynchronous mirroring, the primary site continues to process a next write request without awaiting an acknowledgement from the secondary site. Asynchronous mirroring schemes typically require that the primary site maintain a record for data updates sent to the secondary site. However, data loss can occur in the event of a failure if write-ordering of transactions is not preserved at the secondary site or if the secondary copy is out-of-date.
The present invention provides a system for and method of retrieval-based data redundancy. In an embodiment, a method comprises: performing a first write operation on a data object at a first storage subsystem to form a first version of the data object, the data object being included among a plurality of data objects of primary data; sending an identification of the data object to a second storage subsystem; using the identification of the data object received by the second storage subsystem to retrieve the data object from the first storage subsystem; and applying the retrieved data object to secondary data at the secondary storage subsystem, the secondary data being redundant of the primary data.
In another embodiment, a system comprises: a first storage subsystem for performing a first write operation on a data object to form a first version of the data object, the data object being included among a plurality of data objects of primary data; and a second storage subsystem for initiating retrieval of the data object from the first storage subsystem using an identification of the data object received from the first storage system and for applying the retrieved data object to secondary data at the secondary storage subsystem, the secondary data being redundant of the primary data.
These and other embodiments are described in more detail herein.
The present invention provides a data redundancy technique in which a first data storage subsystem acting as a primary storage facility performs a write operation to update its local copy of a data object. Rather than immediately sending the updated data object to a second storage subsystem acting as a secondary storage facility, the first storage subsystem instead sends a description of the data object to the second storage subsystem. The description of the data object includes an identifier of the data object, such as its address and length, and may also include a version indicator of the data object, such as a hash of its value. The primary storage facility need not thereafter maintain any data regarding the status of the update.
The second storage subsystem retrieves the updated data object at a time that is appropriate for the second storage subsystem by sending a request for the data object to the first storage subsystem. Multiple storage subsystems acting as secondary storage facilities may each retrieve the updated data object at times appropriate for them. Thus, responsibility for maintaining the secondary copy is primarily with the secondary facility (or facilities), which reduces the workload of the primary storage facility. A secondary storage facility retrieves data objects when appropriate for it, which allows the secondary storage facility to better utilize its resources by smoothing its workload over time.
Additional devices, such as one or more computer(s) 108 (e.g., a host computer, a workstation or a server), may communicate with the first storage subsystem 102 (e.g., via communication medium 110). While
One or more applications operating at the computer 108 may access the first storage subsystem 102 for performing write or read operations to or from data objects, such as data blocks, files or storage volumes, stored at the subsystem 102. More particularly, the computer 108 may retrieve a copy of a data object by issuing a read request to the facility 102. Also, when a data object at the computer 108 is ready for storage at the facility 102, the computer 108 may issue a write request to the facility 102. For example, the computer 108 may request storage of a file undergoing modification by the computer 108. While a single computer 108 is illustrated in
For increasing data reliability in the event of a fault at the first storage subsystem 102, data that is redundant of data stored at the first storage subsystem 102 is stored at the second storage subsystem 104. In this case, the first storage subsystem 102 acts as a primary storage facility for the data while the second storage subsystem 104 acts as a secondary storage facility for the data. For example, the second storage subsystem 104 may store a single mirrored copy of data stored by the first storage subsystem 102. Alternatively, the redundant data may be arranged according to another redundancy scheme in which redundant data is distributed among or striped across multiple storage devices or subsystems or in which the redundant data is stored using parity-based error correction coding. For example, the redundant data may be stored at a secondary storage facility (or a plurality of secondary storage facilities) in accordance with Redundant Array of Inexpensive Disks (RAID) techniques, such as RAID levels 0, 1, 2, 3, 4 or 5. Thus, one or more additional storage subsystems acting as secondary storage facilities may be provided, in which each stores only a portion of the data stored at the primary storage facility (thus, proving a distributed redundant copy) or where each stores a complete copy of the data (thus, providing multiple redundant copies). Further, the primary storage facility may itself store data redundantly, such as by employing any RAID technique on data stored at the primary storage facility.
In absence of a fault at the first storage subsystem 102, the computer 108 generally does not direct write and read accesses to the second storage subsystem 104. Rather, for performing write and read operations, the computer 108 accesses the first storage subsystem 102. The first storage subsystem 102 and the second storage subsystem 104 then interact to provide redundant data at the second storage subsystem 104. In the event of a fault at the first storage subsystem 102, lost data may then be reconstructed from the redundant data stored at the second storage subsystem 104 and delivered to the computer 108, or another computer (not shown) may be used to access data at the second storage subsystem facility 104.
For performing its functions, the first storage subsystem 102 may include a CPU or controller 110, a memory 112, such as volatile and/or non-volatile memory, and one or more mass storage devices 114, such as a disk drive (magnetic or optical), disk array or tape subsystem. The mass storage 114 may store a primary copy of data. The second storage subsystem 104 may include a CPU or controller 116, a memory 118, such as volatile and/or non-volatile memory, and one or more mass storage devices 120, such as a disk drive (magnetic or optical), disk array or tape subsystem. The mass storage 120 may store a secondary copy of the data. The primary and secondary copies may include multiple data objects which can be read and written. The memory 118 of the second storage subsystem 104 may include a pending write queue 122 for tracking write operations performed at the first storage subsystem 102, but that have not yet been committed to the secondary copy of the data. The pending write queue 112 is preferably stored in non-volatile memory; it may alternatively be stored on mass storage 120. Computer code for controlling the first and second subsystems 102 to perform functions described herein may be stored on or loaded from computer readable media.
The version indicator 304 for the data object may include a hash value of the data object or some other value suitable for indicating the version of the data object. For example, the version indicator 304 may include a logical timestamp, such as clock value which indicates the time that the object was written at the primary storage facility or a sequence number that is incremented each time the object is overwritten at the primary storage facility or which is incremented each time the primary storage facility generates a new transaction description 300. If the version indicator cannot be derived from the data object itself, then the primary storage facility also stores the version indicator in addition to the data. Otherwise, if the version indicator can be derived from the data object itself, as is the case where the version indicator is a hash value, then the identifier can be derived from the data object when needed and need not be stored at the primary storage facility. Alternatively, the version indicator may be omitted from the description 300 sent to the secondary storage facility, if protection against over-writes and out-of-order updates is not required.
As mentioned, rather than forwarding the data objects themselves, a transaction description (e.g., as shown in
The descriptions 300 may be stored in the pending write queue 122 of the second storage subsystem 104 (
After descriptions of new transactions are received and stored by the secondary storage facility, the secondary storage facility sends requests for the data objects that correspond to the previously received descriptions. Thus, the secondary storage facility first receives the description for a write transaction and then retrieves the corresponding object itself. The primary storage facility initiates the sending of the descriptions to the secondary storage facility, whereas, the secondary storage facility initiates retrieval of the corresponding updated data objects. This retrieval may be concurrent with continuing operations at both the primary and secondary storage facilities.
Once the primary storage facility sends the description of a particular write transaction to the secondary storage facility, the primary storage facility need not thereafter maintain any information as to the status of the transaction at the secondary storage facility. In an embodiment, the secondary storage facility does not generate any indication to the primary that it has received the description. Thus, the primary storage facility may signal to the application that generated the write transaction that the transaction is complete without the need to receive an acknowledgement from the secondary storage facility. To protect against possible communication loss, communication protocols that incorporate reliability measures (such as TCP/IP, or others) can be used to ensure that no descriptions are lost. Alternatively, the description 300 can be augmented with a sequence number generated by the primary facility, and incremented with each new description it generates, so that the secondary facility can detect from the received sequence numbers if it is missing any descriptions. Thus, such sequence numbers can be used as version identifiers and to detect missing descriptions.
In an alternative embodiment, the secondary storage facility returns an acknowledgement to the primary storage facility for each description received by the secondary storage facility. Once the acknowledgement is received, the primary storage facility may signal to the application that generated the write operation that the transaction is complete. If an acknowledgment is not received, the primary storage facility may repeat sending the description until it receives an acknowledgement. If no acknowledgement is received after a predetermined number of tries, the primary storage facility may refuse to accept a next write request from the application that generated the write operation.
The secondary sequence 204 generally follows the write-ordering of transactions in the primary sequence 202, but lags behind the primary sequence 202 in time. Thus,
Depending on the circumstances, a data object may have been overwritten with a new version at the primary storage facility before the secondary storage facility attempts to retrieve the object. Referring to the example of
If, in the interim between the updates to a particular data object, any other data object(s) had been updated and the secondary storage facility were to then apply the particular updated data object to its secondary copy of the data without applying the other updated object(s), the secondary copy would not be consistent with the primary copy because the write-ordering would not be preserved. In the example of
The second storage subsystem 104 acting as a secondary storage facility may detect that a data object has been overwritten at the primary storage facility after the object is retrieved by comparing the version of the retrieved data object to the version associated with the operation in the primary sequence 202. To accomplish this, the secondary storage facility may compute the hash of the retrieved data object and compare it to the hash it previously received from the primary storage facility, e.g., the hash 304 (
Alternatively, rather than the secondary storage facility comparing the versions to detect that a data object has been overwritten at the primary storage facility, this could be done elsewhere, such as at the first storage subsystem 102 acting as the primary storage facility. In this case, the secondary storage facility may send the version indicator for the object it is requesting to the primary storage facility along with the identification of the object. Thus, the secondary storage facility may return the complete transaction description (e.g., description 300) to the primary storage facility. The primary storage facility may then compare its most-recent version for the data to the version received from the secondary storage facility. The primary storage facility may then send a notification to the secondary storage facility that indicates whether the data has been overwritten along with the data.
When the secondary storage facility discovers that a data object requested from the primary storage facility has been overwritten, the secondary storage facility may, at this point, stop processing further updates to its secondary copy of the data so as to maintain the write ordering of the updates already processed. In this case, the secondary copy will then become increasingly out-of-date as the primary storage facility continues to process write requests unless further action is taken. Alternatively, the secondary storage facility may simply apply the updated data to its local copy without preserving the write ordering of the transactions. While this will keep the secondary copy more up-to-date, the secondary copy may become inconsistent with the primary copy.
Alternatively, updates that would be inconsistent if they were applied independently can be accumulated until a consistency point where write-ordering equivalence has been achieved, and then applied together, as follows. When a data object requested from the primary storage facility has been overwritten and the secondary storage facility has another update to this same data object in its transaction queue, it may obtain a consistent copy of the data as though the write ordering had been preserved and if it applies all of the operations in the queue up to and including the next update to this data object. Returning to the example of
Once the data objects, Object (A, 2) and Object (B, 1), are applied, the secondary copy will be consistent with the primary copy as though the write ordering of the transactions had been preserved. However, if one of the data objects to be applied together as whole has itself been overwritten, then the applying this group will not obtain a consistent copy of the data. Returning to the example, if the object, Object (B, 1), had been overwritten before it was retrieved, then the secondary storage facility would have received the updated object, such as Object (B, 2) in response to its request for the Object(B, 1). In this case, it may be possible for the secondary storage system to maintain consistency between the secondary copy and the primary copy if it then retrieves all of the data objects which were updated between the transaction (B, 1) and the transaction (B, 2) and applies them together along with the data object, Object (B, 2).
In an embodiment, rather than the primary storage facility overwriting a data object in place in response to a write operation to the data, the primary storage facility may write the updated data object to a new location at the primary storage facility thereby maintaining multiple versions of the same data object. In this embodiment, the transaction description sent from the primary storage facility to the secondary storage facility for each write operation (and queued at the secondary facility) includes a version indicator which may be a logical timestamp (e.g., a clock value or a sequence number). Using a logical timestamp allows the relative write ordering of the versions to be determined from the timestamps. A hash value of the data object may optionally be sent as well. When the secondary storage facility then requests the data object corresponding to each transaction in its queue (e.g., queue 122), it also identifies the particular version to the primary storage facility. The primary storage facility then responds by providing the requested version of the data even if the data has since been updated. The secondary storage facility then applies this version to its local copy. In this way, write transactions are retrieved and applied serially, thereby preserving the write ordering of the transactions.
As mentioned, if version indicators other than hash values, such as logical timestamps, are employed the primary storage facility stores the version indicator for a data object in addition to the data object itself. In this case, the logical timestamps may be stored in volatile memory, since a recovery from a loss of the timestamps at the primary storage facility could be performed by the secondary storage facility retrieving the most-recent version of each updated data object identified in its transaction queue and applying them together as a whole. Alternatively, the logical timestamps may be stored in non-volatile memory (e.g., memory 112) separate from the data itself since this would prevent the loss of the logical timestamps in the event of certain failures at the primary storage facility, such a temporary loss of power. As another alternative, the logical timestamps may be stored in mass storage (e.g., massage storage 114 of
A garbage collection technique may be employed to limit the storage of copies of data objects at the primary storage facility that are not expected to be retrieved again by the secondary storage facility. For example, any data object older (an indicated by its logical timestamp), than the oldest data object requested for retrieval by all of the secondary storage facilities could be discarded. Alternatively, the secondary storage facilities could periodically notify the primary storage facility of a cut-off time for which the secondary storage facility no longer needs access to data objects older than the cut-off time. As another alternative, data objects whose logical timestamps are older than a predetermined time period (e.g., a day) could be discarded. These garbage collection techniques or other garbage collection techniques could be used in conjunction with each other.
The foregoing detailed description of the present invention is provided for the purposes of illustration and is not intended to be exhaustive or to limit the invention to the embodiments disclosed. Accordingly, the scope of the present invention is defined by the appended claims.