A method is provided, comprising: receiving, at a first storage array, a first request to perform an atomic write operation at a specified address in a volume; placing a read-write lock on a first instance of the volume, and executing the atomic write operation on the first instance of the volume; transmitting, to a second storage array, a second request to perform the atomic write operation on a second instance of the volume; and detecting whether an error condition is present that is associated with the second request; when the error condition is present, comparing a first data item that is stored at the specified address in the first instance of the volume with a second data item that is stored at the specified address in the second instance of the volume, and, when the first data item matches the second data item, transmitting an acknowledgment.
|
8. A storage system, comprising:
one or more storage devices, and
at least one processor configured to perform the operations of:
receiving a first request to perform an atomic write operation at a specified address in a volume, the first request being received from a host device;
placing a read-write lock on a first instance of the volume that is stored in the one or more storage devices, and executing the atomic write operation on the first instance of the volume;
transmitting, to a peer storage system, a second request to perform the atomic write operation on a second instance of the volume that is stored at the peer storage system;
detecting whether an error condition is present that is associated with the second request; and
when the error condition is present, comparing a first data item that is stored at the specified address in the first instance of the volume with a second data item that is stored at the specified address in the second instance of the volume, and, when the first data item matches the second data item, transmitting an acknowledgment to the host device indicating that the first request has been completed successfully.
1. A method for use in an active-active storage cluster having first a storage array and a second storage array, the method comprising:
receiving, at the first storage array, a first request to perform an atomic write operation at a specified address in a volume, the first request being received from a host device;
placing a read-write lock on a first instance of the volume that is stored at the first storage array, and executing the atomic write operation on the first instance of the volume;
transmitting, to the second storage array, a second request to perform the atomic write operation on a second instance of the volume that is stored at the second storage array;
detecting whether an error condition is present that is associated with the second request; and
when the error condition is present, comparing a first data item that is stored at the specified address in the first instance of the volume with a second data item that is stored at the specified address in the second instance of the volume, and, when the first data item matches the second data item, transmitting an acknowledgment to the host device indicating that the first request has been completed successfully.
15. A method for use in an active-active storage cluster having first a storage array and a second storage array, the method comprising:
receiving, at the first storage array, a first request to perform an atomic write operation at a specified address in a volume, the first request being received from a host device;
placing a read-write lock on a first instance of the volume that is stored at the first storage array;
transmitting, to the second storage array, a second request to perform the atomic write operation on a second instance of the volume that is stored at the second storage array; and
detecting whether an error condition is present that is associated with the second request;
when the error condition is present, comparing a first data item that is stored at the specified address in the first instance of the volume with a second data item that is stored at the specified address in the second instance of the volume, and, when the first data item does not match the second data item, copying the second data item to the specified address in the first instance of the volume, and transmitting an acknowledgment to the host device indicating that the first request has been completed successfully.
2. The method of
3. The method of
4. The method of
5. The method of
7. The method of
9. The storage system of
10. The storage system of
11. The storage system of
12. The storage system of
13. The storage system of
14. The storage system of
16. The method of
17. The method of
18. The method of
19. The method of
20. The method of
|
A distributed storage system may include a plurality of storage devices (e.g., storage device arrays) to provide data storage to a plurality of nodes. The plurality of storage devices and the plurality of nodes may be situated in the same physical location, or in one or more physically remote locations. The plurality of nodes may be coupled to the storage devices by a high-speed interconnect, such as a switch fabric.
This Summary is provided to introduce a selection of concepts in a simplified form that are further described below in the Detailed Description. This Summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used to limit the scope of the claimed subject matter.
According to aspects of the disclosure, a method for use in an active-active storage cluster having first a storage array and a second storage array, the method comprising: receiving, at the first storage array, a first request to perform an atomic write operation at a specified address in a volume, the first request being received from a host device; placing a read-write lock on a first instance of the volume that is stored at the first storage array, and executing the atomic write operation on the first instance of the volume; transmitting, to the second storage array, a second request to perform the atomic write operation on a second instance of the volume that is stored at the second storage array; and detecting whether an error condition is present that is associated with the second request; when the error condition is present, comparing a first data item that is stored at the specified address in the first instance of the volume with a second data item that is stored at the specified address in the second instance of the volume, and, when the first data item matches the second data item, transmitting an acknowledgment to the host device indicating that the first request has been completed successfully.
According to aspects of the disclosure, a storage system is provided, comprising: one or more storage devices, and at least one processor configured to perform the operations of: receiving a first request to perform an atomic write operation at a specified address in a volume, the first request being received from a host device; placing a read-write lock on a first instance of the volume that is stored in the one or more storage devices, and executing the atomic write operation on the first instance of the volume; transmitting, to a peer storage system, a second request to perform the atomic write operation on a second instance of the volume that is stored at the peer storage system; and detecting whether an error condition is present that is associated with the second request; when the error condition is present, comparing a first data item that is stored at the specified address in the first instance of the volume with a second data item that is stored at the specified address in the second instance of the volume, and, when the first data item matches the second data item, transmitting an acknowledgment to the host device indicating that the first request has been completed successfully.
According aspects of the disclosure, a method is provided for use in an active-active storage cluster having first a storage array and a second storage array, the method comprising: receiving, at the first storage array, a first request to perform an atomic write operation at a specified address in a volume, the first request being received from a host device; placing a read-write lock on a first instance of the volume that is stored at the first storage array; transmitting, to the second storage array, a second request to perform the atomic write operation on a second instance of the volume that is stored at the second storage array; detecting whether an error condition is present that is associated with the second request; and when the error condition is present, comparing a first data item that is stored at the specified address in the first instance of the volume with a second data item that is stored at the specified address in the second instance of the volume, and, when the first data item does not match the second data item, copying the second data item to the specified address in the first instance of the volume, and transmitting an acknowledgment to the host device indicating that the first request has been completed successfully.
Other aspects, features, and advantages of the claimed invention will become more fully apparent from the following detailed description, the appended claims, and the accompanying drawings in which like reference numerals identify similar or identical elements. Reference numerals that are introduced in the specification in association with a drawing figure may be repeated in one or more subsequent figures without additional description in the specification in order to provide context for other features.
The storage cluster 110 may include a first storage array 112A and a second storage array 112B. The first storage array 112A and the second storage array 112B may be configured to maintain a storage volume 111. The first storage array 112A may store a first instance 113 of the volume 111, and the second storage array 112B may store a second instance 115 of the volume 111. The first storage array 112A and the second storage array 112B may be coupled to one another via a communications network 116 and configured to operate in active-active configuration. In this configuration, data stored in one of the storage arrays 112A and 112B is replicated to the other one by utilizing a replication process that is carried over the communications network 116. Each of the storage arrays 112A and 112B may therefore operate as a production storage array relative to the other, which operates as a backup or recovery storage array.
Host devices in the host cluster 120 may write to the volume 111 by interacting with either one of the first storage array 112A and the second storage array 112B. When a host device writes data to the volume 111 via the first storage array 112A, the first storage array 112A may store the data in the first instance 113 of the volume 111, and it may also interact with the second storage array 112B to store the data in the second instance 115 of volume 111. Similarly, when a host device writes data to the volume 111 via the second storage array 112B, the second storage array 112B may store the data in the second instance 115 of the volume 111, and it may also interact with the first storage array 112A to store the data in the first instance 113 of volume 111. The first instance 113 and the second instance 115 of volume 111 must be maintained in a consistent state.
The host cluster 120 may include one or more host devices 122. According to the present example, the host cluster 120 includes a host device 122A, a host device 122B, and a host device 122B. Any of the host devices 122 may include a desktop computer, a smartphone, a server, a file server, a database frontend, a website frontend, and/or any other suitable type of storage device. Additionally or alternatively, in some implementations, any of the host devices 122 may include a computing device, such as the computing device 500, which is discussed further below with respect to
The communications network 130 may include one or more of the Internet, a wide area network (WAN), a local area network (LAN), an InfiniB and network, and/or any other suitable type of network. The communications network 116 may include one or more the Internet, a wide area network (WAN), a local area network (LAN), an InfiniBand network, and/or any other suitable type of network. The communications network 116 may or may not be part of the communications network 130. For example, in some implementations, the communications network 116 may be an internal network that is dedicated to communications between the first storage array 112A and the second storage array 112B.
As illustrated, the storage array 112 may include one or more servers 220 and one or more storage devices 230. Any of the servers 220 may be implemented by using any suitable type of computing device, such as the computing device 500, which is discussed further below with respect to
The storage devices 230 may include one or more rotating magnetic storage devices, one or more rotating optical storage devices, and/or one or more solid state drives (SSDs). Additionally or alternatively, the storage devices 230 may include one or more hard disk drives (HDD), one or more flash drives, optical disks, as well as one or more other types of data storage devices. Additionally or alternatively, the storage devices 230 may include a redundant array of inexpensive disks (RAID) array, an optical storage array, or any other type of array of storage devices 230.
The MPIO driver 250 may be part of a multi-path layer of the host cluster 120. The multi-path layer provides automated path selection functionality using a path selection logic 260, which is part of the MPIO driver 250. The MPIO driver 250 may comprise, for example, PowerPath drivers from Dell EMC, and/or other types of MPIO drivers that are arranged to discover available communications paths between the host device 122 and corresponding storage arrays (e.g., the storage arrays 112A and 112B). The MPIO driver 250 may be configured to select I/O operations from any of the I/O queues 240 for delivery to the storage arrays 112A and 112B over the communications network 130. The sources of the IO operations stored in the set of I/O queues 240 may include respective processes of one or more applications executing on the host device 122. Other types of sources of IO operations may be present in a given implementation of system 100.
In selecting particular ones of the paths for delivery of the IO operations to the storage arrays 112A and 112B, the path selection logic 260 of the MPIO driver 250 may implement a path selection algorithm that selects particular ones of the paths in accordance with the path selection algorithm. The MPIO driver 250 may include a user-space portion and a kernel-space portion. The kernel-space portion of the MPIO driver 250 may be configured to detect one or more path changes of the type mentioned above, and to instruct the user-space portion of the MPIO driver 250 to run a path discovery scan responsive to the detected path changes. Other divisions of functionality between the user-space portion and the kernel-space portion of the MPIO driver 250 are possible.
As noted above, in an active-active replication environment data must be identical on each instance of a volume. When a write command, received from a host device (e.g., the host device 122A), is executed on a first instance of a volume (e.g., the first instance 113), the same write request needs to be executed all other instances of the volume (e.g., the second instance 115), as well. However, it is possible that a write will succeed on the first instance and fail on the second instance. A conventional approach for handling this approach is to revert the first instance of the volume to its prior state and issue an error, meaning the host device must retry the write and cannot assume anything about the data that is being written. This approach, however, could lead to a window of vulnerability in which different instances of the same volume store different data at the same address. The window of vulnerability may last until the first instance of the volume is reverted to its prior state.
For example, during the window of vulnerability, a host device may perform the same read twice and receive different data, even though it should have gotten the same data. As another example, during the window of vulnerability, two host devices may each perform a read (from the same address) from different instances of the same volume and receive different data. When the data received is a part of a synchronization object or another similar object that controls the sharing of a resource, receiving different data at the two host devices may result in the two host devices accessing the resource the same time or otherwise sharing the resource incorrectly. While the conventional approach to handling failed writes is acceptable for most type of writes, it can be infeasible for atomic changes such as VMware TM ATS (atomic test and set) or, in general, any read-modify-write command, because global corruption of data can occur during the window of vulnerability.
At step 302, the first storage array 112A receives a first request to perform an atomic write operation at a specified address in the volume 111. The first request may be received over the communications network 130 from the host device 122A. The first request may include one or more of an atomic test-and-set (ATS) command, a read-modify-write command, a SCSI reservation command, and/or any other suitable type of atomic write command. The first request may include one or more of (i) an opcode, a (ii) a data item, and (iii) an indication of the specified address where the data item is desired to be stored (e.g., if a condition is satisfied, etc.). The data item may include a page of data and/or any other suitable type of data item.
Although in the example of
At step 304, the first storage array 112A places a read-write lock on the first instance 113 of the volume 111. The read-write lock may include any suitable type of lock that prevents: (i) the reading of data from the specified address in the first instance 113 of the volume 111, and (ii) the writing of data to the specified address in the first instance 113 of volume 111. In some implementations, the read-write lock may encompass the entire first instance 113 of the volume 111. Additionally or alternatively, in some implementations, the read-write lock may encompass only a portion of the volume 111 that includes the specified address. For example, the read-write lock may be placed on only one of the storage devices 230 that includes the physical location corresponding to the specified address.
At step 306, the first storage array 112A attempts to store the data item associated with the first request in the first instance 113 of the volume 111. The data item may be stored at the address specified by the first request.
At step 307, the first storage array 112A determines if the attempt was successful. If the attempt was not successful, the process 300 proceeds to step 324. Otherwise, if the data item was successfully stored in the first instance 113 of the volume 111, the process 300 proceeds to step 308.
At step 308, the first storage array 112A transmits to the second storage array 112B a second request to perform the atomic write operation on the second instance 115 of the volume 111. The second request may include any suitable type of request to write, in the second instance 115 of volume 111, the data item (associated with the first request), at the address (specified by the first request). The second request may be transmitted over the communications network 116. The second request may be transmitted for the purposes of maintaining the first instance 113 and the second instance 115 of the volume 111 in consistent states.
At step 310, the first storage array 112A detects whether an error condition is present that is associated with the second request. In some implementations, detecting whether an error condition is present may include detecting whether the second request has been completed successfully by the second storage array 112B. If no error condition is detected (i.e., if the second request has been completed successfully by the second storage array 112B), the process 300 proceeds to step 312. Otherwise, if an error condition is detected, the process 300 proceeds to step 314.
At step 312, the first storage array 112A releases the read-write lock (set at step 304), and transmits to the host device 122A an acknowledgment indicating the that the first request has been executed successfully by the storage cluster 110A.
At step 314, the first storage array 112A retrieves a first data item that is stored, at the address specified by the first request, in the first instance 113 of the volume 111. As can be readily appreciated, following a successful execution of step 306, the first data item would be the same as the item associated with the first request (i.e., the atomic write request that is received at the first storage array 112A at step 302).
At step 316, the first storage array 112A retrieves from the second storage array 112B a second data item that is stored, at the address specified by the first request, in the second instance 115 of the volume 111. The second data item may be retrieved by transmitting a read request to the second storage array 112B. As can be readily appreciated, in a situation in which the second storage array 112B has successfully executed the second request, but the first storage array 112A failed to receive an acknowledgment of the successful completion of the second request, the received second data item may be the same as the second data item associated with the first request. This situation can occur as a result of a hiccup or some intermittent failure in the communications network 116 and/or the second storage array 112B. On the other hand, if the second storage array 112B experienced an internal failure that prevented it from completing the second request, the second data item may be different from the data item that is associated with the first request (i.e., the atomic write request that is received at the first storage array 112A at step 302). In either one of these situations, the first storage array 112A would detect the presence of an error condition associated with the second read request (at step 310).
At step 318, the first storage array 112A compares the first data item to the second data item to determine if they match. By way of example, in some implementations, the first data item may match the second data item when they are identical and/or within a predetermined distance from one another. When the first data item is the same as the second data item, this is an indication that: (i) the first instance 113 and the second instance 115 of the volume 111 are in a consistent state, and (ii) the first request has been completed successfully by the storage cluster 110. When the first data item and the second data item are different, this is an indication that: (i) the first instance 113 and the second instance 115 are in inconsistent states (because they store different data at the same address), and (ii) the execution of the first request by the storage cluster 110 has failed. If the first data item matches the second data item, the process 300 proceeds to step 320. Otherwise, if the first data item does not match the second data item, the process 300 proceeds to step 322.
At step 320, the first storage array 112A releases the read-write lock (set at step 304), and transmits to the host device 122A an acknowledgment indicating the that the first request has been executed successfully by the storage cluster 110.
At step 322, the first storage array 112A writes the second data item, at the specified address, to the first instance 113 of the volume 111. Doing so has the effect of bringing back the first instance 113 to a state that is consistent with the state of the second instance 115, effectively restoring the data integrity of the volume 111.
At step 324, the first storage array 112A releases the read-write lock (set at step 304), and transmits to the host device 122A an error indicating the that the first request could not be executed successfully by the storage cluster 110A.
The present disclosure is not limited to any specific method for detecting whether an error condition is present (at step 310 of the process 300). In some implementations, detecting whether an error condition is present may include detecting whether a timeout event is generated that is associated with the second request. The timeout event may include any suitable type of event that indicates that the first array 112A has not received, within a predetermined time period, an acknowledgement that the second request has been completed successfully by the second storage array 112B. Additionally or alternatively, in some implementations, detecting whether an error condition is present may include detecting whether an error is received from the second storage array 112B, which indicates that the second storage array 112B encountered a failure as it was trying to complete the second request. Additionally or alternatively, in some implementations, detecting whether an error condition is present may include detecting whether an acknowledgement is received from the second storage array 112B indicating the second request has been completed successfully.
It should be noted that the read-write lock (set at step 304) is maintained until either an acknowledgment or error is transmitted in response to the first request (received at step 302). Maintaining the read-write lock for the entire duration in which the first request is being serviced prevents the occurrence of a window of vulnerability. Maintaining the read-write lock forces all read requests for the specified address (i.e., the address specified by the first request) to be served by the second instance 115 of the volume 111, thereby preventing the retrieval of different data, from the specified address, from each of the first instance 113 and the second instance 115 of the volume 111. Moreover, under the arrangement described with respect to
Referring to
Processor 502 may be implemented by one or more programmable processors executing one or more computer programs to perform the functions of the system. As used herein, the term “processor” describes an electronic circuit that performs a function, an operation, or a sequence of operations. The function, operation, or sequence of operations may be hard-coded into the electronic circuit or soft coded by way of instructions held in a memory device. A “processor” may perform the function, operation, or sequence of operations using digital values or using analog signals. In some embodiments, the “processor” can be embodied in an application-specific integrated circuit (ASIC). In some embodiments, the “processor” may be embodied in a microprocessor with associated program memory. In some embodiments, the “processor” may be embodied in a discrete electronic circuit. The “processor” may be analog, digital or mixed-signal. In some embodiments, the “processor” may be one or more physical processors or one or more “virtual” (e.g., remotely located or “cloud”) processors.
At step 602, the first storage array 112A receives a first request to perform an atomic write operation at a specified address in the volume 111. Step 602 may be performed in the same or similar manner as step 302, which is discussed above with respect to
At step 604, the first storage array 112A places a read-write lock on the first instance 113 of the volume 111. Step 604 may be performed in the same or similar manner as step 304, which is discussed above with respect to
At step 606, the first storage array 112A transmits to the second storage array 112B a second request to perform the atomic write operation on the second instance 115 of the volume 111. Step 606 may be performed in the same or similar manner as step 308, which is discussed above with respect to
At step 608, the first storage array 112A detects whether an error condition is present that is associated with the second request. Step 608 may be performed in the same or similar manner as step 310, which is discussed above with respect to
At step 610, the first storage array 112A attempts to store the data item associated with the first request in the first instance 113 of the volume 111. The data item may be stored at the address specified by the first request.
At step 611, the first storage array 112A determines if the attempt was successful. If the attempt was not successful, the process 600 proceeds to step 614. Otherwise, if the data item was successfully stored in the first instance 113 of the volume 111, the process 600 proceeds to step 612.
At step 612, the first storage array 112A releases the read-write lock (set at step 604), and transmits to the host device 122A an acknowledgment indicating that the first request has been executed successfully by the storage cluster 110A.
At step 614, the first storage array 112A retrieves a first data item that is stored, at the address specified by the first request, in the first instance 113 of the volume 111. Step 614 may be performed in the same or similar manner as step 314, which is discussed above with respect to
At step 616, the first storage array 112A retrieves from the second storage array 112B a second data item that is stored, at the address specified by the first request, in the second instance 115 of the volume 111. Step 616 may be performed in the same or similar manner as step 316, which is discussed above with respect to
At step 618, the first storage array 112A compares the first data item to the second data item to determine if they match. Step 618 may be performed in the same or similar manner as step 318, which is discussed above with respect to
At step 620, the first storage array 112A releases the read-write lock (set at step 604), and transmits to the host device 122A an error indicating the that the first request could not be executed successfully by the storage cluster 110A.
At step 622, the first storage array 112A writes the second data item, at the specified address, in the first instance 113 of the volume 111.
At step 624, the first storage array 112A releases the read-write lock (set at step 304), and transmits to the host device 122A an acknowledgment indicating the that the first request has been executed successfully by the storage cluster 110A.
The example of
As used in this application, the word “exemplary” is used herein to mean serving as an example, instance, or illustration. Any aspect or design described herein as “exemplary” is not necessarily to be construed as preferred or advantageous over other aspects or designs. Rather, use of the word exemplary is intended to present concepts in a concrete fashion.
Additionally, the term “or” is intended to mean an inclusive “or” rather than an exclusive “or”. That is, unless specified otherwise, or clear from context, “X employs A or B” is intended to mean any of the natural inclusive permutations. That is, if X employs A; X employs B; or X employs both A and B, then “X employs A or B” is satisfied under any of the foregoing instances. In addition, the articles “a” and “an” as used in this application and the appended claims should generally be construed to mean “one or more” unless specified otherwise or clear from context to be directed to a singular form.
To the extent directional terms are used in the specification and claims (e.g., upper, lower, parallel, perpendicular, etc.), these terms are merely intended to assist in describing and claiming the invention and are not intended to limit the claims in any way. Such terms do not require exactness (e.g., exact perpendicularity or exact parallelism, etc.), but instead it is intended that normal tolerances and ranges apply. Similarly, unless explicitly stated otherwise, each numerical value and range should be interpreted as being approximate as if the word “about”, “substantially” or “approximately” preceded the value of the value or range.
Moreover, the terms “system,” “component,” “module,” “interface,”, “model” or the like are generally intended to refer to a computer-related entity, either hardware, a combination of hardware and software, software, or software in execution. For example, a component may be, but is not limited to being, a process running on a processor, a processor, an object, an executable, a thread of execution, a program, and/or a computer. By way of illustration, both an application running on a controller and the controller can be a component. One or more components may reside within a process and/or thread of execution and a component may be localized on one computer and/or distributed between two or more computers.
Although the subject matter described herein may be described in the context of illustrative implementations to process one or more computing application features/operations for a computing application having user-interactive components the subject matter is not limited to these particular embodiments. Rather, the techniques described herein can be applied to any suitable type of user-interactive component execution management methods, systems, platforms, and/or apparatus.
While the exemplary embodiments have been described with respect to processes of circuits, including possible implementation as a single integrated circuit, a multi-chip module, a single card, or a multi-card circuit pack, the described embodiments are not so limited. As would be apparent to one skilled in the art, various functions of circuit elements may also be implemented as processing blocks in a software program. Such software may be employed in, for example, a digital signal processor, micro-controller, or general-purpose computer.
Some embodiments might be implemented in the form of methods and apparatuses for practicing those methods. Described embodiments might also be implemented in the form of program code embodied in tangible media, such as magnetic recording media, optical recording media, solid-state memory, floppy diskettes, CD-ROMs, hard drives, or any other machine-readable storage medium, wherein, when the program code is loaded into and executed by a machine, such as a computer, the machine becomes an apparatus for practicing the claimed invention. Described embodiments might also be implemented in the form of program code, for example, whether stored in a storage medium, loaded into and/or executed by a machine, or transmitted over some transmission medium or carrier, such as over electrical wiring or cabling, through fiber optics, or via electromagnetic radiation, wherein, when the program code is loaded into and executed by a machine, such as a computer, the machine becomes an apparatus for practicing the claimed invention. When implemented on a general-purpose processor, the program code segments combine with the processor to provide a unique device that operates analogously to specific logic circuits. Described embodiments might also be implemented in the form of a bitstream or other sequence of signal values electrically or optically transmitted through a medium, stored magnetic-field variations in a magnetic recording medium, etc., generated using a method and/or an apparatus of the claimed invention.
It should be understood that the steps of the exemplary methods set forth herein are not necessarily required to be performed in the order described, and the order of the steps of such methods should be understood to be merely exemplary. Likewise, additional steps may be included in such methods, and certain steps may be omitted or combined, in methods consistent with various embodiments.
As used throughout the disclosure, the term “storage system” may refer to one or more of: (i) a distributed storage system including a source system and a target system, (ii) the target system, or (iii) the source system.
Also, for purposes of this description, the terms “couple,” “coupling,” “coupled,” “connect,” “connecting,” or “connected” refer to any manner known in the art or later developed in which energy is allowed to be transferred between two or more elements, and the interposition of one or more additional elements is contemplated, although not required. Conversely, the terms “directly coupled,” “directly connected,” etc., imply the absence of such additional elements.
As used herein in reference to an element and a standard, the term “compatible” means that the element communicates with other elements in a manner wholly or partially specified by the standard, and would be recognized by other elements as sufficiently capable of communicating with the other elements in the manner specified by the standard. The compatible element does not need to operate internally in a manner specified by the standard.
It will be further understood that various changes in the details, materials, and arrangements of the parts which have been described and illustrated in order to explain the nature of the claimed invention might be made by those skilled in the art without departing from the scope of the following claims.
Patent | Priority | Assignee | Title |
Patent | Priority | Assignee | Title |
10007466, | Jun 29 2012 | EMC IP HOLDING COMPANY LLC | Tracking copy sessions |
10025843, | Sep 24 2014 | EMC IP HOLDING COMPANY LLC | Adjusting consistency groups during asynchronous replication |
10055161, | Mar 31 2014 | EMC IP HOLDING COMPANY LLC | Data reduction techniques in a flash-based key/value cluster storage |
10095428, | Mar 30 2016 | EMC IP HOLDING COMPANY LLC | Live migration of a tree of replicas in a storage system |
10152527, | Dec 28 2015 | EMC IP HOLDING COMPANY LLC | Increment resynchronization in hash-based replication |
10238487, | Aug 22 2008 | Edwards Lifesciences Corporation | Prosthetic heart valve and delivery apparatus |
10261853, | Jun 28 2016 | EMC IP HOLDING COMPANY LLC | Dynamic replication error retry and recovery |
10310951, | Mar 22 2016 | EMC IP HOLDING COMPANY LLC | Storage system asynchronous data replication cycle trigger with empty cycle detection |
10324635, | Mar 22 2016 | EMC IP HOLDING COMPANY LLC | Adaptive compression for data replication in a storage system |
10324640, | Jan 22 2018 | EMC IP HOLDING COMPANY LLC | Storage system with consistent initiation of data replication across multiple distributed processing modules |
10324806, | Apr 27 2017 | EMC IP HOLDING COMPANY LLC | Snapshot visualization for content-based storage |
10331350, | Apr 27 2017 | EMC IP HOLDING COMPANY LLC | Capacity determination for content-based storage |
10338851, | Jan 16 2018 | EMC IP HOLDING COMPANY LLC | Storage system with consistent termination of data replication across multiple distributed processing modules |
10359965, | Jul 28 2017 | EMC IP HOLDING COMPANY LLC | Signature generator for use in comparing sets of data in a content addressable storage system |
10374792, | Sep 29 2016 | EMC IP HOLDING COMPANY LLC | Layout-independent cryptographic stamp of a distributed dataset |
10394485, | Mar 29 2018 | EMC IP HOLDING COMPANY LLC | Storage system with efficient re-synchronization mode for use in replication of data from source to target |
10409520, | Apr 27 2017 | EMC IP HOLDING COMPANY LLC | Replication of content-based storage using address space slices |
10437855, | Jul 28 2017 | EMC IP HOLDING COMPANY LLC | Automatic verification of asynchronously replicated data |
10459632, | Sep 16 2016 | EMC IP HOLDING COMPANY LLC | Method and system for automatic replication data verification and recovery |
10459883, | Dec 30 2015 | EMC IP HOLDING COMPANY LLC | Retention policies for unscheduled replicas in backup, snapshots, and remote replication |
10466925, | Oct 25 2017 | EMC IP HOLDING COMPANY LLC | Compression signaling for replication process in a content addressable storage system |
10496324, | Mar 30 2018 | EMC IP HOLDING COMPANY LLC | Storage system with concurrent fan-out asynchronous replication using decoupled replication sessions |
10496489, | Nov 21 2017 | EMC IP HOLDING COMPANY LLC | Storage system configured for controlled transition between asynchronous and synchronous replication modes |
10496668, | Jun 28 2016 | EMC IP HOLDING COMPANY LLC | Optimized tender processing of hash-based replicated data |
10496672, | Dec 30 2015 | EMC IP HOLDING COMPANY LLC | Creating replicas at user-defined points in time |
10503609, | Apr 27 2017 | EMC IP HOLDING COMPANY LLC | Replication link smoothing using historical data |
10534547, | Dec 29 2015 | EMC IP HOLDING COMPANY LLC | Consistent transition from asynchronous to synchronous replication in hash-based storage systems |
10565058, | Mar 30 2016 | EMC IP HOLDING COMPANY LLC | Adaptive hash-based data replication in a storage system |
10613793, | Nov 01 2018 | EMC IP HOLDING COMPANY LLC | Method to support hash based xcopy synchronous replication |
11089105, | Dec 14 2017 | Pure Storage, Inc. | Synchronously replicating datasets in cloud-based storage systems |
5742792, | Apr 23 1993 | EMC Corporation | Remote data mirroring |
6496908, | May 18 2001 | EMC IP HOLDING COMPANY LLC | Remote mirroring |
6553464, | Mar 04 2001 | EMC IP HOLDING COMPANY LLC | Obtaining data from a remote storage device |
6640280, | Mar 04 2001 | EMC IP HOLDING COMPANY LLC | Obtaining data from a remote storage device using multiple jobs per device on RA |
6862632, | Nov 14 2001 | EMC IP HOLDING COMPANY LLC | Dynamic RDF system for transferring initial data between source and destination volume wherein data maybe restored to either volume at same time other data is written |
6883018, | Jan 24 2001 | EMC IP HOLDING COMPANY LLC | Scanning a message-list |
6886164, | May 08 2001 | EMC IP HOLDING COMPANY LLC | Selection of a resource in a distributed computer system |
6898685, | Mar 25 2003 | EMC IP HOLDING COMPANY LLC | Ordering data writes from a local storage device to a remote storage device |
6910075, | Nov 14 2001 | EMC IP HOLDING COMPANY LLC | Dynamic RDF groups |
6938122, | Jan 23 2001 | EMC IP HOLDING COMPANY LLC | Remote mirroring in a switched environment |
6944726, | Nov 14 2001 | EMC IP HOLDING COMPANY LLC | Distributed background track processing |
6968369, | Sep 27 2001 | EMC IP HOLDING COMPANY LLC | Remote data facility over an IP network |
6976139, | Nov 14 2001 | EMC IP HOLDING COMPANY LLC | Reversing a communication path between storage devices |
7000086, | Mar 25 2003 | EMC IP HOLDING COMPANY LLC | Virtual ordered writes |
7024525, | Nov 14 2001 | EMC Corporation | Distributed background track processing |
7032228, | Mar 01 2001 | EMC IP HOLDING COMPANY LLC | Common device interface |
7051176, | Mar 25 2003 | EMC IP HOLDING COMPANY LLC | Reading data provided to a remote storage device |
7054883, | Dec 01 2003 | EMC IP HOLDING COMPANY LLC | Virtual ordered writes for multiple storage devices |
7113945, | Apr 10 2002 | EMC IP HOLDING COMPANY LLC | Virtual storage device that uses volatile memory |
7114033, | Mar 25 2003 | EMC IP HOLDING COMPANY LLC | Handling data writes copied from a remote data storage device |
7174423, | Jan 23 2001 | EMC IP HOLDING COMPANY LLC | Remote mirroring in a switched environment |
7197616, | Mar 25 2003 | EMC IP HOLDING COMPANY LLC | Virtual ordered writes |
7228456, | Dec 01 2003 | EMC IP HOLDING COMPANY LLC | Data recovery for virtual ordered writes for multiple storage devices |
7240116, | Nov 14 2001 | EMC IP HOLDING COMPANY LLC | Dynamic RDF groups |
7292969, | Sep 27 2002 | EMC IP HOLDING COMPANY LLC | Method and system for simulating performance on one or more data storage systems |
7376651, | Apr 10 2002 | EMC Corporation | Virtual storage device that uses volatile memory |
7380082, | Mar 25 2003 | EMC IP HOLDING COMPANY LLC | Reading virtual ordered writes at local storage device |
7383385, | Jan 23 2001 | EMC IP HOLDING COMPANY LLC | Remote mirroring in a switched environment |
7383408, | Mar 25 2003 | EMC IP HOLDING COMPANY LLC | Storage device that uses virtual ordered writes |
7386668, | Mar 25 2003 | EMC IP HOLDING COMPANY LLC | Handling data writes copied from a remote data storage device |
7392360, | Sep 27 2002 | EMC IP HOLDING COMPANY LLC | Method and system for capacity planning and configuring one or more data storage systems |
7409470, | Nov 14 2001 | EMC IP HOLDING COMPANY LLC | Determining configuration data in connection with dynamic RDF |
7430589, | Sep 27 2001 | EMC IP HOLDING COMPANY LLC | Remote data facility over an IP network |
7577957, | Mar 04 2001 | EMC IP HOLDING COMPANY LLC | Multiple jobs per device that are linked via a device record for servicing by different adapters |
7613890, | Mar 31 2006 | EMC IP HOLDING COMPANY LLC | Consistent replication across multiple storage devices |
7617372, | Sep 28 2006 | EMC IP HOLDING COMPANY LLC | Avoiding copy on first write |
7702871, | Aug 31 2007 | EMC IP HOLDING COMPANY LLC | Write pacing |
7870195, | Jan 24 2001 | EMC IP HOLDING COMPANY LLC | Inter-processor messaging |
8046545, | Jan 03 2006 | EMC IP HOLDING COMPANY LLC | Continuous backup |
8078813, | Sep 30 2004 | EMC IP HOLDING COMPANY LLC | Triangular asynchronous replication |
8332687, | Jun 23 2010 | EMC IP HOLDING COMPANY LLC | Splitter used in a continuous data protection environment |
8335771, | Sep 29 2010 | EMC IP HOLDING COMPANY LLC | Storage array snapshots for logged access replication in a continuous data protection system |
8335899, | Mar 31 2008 | EMC IP HOLDING COMPANY LLC | Active/active remote synchronous mirroring |
8468180, | Dec 31 2010 | EMC IP HOLDING COMPANY LLC | Porting storage metadata |
8578204, | Dec 29 2010 | EMC IP HOLDING COMPANY LLC | Witness facility for distributed storage system |
8600943, | Dec 31 2010 | EMC IP HOLDING COMPANY LLC | Porting replication relationships |
8677087, | Jan 03 2006 | EMC IP HOLDING COMPANY LLC | Continuous backup of a storage device |
8694700, | Sep 29 2010 | EMC IP HOLDING COMPANY LLC | Using I/O track information for continuous push with splitter for storage device |
8706959, | Jun 30 2009 | EMC IP HOLDING COMPANY LLC | Virtual storage machine |
8719497, | Sep 21 2011 | EMC IP HOLDING COMPANY LLC | Using device spoofing to improve recovery time in a continuous data protection environment |
8732124, | Mar 26 2012 | EMC IP HOLDING COMPANY LLC | Multisite replication with coordinated cycle switching |
8782357, | Nov 14 2001 | EMC Corporation | Reversing a communication path between storage devices |
8812595, | Jan 24 2001 | EMC IP HOLDING COMPANY LLC | Scanning a message-list |
8825964, | Sep 26 2011 | EMC IP HOLDING COMPANY LLC | Adaptive integration of cloud data services with a data storage system |
8838849, | Dec 08 2011 | EMC IP HOLDING COMPANY LLC | Link sharing for multiple replication modes |
8862546, | Jun 30 2011 | EMC IP HOLDING COMPANY LLC | Virtual access roll |
8914596, | Dec 01 2003 | EMC IP HOLDING COMPANY LLC | Virtual ordered writes for multiple storage devices |
8966211, | Dec 19 2011 | EMC IP HOLDING COMPANY LLC | Techniques for dynamic binding of device identifiers to data storage devices |
8977826, | Dec 28 2011 | EMC IP HOLDING COMPANY LLC | Extent commands in replication |
9002904, | Dec 31 2010 | EMC IP HOLDING COMPANY LLC | Handling hibernation of a process on a storage device |
9009437, | Jun 20 2011 | EMC IP HOLDING COMPANY LLC | Techniques for shared data storage provisioning with thin devices |
9026492, | Mar 26 2012 | EMC IP HOLDING COMPANY LLC | Multisite replication with uncoordinated cycle switching |
9026696, | Sep 29 2010 | EMC IP HOLDING COMPANY LLC | Using I/O track information for continuous push with splitter for storage device |
9037816, | Nov 14 2001 | EMC IP HOLDING COMPANY LLC | Reversing a communication path between storage devices |
9037822, | Sep 26 2013 | EMC IP HOLDING COMPANY LLC | Hierarchical volume tree |
9100343, | Mar 29 2012 | EMC IP HOLDING COMPANY LLC | Storage descriptors and service catalogs in a cloud environment |
9110693, | Feb 17 2011 | EMC IP HOLDING COMPANY LLC | VM mobility over distance |
9304889, | Sep 24 2014 | EMC IP HOLDING COMPANY LLC | Suspending data replication |
9323750, | Sep 29 2010 | EMC IP HOLDING COMPANY LLC | Storage array snapshots for logged access replication in a continuous data protection system |
9342465, | Mar 31 2014 | EMC IP HOLDING COMPANY LLC | Encrypting data in a flash-based contents-addressable block device |
9378106, | Sep 26 2013 | EMC IP HOLDING COMPANY LLC | Hash-based replication |
9396243, | Jun 27 2014 | EMC IP HOLDING COMPANY LLC | Hash-based replication using short hash handle and identity bit |
9418131, | Sep 24 2013 | EMC IP HOLDING COMPANY LLC | Synchronization of volumes |
9483355, | Jun 29 2012 | EMC IP HOLDING COMPANY LLC | Tracking copy sessions |
9524220, | Dec 30 2011 | EMC IP HOLDING COMPANY LLC | Memory optimization for configuration elasticity in cloud environments |
9558083, | Sep 30 2004 | EMC IP HOLDING COMPANY LLC | Triangular asynchronous replication |
9606739, | Dec 01 2003 | EMC IP HOLDING COMPANY LLC | Virtual ordered writes for multiple storage devices |
9606870, | Mar 31 2014 | EMC IP HOLDING COMPANY LLC | Data reduction techniques in a flash-based key/value cluster storage |
9753663, | Oct 18 2011 | EMC IP HOLDING COMPANY LLC | Triangular asynchronous replication |
9959063, | Mar 30 2016 | EMC IP HOLDING COMPANY LLC | Parallel migration of multiple consistency groups in a storage system |
9959073, | Mar 30 2016 | EMC IP HOLDING COMPANY LLC | Detection of host connectivity for data migration in a storage system |
20080034172, | |||
20160110378, | |||
20180260125, | |||
20190243703, |
Executed on | Assignor | Assignee | Conveyance | Frame | Reel | Doc |
Sep 16 2020 | CHEN, XIANGPING | EMC IP HOLDING COMPANY LLC | ASSIGNMENT OF ASSIGNORS INTEREST SEE DOCUMENT FOR DETAILS | 053866 | /0714 | |
Sep 16 2020 | MEIRI, DAVID | EMC IP HOLDING COMPANY LLC | ASSIGNMENT OF ASSIGNORS INTEREST SEE DOCUMENT FOR DETAILS | 053866 | /0714 | |
Sep 23 2020 | EMC IP HOLDING COMPANY LLC | (assignment on the face of the patent) | / | |||
Nov 12 2020 | EMC IP HOLDING COMPANY LLC | Credit Suisse AG, Cayman Islands Branch | SECURITY AGREEMENT | 054591 | /0471 | |
Nov 12 2020 | Dell Products L P | Credit Suisse AG, Cayman Islands Branch | SECURITY AGREEMENT | 054591 | /0471 | |
Nov 13 2020 | EMC IP HOLDING COMPANY LLC | THE BANK OF NEW YORK MELLON TRUST COMPANY, N A , AS NOTES COLLATERAL AGENT | SECURITY INTEREST SEE DOCUMENT FOR DETAILS | 054475 | /0434 | |
Nov 13 2020 | Dell Products L P | THE BANK OF NEW YORK MELLON TRUST COMPANY, N A , AS NOTES COLLATERAL AGENT | SECURITY INTEREST SEE DOCUMENT FOR DETAILS | 054475 | /0434 | |
Nov 13 2020 | EMC IP HOLDING COMPANY LLC | THE BANK OF NEW YORK MELLON TRUST COMPANY, N A , AS COLLATERAL AGENT | SECURITY INTEREST SEE DOCUMENT FOR DETAILS | 054475 | /0609 | |
Nov 13 2020 | Dell Products L P | THE BANK OF NEW YORK MELLON TRUST COMPANY, N A , AS COLLATERAL AGENT | SECURITY INTEREST SEE DOCUMENT FOR DETAILS | 054475 | /0609 | |
Nov 01 2021 | Credit Suisse AG, Cayman Islands Branch | EMC IP HOLDING COMPANY LLC | RELEASE OF SECURITY INTEREST AT REEL 054591 FRAME 0471 | 058001 | /0463 | |
Nov 01 2021 | Credit Suisse AG, Cayman Islands Branch | Dell Products L P | RELEASE OF SECURITY INTEREST AT REEL 054591 FRAME 0471 | 058001 | /0463 | |
Mar 29 2022 | THE BANK OF NEW YORK MELLON TRUST COMPANY, N A , AS NOTES COLLATERAL AGENT | EMC IP HOLDING COMPANY LLC | RELEASE OF SECURITY INTEREST IN PATENTS PREVIOUSLY RECORDED AT REEL FRAME 054475 0523 | 060332 | /0664 | |
Mar 29 2022 | THE BANK OF NEW YORK MELLON TRUST COMPANY, N A , AS NOTES COLLATERAL AGENT | EMC IP HOLDING COMPANY LLC | RELEASE OF SECURITY INTEREST IN PATENTS PREVIOUSLY RECORDED AT REEL FRAME 054475 0434 | 060332 | /0740 | |
Mar 29 2022 | THE BANK OF NEW YORK MELLON TRUST COMPANY, N A , AS NOTES COLLATERAL AGENT | Dell Products L P | RELEASE OF SECURITY INTEREST IN PATENTS PREVIOUSLY RECORDED AT REEL FRAME 054475 0434 | 060332 | /0740 | |
Mar 29 2022 | THE BANK OF NEW YORK MELLON TRUST COMPANY, N A , AS NOTES COLLATERAL AGENT | EMC IP HOLDING COMPANY LLC | RELEASE OF SECURITY INTEREST IN PATENTS PREVIOUSLY RECORDED AT REEL FRAME 054475 0609 | 062021 | /0570 | |
Mar 29 2022 | THE BANK OF NEW YORK MELLON TRUST COMPANY, N A , AS NOTES COLLATERAL AGENT | Dell Products L P | RELEASE OF SECURITY INTEREST IN PATENTS PREVIOUSLY RECORDED AT REEL FRAME 054475 0609 | 062021 | /0570 | |
Mar 29 2022 | THE BANK OF NEW YORK MELLON TRUST COMPANY, N A , AS NOTES COLLATERAL AGENT | Dell Products L P | RELEASE OF SECURITY INTEREST IN PATENTS PREVIOUSLY RECORDED AT REEL FRAME 054475 0523 | 060332 | /0664 |
Date | Maintenance Fee Events |
Sep 23 2020 | BIG: Entity status set to Undiscounted (note the period is included in the code). |
Date | Maintenance Schedule |
Mar 22 2025 | 4 years fee payment window open |
Sep 22 2025 | 6 months grace period start (w surcharge) |
Mar 22 2026 | patent expiry (for year 4) |
Mar 22 2028 | 2 years to revive unintentionally abandoned end. (for year 4) |
Mar 22 2029 | 8 years fee payment window open |
Sep 22 2029 | 6 months grace period start (w surcharge) |
Mar 22 2030 | patent expiry (for year 8) |
Mar 22 2032 | 2 years to revive unintentionally abandoned end. (for year 8) |
Mar 22 2033 | 12 years fee payment window open |
Sep 22 2033 | 6 months grace period start (w surcharge) |
Mar 22 2034 | patent expiry (for year 12) |
Mar 22 2036 | 2 years to revive unintentionally abandoned end. (for year 12) |