Emc IP Holding Company LLC

Emc Corporation

Ying Hu

Xiangping Chen

Anton Kucherov

Felix Shvaiger

Zvi Schneider

Richard P Ruef

David Meiri

Yuval Harduf

Kurt William Everson

Ruiling Dou

Vladimir Shveidel

Feng Zhang

Gong Chen

Hao Pan

In one aspect, adaptive replication modes in a storage system are provided. An aspect includes during an active replication session in which a first type of replication is performed at the storage system, monitoring write input/output (IO) operations, collecting data from the write IO operations, and determining, from the collected data, write IO latency. Upon determining that a threshold value has been met from the write IO latency, where the threshold value is defined for the first type of replication, an aspect includes automatically switching from the first type of replication to a second type of replication. The second type of replication is configured to compensate for operational deficiencies detected in response to the write IO latency.

Adaptive replication modes in a storage system

A method is disclosed comprising: generating a first snapshot of a first storage subsystem; detecting, by a management node, that all in-flight data storage requests recorded in drain tables of storage nodes in the first storage subsystem have been completed, the in-flight data storage requests recorded in the drain tables of the storage nodes being replicated in a second storage subsystem; causing, by the management node, each of the storage nodes to flip the respective designations of the tracking tables in the node's respective pair of tracking tables; and transmitting, from the management node to the second storage subsystem, an instruction which when received by the second storage subsystem causes the second storage subsystem to generate a second snapshot of the second storage subsystem.

Sand timer algorithm for tracking in-flight data storage requests for data replication

Described embodiments provide systems and methods for operating a storage system wherein an online consistent system checkpoint is generated. The checkpoint contains a point in time image of a system and is used for providing recovery of the system to a known good state. In one embodiment the checkpoint includes volume configuration data, logical volume space, a plurality of layers of metadata, and physical data storage.

Online consistent system checkpoint

An apparatus comprises a storage system having storage devices and an associated storage controller. In conjunction with initiation of a checkpoint, the storage controller sets a checkpoint started flag for the checkpoint, marks user data pages and metadata pages for write operations already entered in a write journal of the storage system as of the setting of the checkpoint started flag as checkpoint pages, and marks user data pages and metadata pages for new write operations entered in the write journal after the setting of the checkpoint started flag as non-checkpoint pages by altering information used to generate signatures for respective ones of the metadata pages. Metadata pages characterizing the same user data pages subject to write operations at different times thereby have different signatures depending on whether or not the checkpoint started flag was set when its corresponding write operation was entered in the write journal.

Checkpointing of user data and metadata in a non-atomic persistent storage environment

A storage system is configured to comprise a processor in operable communication with a storage device and a metadata journal comprising metadata configured to store information associated with a change to be made to information stored on the storage device. While the storage system is booted up and responsive to I/O requests from a host, a scan is performed of a first portion of metadata that is loaded into storage system memory during the bootup, to check for existence of a metadata inconsistency condition comprising at least one of: (a) dirty tree (DT) entries in the metadata associated with an invalid logical unit (LU) index; (b) hash tree (HT) entries in the metadata which do not have corresponding DT bits; and (c) DT bits set without having a corresponding HT entry. Based on the results of the first scan, a determination is made about whether a first metadata inconsistency condition exists.

Online address to hash (A2H) metadata scanner

An aspect includes generating a checkpoint for a storage system containing an image for a point in time. An aspect also includes storing, in a reserved area, volume configuration data corresponding to volumes for the point in time, layers of metadata and physical data for the point in time. An aspect further includes creating consistent snapshots for the volumes, destaging a control module journal and persisting a hash tree and dirty tree metadata, destaging a code cache, dumping hash metadata and physical layout metadata to a separate location in the storage and enabling new metadata updates to a default location. An aspect also includes redirecting new data and metadata IOS to stripes reserved during preparation of the separate location relating to the checkpoint and protecting checkpointed data and metadata, and generating a consistent checkpoint copy of a management module repository in the reserved area of storage.

Online system checkpoint recovery orchestration

In one aspect, IO recovery mechanisms in active/active replication for storage clusters provide, for each write IO request: determining an extent of pages to be modified; acquiring a lock by a cluster local to the request and locally persisting data; atomically creating an entry in a local journal; and sending, by the local cluster, a data write request to a peer cluster. Upon receiving acknowledgement from the peer cluster of successful transmission, the replication journal entry is cleared, the extent is unlocked, and a notification is returned to the peer. In response to a failure event at the peer cluster after persisting the data at the local cluster and creating the journal entry at the local cluster, an aspect includes sending, to the peer cluster upon recovery of the peer cluster, the journal entry with respect to an extent corresponding to a time of the failure event.

Consistent input/output (IO) recovery for active/active cluster replication

In one aspect, support for hash based xcopy replication for synchronous replication is provided. An aspect includes determining, in response to an xcopy command, whether a source logical unit (LU) and a target LU are in active synchronous replication to the same target site. Upon determining that the LUs are in active synchronous replication, increasing a count of a hash handle list, obtaining a unique full hash digest, and sending the digest with volume replication pairing identifier, offset, and length to the target. Upon receiving a request from the source, searching, by the target, for local hash handles of the digest; and upon determining the local hash handles exist in the digest, incrementing, the reference counter handle list, and sending corresponding hash handles from the source site to the target.

Method to support hash based xcopy synchronous replication

In one aspect, providing recovery during active/active replication includes: creating, at a first storage device, a local snapset; waiting for inflight (input/output) IO operations (IOs) from the first device to a second device at the time snapset creation to complete; creating a recovery snapset; and waiting for inflight IOs from the second device to the first device, at the time of snapset creation to complete. Upon determining a failure event, an aspect includes identifying a most recent local snapset (Sk) and a most recent recovery snapset (Sk') on the first and second devices, respectively, identifying predecessor snapsets (Sk&#x2212;1) and (Sk&#x2212;1&#x2032;) on the first and second devices, respectively, creating a new recovery snapset (Sk&#x2032;) using (Sk&#x2212;1&#x2032;), sending the delta of (Sk) and (Sk&#x2212;1) from the first device to the second device; updating (Sk&#x2032;) with the delta; and performing async-to-sync recovery to transfer a difference between the first and second devices.

Recovery after service disruption during an active/active replication session

An apparatus in one embodiment comprises at least one processing device comprising a processor coupled to a memory. The processing device is configured to capture metadata from a metadata area of a storage system for checkpointing, and to store the captured metadata as checkpointed metadata in a user data area of the storage system in association with mapping information relating portions of the checkpointed metadata to particular storage locations in the user data area. The processing device in some embodiments is implemented within the storage system, and may comprise a storage controller of the storage system. The mapping information illustratively comprises a plurality of page location arrays each having a plurality of entries specifying respective locations of checkpointed metadata pages in the user data area. The mapping information may further comprise one or more array location arrays each indexed by a corresponding set of page location array identifiers specifying respective locations of page location arrays in the user data area.

Checkpointing of metadata into user data area of a content addressable storage system

A storage system comprises a storage device and metadata journal comprising metadata configured to store information associated with changes to information stored on the storage device. Dirty tree (DT) metadata pages, each corresponding to information written to the storage device from the metadata journal, are stored on the storage device. DT pages are read and scanned to detect if any DT metadata page comprises an entry having an invalid snap group ID associated with a given offset. For each detected DT metadata page comprising a respective invalid snap group ID, a corresponding fake journal entry is created in metadata journal and configured to point to the respective DT metadata page comprising the invalid snap group ID and given offset. The fake journal entry is configured so that, when the metadata journal is destaged to the storage device, the invalid snap group ID is reset to nonexistent.

Online metadata backup consistency check

An aspect of resolving conflicts during recovery operations includes separating journal entries for first and second types of recovery operations into each of a first and second array. For each entry in the first array, an aspect includes taking a range lock of a designated number of the addresses and creating an entry in a table. For each entry in the second array, an aspect includes upon determining a corresponding sub-LUN has been locked for an entry in the first array, incrementing a count in the table. Upon determining the corresponding sub-LUN is not locked for the entry, an aspect includes taking the address lock for the entry in the second array. An aspect further includes opening gates for a corresponding address, performing a first recovery operation corresponding to the first type of recovery operation, and performing a second recovery operation corresponding to the second type of recovery operation.

Method to resolve conflicts during recovery in a storage system

A storage system in one embodiment is configured to participate as a source storage system in a synchronous replication process with a target storage system. In conjunction with the synchronous replication process, the source storage system receives write requests from at least one host device. Responsive to a given write request being a multi-page write request, an entry is created in a first journal, where the first journal is utilized to ensure that the given write request is completed for all of the pages or for none of the pages. Responsive to the write request being a single-page write request, an entry is created in a second journal different than the first journal. An address-to-signature table is updated utilizing write data of the write request, and if the corresponding entry for the write request was created in the first journal, the entry is swapped from the first journal into the second journal, and the write data of the write request is sent to the target storage system.

Growing community of inventors

Northborough, MA, United States of America

Ying Hu