WO2020069654A1

WO2020069654A1 - Method of handling snapshot creation request and storage device thereof

Info

Publication number: WO2020069654A1
Application number: PCT/CN2019/107808
Authority: WO
Inventors: Mandar Govind NANIVADEKAR; Vaiapuri RAMASUBRAMANIAM
Original assignee: Huawei Technologies Co., Ltd.
Priority date: 2018-10-01
Filing date: 2019-09-25
Publication date: 2020-04-09
Also published as: CN112805949B; CN112805949A

Abstract

Methods and devices for handling snapshot creation request at a source file system and a destination file system having a synchronous relationship with each other in a communication network is disclosed. The method comprises of, determining a throughput of successful input/output (IO) transactions acknowledged both by the source file system and the destination file system, and determining a future I/O transaction marker based on the throughput as determined. The future I/O transaction marker is indicative of the sequence number of a future I/O transaction which upon successfully cached in a primary cache of the first storage device is succeeded with a snapshot creation associated with a snapshot creation request pending with the source file system.

Description

METHOD OF HANDLING SNAPSHOT CREATION REQUEST AND STORAGE DEVICE THEREOF

TECHNICAL FIELD

The present subject matter described herein, in general, relates to the field of storage technologies, and data replication method in a storage system. More particularly, the present subject matter relates to snapshot handling and processing method applied to storage technologies employing data replication method.

BACKGROUND

To protect security of data as well as for providing business continuity solutions, storage vendors establish a remote disaster recovery center to implement remote data backup, so as to ensure that original data is not lost or damaged after a disaster (such as a fire and an earthquake) occurs, and to ensure that a key service resumes within an allowed time range, for example within 5 to 10 seconds, thereby reducing a loss caused by the disaster as much as possible. Current disaster recovery systems may include a 2 center disaster recovery system where disaster recovery is implemented by establishing two data centers which are interconnected by using a dedicated network, where an active data center is used to undertake a service of a user, and a passive data center is deployed to take over the service and the like of the active data center when a disaster occurs in the active data center without data loss or service interruption. Generally, the active and the passive data centers may be located at respective site A and site B separated by a distance of up to 200 km.

To store and protect data in the 2 center disaster recovery system, a synchronous replication environment may be employed where the data volumes at the two data centers at the respective sites are mirrored to each other. So under normal operation, a file system in the active data center at site A exports a Read- Write File System to a client, and in case of failure of the active data center at site A, the mirrored file system in the passive data center at site B will be made Read-Write File System and will start serving the client operations. The file system architecture is based on objects. Each file serves as an object and each file system is a collection of objects.

For data storage and processing methods in the synchronous replication environment, storage devices at the two data centers process the client services simultaneously, where the storage devices at the site A and the site B are always kept in a synchronized state. The input/output (IO) operations which are received from a host file system in the client device are received at the storage device at site A and the same IO operations are cloned at real time at the storage device at site B. It should be understood that in the described disaster recovery systems, the host file system is basically the source file system mounted on the client device. As such, the IO operations are successfully acknowledged back to the client only after successfully processing of the IO operations at both the storage devices at site A and site B, where the processing includes at least writing operation in a non-volatile cache of both the storage devices at site A and site B. The data centers operating in the synchronous replication environment support creation of snapshots.

A snapshot may be understood as a copy of a data set, and the copy includes an image of corresponding data at a particular time point (a start time point of copying) , or the snapshot may be understood as a duplicate of a data set at a time point. In the data storage system of the synchronous replication environment, the snapshot creation operation is provided both to mirrored data volumes at site A and at site B. Data in the snapshots is completely the same, so that the mirrored data volumes may roll back to a state of a time point (for example, a snapshot rollback of the mirrored data volume means that data at the two locations needs to roll back to the same state) . Because data of mirrored data volumes at the two locations are concurrent and the data changes at any time, snapshots finally are taken at the two locations may be inconsistent without a good cooperation mechanism. As such all the IO transactions which are part of the snapshot at site A should also be part of the corresponding snapshot at site B.

In prior-art solutions, the input/output (I/O) transactions from the client are blocked when a snapshot creation is triggered at both the data centers at site A and site B. At this stage, all the IO transactions are flushed to the respective non-volatile memories of the storage devices at site A and site B. Considering a site A and site B which may be separated by a distance up to 200 km at least, a typical latency of typical latency of 2-5 ms may be experienced for an IO transaction to be processed at site A with respect to site B. Moreover, completing taking snapshots needs a relatively long latency. Therefore, for a synchronous replication environment, blocking the IO transactions from the client for up to 5ms may significantly drop the file systems performances at the data centers, when a snapshot is to be created.

Thus, there is a need in the existing data storage solutions, to improve the performance of the storage systems while processing snapshot creation requests.

SUMMARY

This summary is provided to introduce concepts related to method and system for handling snapshot creation requests in a synchronous replication environment, and the related storage devices in a dedicated communication network in the system.

Accordingly, an aspect of the present invention is to provide a method of handling snapshot creation request at a source file system in a first storage device. The first storage device is in communication with a second storage device in a communication network. The source file system in the first storage device is a synchronous relationship with a destination file system in the second storage device in the communication network. The synchronous relationship herein implies that the source file system and the destination file system are in a synchronized state in real-time in a synchronous replication environment where any client input/output (IO) transaction received at the source file system in the first storage device is also cloned in real-time to the destination file system. The method comprises of determining a throughput of successful input/out (IO) transactions acknowledged both by the source file system and the destination file system, and determining a future I/O transaction marker based on the throughput as determined. The future I/O transaction marker is indicative of the sequence number of a future I/O transaction. The future IO transaction when successfully cached in a primary cache of the first storage device is succeeded with a snapshot creation associated with a snapshot creation request pending with the source file system. Further, the method comprises of creating the snapshot associated with the snapshot creation request pending at the source file system on successfully caching the future I/O transaction in the primary cache, wherein during the creating of the snapshot, an IO transaction received after the future IO transaction, is cached in a secondary cache of the first storage device.

Accordingly, another aspect of the present invention is to provide a method of handling snapshot creation request at a destination file system in a second storage device. The second storage device is a communication with a first storage device in a communication network. The destination file system in the second storage device is in a synchronous relationship with the source file system in the first storage device in the communication network. The method comprises of receiving a future input/output (IO) transaction marker from the first storage device, the future IO transaction is determined at the first storage device based on a throughput of successful IO transactions acknowledged both by the source file system and the destination file system. The future I/O transaction marker is indicative of the sequence number of a future I/O transaction. The future IO transaction when successfully cached in a primary cache of the second storage device is succeeded with a snapshot creation associated with a snapshot creation request pending with the destination file system. Further, the method comprises of creating a snapshot associated with the snapshot creation request pending at the destination file system on successfully caching the future I/O transaction in the primary cache of the second storage device, wherein during the creating of the snapshot, an IO transaction received after the future IO transaction, is cached in a secondary cache of the second storage device.

Accordingly, another aspect of the present invention is to provide a first storage device storing a source file system having a synchronous replication relationship with a destination file system in a second storage device, the first storage device and the second storage device in communication with each other in a communication network. The first storage device comprises of a first storage device storing a source file system having a synchronous replication relationship with a destination file system in a second storage device, the first storage device and the second storage device in communication with each other in a communication network. The first storage device comprises of a first storage controller, and a primary cache and a secondary cache. The first storage controller is configured to determine a throughput of successful input/output (IO) transactions acknowledged both by the source file system and the destination file system, determine a future I/O transaction marker based on the throughput as determined, wherein the future I/O transaction marker is indicative of the sequence number of a future I/O transaction. The future IO transaction when successfully cached in the primary cache of the first storage device is succeeded with a snapshot creation associated with a snapshot creation request pending with the source file system. Further, the first storage controller is configured to create the snapshot associated with the snapshot creation request pending at the source file system on successfully caching the future I/O transaction in the primary cache, wherein during the creating of the snapshot, an IO transaction received after the future IO transaction, is cached in the secondary cache of the first storage device.

Accordingly, yet another aspect of the present invention is to provide a second storage device storing a destination file system having a synchronous replication relationship with a source file system in a first storage device, the first storage device and the second storage device in communication with each other in a communication network. The second storage device comprises of a second storage controller, a primary cache, and a secondary cache. The second storage controller is configured to receive a future input/output (IO) transaction marker from the first storage device, the future IO transaction is determined at the first storage device based on a throughput of successful IO transactions acknowledged both by the source file system and the destination file system. The future I/O transaction marker is indicative of the sequence number of a future I/O transaction. The future IO transaction when successfully cached in a primary cache of the second storage device is succeeded with a snapshot creation associated with a snapshot creation request pending with the destination file system. Further, the second storage controller is configured to create a snapshot associated with the snapshot creation request pending at the destination file system on successfully caching the future I/O transaction in the primary cache, wherein during the creating of the snapshot, an IO transaction received after the future IO transaction, is cached in a secondary cache of the second storage device.

Other aspects and features of the present invention will become apparent to those ordinarily skilled in the art upon review of the following description of specific embodiments of the invention in conjunction with the accompanying figures.

BRIEF DESCRIPTION OF THE ACCOMPANYING DRAWINGS

The detailed description is described with reference to the accompanying figures. Apparently, the accompanying figures in the following description show merely some embodiments of the present disclosure.

Fig. 1A is a schematic diagram of an application scenario according to an embodiment of the present invention.

Fig. 1B is a schematic diagram of file system according to an embodiment of the present invention.

Fig. 2 illustrates a schematic structure of a storage device according to an embodiment of the present invention.

Fig. 3A illustrates a schematic representation of a sequence of a client IO transactions handled along with a snapshot creation request by a file system in a storage device, according to an embodiment of a related art.

Fig. 3B illustrates a schematic representation of a sequence of client IO transactions handled along with a snapshot creation request by respective file systems in two storage devices in a synchronous replication environment, according to an embodiment of the present invention.

Fig. 4 illustrates a schematic structure of a storage device according to an embodiment of the present invention.

Fig. 5 illustrates a schematic structure of a storage device according to an embodiment of the present invention.

Fig. 6 illustrates a method of handing snapshot creation request at a source file system in a first storage device according to an embodiment of the present invention.

Fig. 7 illustrates a method of handing snapshot creation request at a destination file system in a second storage device according to an embodiment of the present invention.

It is to be understood that the attached drawings are for purposes of illustrating the concepts of the invention and may not be to scale.

DETAILED DESCRIPTION OF THE PRESENT INVENTION

The invention can be implemented in numerous ways, as a process, an apparatus, a system, a computer-readable medium such as a computer readable storage medium or a computer network wherein program instructions are sent over optical or electronic communication links. In this specification, these implementations, or any other form that the invention may take, may be referred to as techniques. In general, the order of the steps of disclosed processes may be altered within the scope of the invention.

A detailed description of one or more embodiments of the invention is provided below along with accompanying figures that illustrate the principles of the invention. The invention is described in connection with such embodiments, but the invention is not limited to any embodiment. The scope of the invention is limited only by the claims and the invention encompasses numerous alternatives, modifications, and equivalents. Numerous specific details are set forth in the following description in order to provide a thorough understanding of the invention. These details are provided for the purpose of example and the invention may be practiced according to the claims without some or all of these specific details. For the purpose of clarity, technical material that is known in the technical fields related to the invention has not been described in detail so that the invention is not unnecessarily obscured.

In the following detailed description, numerous specific details are set forth in order to provide a thorough understanding of the invention. However, it will be understood by those skilled in the art that the present invention may be practiced without these specific details. In other instances, well-known methods, procedures, and components, modules, units and/or circuits have not been described in detail so as not to obscure the invention.

Although embodiments of the invention are not limited in this regard, discussions utilizing terms such as, for example, “processing, ” “computing, ” “calculating, ” “determining, ” “establishing” , “analyzing” , “checking” , or the like, may refer to operation (s) and/or process (es) of a computer, a computing platform, a computing system, or other electronic computing device, that manipulates and/or transforms data represented as physical (e.g., electronic) quantities within the computer's registers and/or memories into other data similarly represented as physical quantities within the computer's registers and/or memories or other information non-transitory storage medium that may store instructions to perform operations and/or processes.

Although embodiments of the invention are not limited in this regard, the terms “plurality” and “aplurality” as used herein may include, for example, “multiple” or “two or more” . The terms “plurality” or “aplurality” may be used throughout the specification to describe two or more components, devices, elements, units, parameters, or the like. Unless explicitly stated, the method embodiments described herein are not constrained to a particular order or sequence. Additionally, some of the described method embodiments or elements thereof can occur or be performed simultaneously, at the same point in time, or concurrently.

System and method for handling snapshot creation requests in a synchronized replication environment and storage devices thereof are disclosed in the present invention.

While aspects are described for system and method for a 2 center disaster recovery system, the present invention may be applied to a disaster recovery system with multiple data centers where the disaster recovery system may include two or more data centers. The various embodiments of the present invention are described in the context of the following exemplary systems and methods.

Henceforth, embodiments of the present disclosure are explained with the help of exemplary diagrams and one or more examples. However, such exemplary diagrams and examples are provided for the illustration purpose for a better understanding of the present disclosure and should not be construed as a limitation on the scope of the present disclosure.

Fig. 1 illustrates a schematic diagram of a typical application scenario of a 2 center disaster (2DC) recovery system, in accordance with an embodiment of the present invention. A 2DC disaster recovery system shown in Fig. 1 includes at least one host 100 and two data centers included at site 10 and site 12 respectively. The two data centers may be connected to each other in a dedicated communication network. The dedicated communication network may include, for example, a fiber or network cable in a star-shaped networking manner. The two data centers may perform data transmission with each other by using the IP (Internet Protocol) protocol or an FC (Fiber Channel) protocol. Further, the host 100 may communicate with the site 10 and/or the site 12 based on the Small Computer System Interface (SCSI) protocol or based on the Internet Small Computer System Interface (iSCSI) protocol, which is not limited herein. Further, the host 100 may access data from the data centers at site 10 and site 12 using NFS (Network File System Protocol) protocol or CIFS (Common Internet File System Protocol) protocol but is not limited herein.

The host 100 may include any computing device at the client end, which may also be referred to as the ‘client device 100’ . Such client device 100 may include a server, a desktop computer or an application server, or any other similar device known in current technologies. An operating system and other application programs may be installed in the client device 100. In accordance with an embodiment of the present invention, the client device 100 includes a file system 14, hereafter referred to as a ‘host file system 14’ , as illustrated in Fig. 1B. In accordance with the principals of disaster recovery solutions as well as business continuity solutions known in the related art, the host file system 100 is stored/backed-up in storage arrays at the two data centers as site 10 and site 12. An input/output (IO) transaction originating from the host file system 14 in the client device 100 may also be referred to as a client IO transaction and may include multiple operations corresponding to the host file system 14 which may include, for e.g., but are not limited to, a read/write operation, an updating operation, a creation operation, a deleting operation and like operations. Each client IO transaction may be of same or different sizes. Each client IO transaction has a Time Point (TP) value associated therewith. The TP value of the respective IO transaction may be maintained by the host file system 100 and is sent along with the client IO transaction when the respective IO transaction is to be written in a corresponding file system of the storage arrays at the site 10 and the site 12. The TP value is associated with a snapshot and is used to distinguish a snapshot from other snapshots. Whenever a snapshot command, also referred to as a snapshot creation request, is issued by the host file system 14 to the corresponding file system of the storage arrays at the site 10 and the site 12, the TP value is incremented. Therefore, the TP value is a direct indicator of a sequence of the snapshot creation requests issued by the host file system 14 in the client device 100. By way of an example, for a sequence of IO transactions, IO=1, IO=2, IO=3, IO=4, IO=5, IO=6, IO=7, IO=8, IO=9, if a first snapshot creation request is issued after IO=6 and before IO=7, the TP value of the IP transaction up to IO=6, i.e., for IO=1, IO=2, IO=3, IO=4, IO=5, shall be equal to 0. Accordingly, the TP value of the IO transaction after IO=6, i.e., for IO=7, IO=8, and IO=9 shall be equal to 1. Based on the TP value of a respective IO transaction or a group of IO transactions, a snapshot may be identified to which the respective IO transaction belongs to or the group of IO transaction belongs to. The use of the TP value associated with an IO transaction during storing, processing and handling of the snapshot creation requests, by the 2DC, in accordance with the embodiments of the present invention, shall become apparent in the foregoing disclosure.

In accordance with the embodiments of the present disclosure, the host 100 writes data from the host file system to the 2DC at the site 10 and the site 12. The 2DC at the site 10 and the site 12 may keep, using a synchronous replication technology, data stored at the site 10 and the site 12 synchronized in real time. For example, when the host file system, 14 writes data, i.e., the client IO transaction, to the site 10, the data center at the site 10 may simultaneously back-up data to the data center at the site 12. In another example, the host file system 14 may perform double-write on data, i.e., double-write the client IO transactions where the client IO is sent to both the data centers at the site 10 and the site 12 simultaneously in the synchronous replication environment. Both the data centers at the site 10 and the 12 process the client IO transactions received from the host file system 14 in the client device 100. When the IO transaction is successfully processed at the data center at the site 12, the same is acknowledged to the data center at the site 10. Only after receiving an acknowledgment from the data center at the site 12, the data center at the site 10 sends an acknowledgment to the client device 100. For example, when the host file system 14 performs a write data to the corresponding file systems in the data centers at the site 10 and the site 12, the host file system 14 receives a write success response from the data center at the site 10, only when the write data is successfully cached at both the site 10 and the site 12.

The data center at the site 10 may include a first storage device 102 and the data center at the site 12 may include a second storage device 104. The first storage device 102 and the second storage device 104 may be storage devices such as storage array or a server known in current technologies. For example, the first storage device 102 and the second storage device 104 may include a storage area network (SAN) array or may include a network attached storage (NAS) array. A specific form of a storage device is each data center is not limited in this embodiment of the present disclosure. It should be noted that all the methods in the embodiments of the present disclosure may be performed by the storage devices at the sites 10 and the site 12. In the application scenario shown in FIG. 1 the distance between the first storage device 102 and the second storage device 104 may be up to 200 km. The first storage device 102 and the second storage device may be in the same city or different cities, as long as the synchronous replication of the data between the first storage device 102 and the second storage device 104 can be implemented.

The first storage device 102 and the second storage device 104 form respective storage space at the site 10 and the site 12 for storing the host file system 14 of the client device 100. The storage space thus formed may include a respective file system corresponding to the host file system 14 in the client device 100. Fig. 1B illustrates a source file system 16 in the first storage device 102 and a destination file system 18 in the second storage device 104 where the source file system 16 and the destination file system 18 for the storage space for the replicated data corresponding to the host file system 14 in the client device 100. In accordance with the embodiments of the present invention, the source file system 16 and the destination file system 18 are said to be in a synchronous replication relationship with each other as they are formed synchronously in real-time. Although, the present invention has been described with relation to a file system forming the storage space for the host 100, a storage space in the storage devices should be understood to include multiple data volumes. The data volume may be a file system or a logical storage space formed by mapping a physical storage space. For example, the data volume may be a logical unit number (LUN) , or a file system, and the data volumes may be multiple.

In the described embodiment of the synchronous replication environment, the 2DC employed support creation of snapshots. Due to the nature of synchronous replication relationship between the source file system 16 in the first storage device 102 and the destination file system 18 in the second storage device 104, a snapshot creation request received from the host file system 14 in the client device 100 is applied both to the source file system 16 and the destination file system 18. ‘Snapshot’ used herein should be understood as different from the replication of the file systems described in the present disclosure. Data replication may be performed by using the snapshot view. However, in the context of the present invention, data replication at the second storage device 104 may be performed using other known operations. A snapshot creation request may be received from the host 100 to create a copy of the file system at the first storage device 102 and the second storage device 104. A snapshot is a fully usable copy of a specified collection of data, where the copy includes an image of corresponding data at a time point (a time point at which the copy begins) . The snapshot may be a duplicate of the data represented by the snapshot, or a replica of the data. When a snapshot creation is initiated, a state view may be created for a data volume at a creation moment, only data at the creation moment of the data volume can be seen by using the view, and modification (new data is written) to the data volume after the time point is not reflected in the snapshot view.

In accordance with the embodiments of the present disclosure, the first storage device 102 and the second storage device 104 continue receiving write operation, i.e., the incoming IO transactions sent by the host 100 even when a snapshot is being created. This poses certain challenges for the storage systems in a synchronous replication environment. It should be understood that a snapshot creation can happen at any time. The snapshot creation request and the IO transactions are not related. While the prior art storage solutions block the incoming IO transactions, and after creating the snapshot, unblock the incoming IO transactions, the storage devices in the present invention do not block the IO transactions. However, some of the IO transactions fall before in the current snapshot and some of the IO transactions fall after the next snapshot. The snapshot creation command is only sent to the source file system 16 from the host 100. The corresponding snapshot creation command also has to be sent to the destination file system 18 at the site 12 from the source file system 16 at the site 10.The destination file system 18 at the site 12 needs to interpret the snapshot creation command and create the snapshot only after all the IO transactions belonging to the earlier snapshot are written to its cache and not allow IO transactions belonging to the next snapshot to be written before the earlier snapshot is created. Therefore, it is important to ensure that the IO transactions which form part of the snapshot at the source file system 16 in the first storage device 102 also form part of the same snapshot at the destination file system 18 in the second storage device 104. Thus, in accordance with the disclosed embodiments of the synchronous replication environment, the IO transactions which form part of a snapshot creation request at the first storage device 102 consistently also form part of a snapshot creation request sent to the second storage device 104 so as not to affect the file system performance during the snapshot creation at the second storage device 104 and ensure that the snapshot creation is instantaneous. To this end, the solutions implemented in the present invention ensure that the exact IO transactions are written at the source file system 16 in the first storage device 102 and the destination file system 18 in the second storage device 104 before a snapshot gets created at both

sites

10 and 12 to avoid any inconsistency. If the snapshot creation request is received at the site 12 prior to some of the IO transaction which forms part of the snapshot corresponding to the snapshot creation request, these IO transactions will be failed to be processed. To understand the inconsistency which may appear at the

sites

10 and 12 when a snapshot is being created, reference is now made to Fig. 3A.

Fig. 3A illustrates an example situation where the incoming IO transactions which are a part of a snapshot corresponding to a snapshot creation request received at site 10 fall out of band when a snapshot creation request is received. ‘Out of band’ herein refers to those IO transactions whose time point (TP) are incremented due to a snapshots creation request. As illustrated in Fig. 3A, six IO transactions, 1, 2, 3, 4, 5, and 6, are received prior to a snapshot creation request which has a TP=0, i.e., no snapshot has been requested while these six IO transactions are received at site A. After the sixth IO transaction a snapshot creation is requested where the TP gets incremented, i.e., TP=1. The

IO transactions

7, 8 and 9 which fall after the snapshot creation request accordingly have a TP=1. The six IO transactions are therefore part of a first snapshot, say, for example, snapshot 1, at the site 10. According to the synchronous replication environment, the six IO transactions also have to a part of snapshot 1 at the site 12. The IO transactions which are received at the

sites

10, 12 are committed to a respective cache of the

storage devices

102, 104. Now, when while an IO transaction which is associated with TP=0 is in progress to the site 12, if it is delayed and reaches site 12 after the snapshot creation request, it will fail to get committed to the cache at the second storage device 104 because it will get incremented out-of-band. In the example shown in Fig. 3A, if the IO transactions numbered 4, 5 and 6 which are associated with TP=0 are delayed with respect to the snapshot creation request at the site 12, they will be rejected by the cache of the second storage device 104, as they will be increment out of the band. This may result in inconsistency between the site 10 and the site 12 and may affect the file system performance complying with the synchronous replication environment. Even if the failed IO transactions are re-tried with the new TP value, for example, see IO transactions, 4’ , 5’ , and ‘6’ in Fig, 3A, these will still not form part of the snapshot 1 and may only form part of the next snapshot. The present invention solves these problems in the existing scenario and ensures consistency in the IO transactions forming part of a corresponding snapshot at both

sites

10 and 12. The solutions provided by the present invention shall become apparent in the foregoing description.

FIG. 2 is a schematic structural diagram of a storage device 20 (for example, the storage device 102 and the storage device 104) according to an embodiment of the present disclosure. The storage device 20 shown in FIG. 2 is a storage array. As shown in FIG. 2, the storage device 20 may include a storage controller 200 and a disk array 214, where the disk array 214 herein is configured to provide a storage space and may include a redundant array of independent disks (RAID) or a disk chassis including multiple disks. There may be multiple disk arrays 214, and the disk array 214 includes multiple disks 216. The disk 216 is configured to store data. The disk array 214 is in communication connection with the controller 200 by using a communication protocol, for example, the SCSI Protocol, which is not limited herein.

It is understandable that the disk array 214 is merely an example of a storage in the storage system. In this embodiment of the present disclosure, data may also be stored by using a storage, for example, a tape library. It should be noted that the disk 216 is also merely an example of a memory for building the disk array 214. In an actual application, there may further be an implementation manner, for example, for building a disk array between cabinets including multiple disks. Therefore, in this embodiment of the present disclosure, the disk array 214 may also include a storage including a non-volatile storage medium such as a solid state disk (SSD) , a cabinet including multiple disks, or a server, which is not limited herein.

The storage controller 200 is a “brain” of the storage device 20, and mainly includes a processor 202, a cache 204, a memory 206, a communications bus (a bus for short) 210, and a communications interface 212. The processor 202, the cache 204, the memory 206, and the communications interface 212 communicate with each other by using the communications bus 210. It should be noted that, in this embodiment of the present disclosure, there may be one or more controllers 200 in the storage device 20. It is understandable that, when the storage device 20 includes at least two controllers 200, the stability of the storage device 20 may be improved.

The communications interface 212 is configured to communicate with the host 100, the disk 216, or another storage device.

The memory 206 is configured to store a program 208. The memory 206 may include a high-speed RAM memory, or may further include a non-volatile memory, for example, at least one magnetic disk storage. It is understandable that the memory 206 may be various non-transitory machine-readable media, such as a random access memory (RAM) , a magnetic disk, a hard disk drive, an optical disc, an SSD, or a non-volatile memory, that can store program code.

The program 208 may include program code, and the program code includes a computer operation instruction.

The cache 204 is a storage between the controller and the hard disk drive and has a capacity smaller than that of the hard disk drive but a speed faster than that of the hard disk drive. The cache 204 is configured to temporarily store data, for example, the received IO transactions from the host 100, or another storage device and temporarily store data read from the disk 216, so as to improve performance and reliability of the array. The cache 204 may be various non-transitory machine-readable media, such as a RAM, a ROM, a flash memory, or an SSD, that can store data, which is not limited herein. In accordance with an embodiment of the present invention, the cache 204

The processor 202 may be a central processing unit CPU or an application-specific integrated circuit ASIC (Application-Specific Integrated Circuit) or is configured as one or more integrated circuits that implement this embodiment of the present disclosure. An operating system and another software program are installed in the processor 202, and different software programs may be considered as different processing module, and have different functions, such as processing an input/output (I/O) request for the disk 216, performing another processing on data in the disk 216, or modifying metadata saved in the storage device 20. Therefore, the storage controller 200 can implement various data management functions, such as an IO operation, a snapshot, a mirroring, and replication. In this embodiment of the present disclosure, the processor 202 is configured to execute the program 208, and specifically, may perform relevant steps in the following method embodiments.

It is understandable that, in this embodiment of the present disclosure, hardware structures of the first storage device 102, and the second storage device 104 may be similar. The following describes in detail how the storage devices in this embodiment of the present disclosure specifically implement a handling method of the snapshot creation request.

Referring to Fig. 4, a first storage device 400 is illustrated where the first storage device 400 is configured to implement the handling method of the snapshot creation request in accordance with the embodiments of the present disclosure. It should be understood that the first storage device 400 includes the first storage device 102 (shown in Fig. 1) and the storage device 20 (shown in Fig. 2) and is part of the synchronous replication environment including another storage device (for example the storage device 104) where the file system at both the storage devices form a synchronous replication relationship with each other. As illustrated the first storage device 400 includes a first storage controller 402 (for example the storage controller 200) , a primary cache 404, a secondary cache 406, a sending unit 408 and a receiving unit 410.

The first storage controller 402 implements the processing of the incoming IO transaction from the host 100 and creates the snapshot of the file system in accordance with the teachings of the present disclosure. As described above, the source file system 16 is stored at the site 10 in the first storage device 400. The snapshot created is a time point copy of the source file system 16. The first storage controller 402 identifies a sequence number of each IO transaction received in the source file system 16 from the host 100, i.e., the host file system 14. For this purpose, the first storage controller 402 may employ a sequence no. generator 403 which may generate and assign a sequence no. to the each IO transaction received at the source file system 16. In one embodiment, the sequence no. generator 403 may generate and assign the sequence no. only when a snapshot is to be created or when a snapshot creation request is received at the source file system 16. Although, the sequences no. generator 403 is shown as a part of the first storage controller 402 in the embodiment shown in Fig. 4, the same should not be construed as limiting to the present invention and other modification may be possible.

On identifying the sequence no. of the received IO transactions at the source file system 16, the first storage controller 402 determines a throughput of successful IO transactions acknowledged both the by the source file system 16 in the first storage device 400 and a destination file system in a second storage device, where the source file system 16 and the destination file system (for example, the destination file system 18 of the second storage device 104) have a synchronous replication relationship. The first storage device 400 has to take into consideration that the IO transaction is committed to the respective cache at both the first storage device 400 and the second storage device (for example the second storage device 104) before it sends an acknowledgment to the host 100. The throughput of the successful IO transactions being determined by the first storage controller 402 reflects a total number of IO transactions successful per second. This number may also be referred to as write IO operations per second (IOPS) . By way of an example, a 40000 IOPS would indicate that 40000 write operations are being committed to the respective cache per second at both the source file system 16 and the destination file system 18. The throughput of the successful IO transactions may differ for different storage solutions, the number of file systems being exported, the current write workload, size of the memory buffer (8k, 16k) , latency being induced by the communication path between the host 100 and the

sites

10, 12.

Based on the throughput of the successful IO transactions as determined, the first storage controller 402 determines a future IO transaction marker. The future IO transaction marker is indicative of the sequence number of a future IO transaction which when committed to the cache of the first storage device 400, enables the first storage controller 402 to create a snapshot associated with a pending snapshot creation request received at an earlier point in time from the host 100. By way of an example, if a snapshot operation request is received at the source file system 16 when an IO transaction with sequence number X is in-flight or being processed at the first storage device 400, and a future IO transaction marker is determined to be X+ 200, then the snapshot creation shall be initiated by the first storage controller 402 only after committing all the IO transactions before X+200 ^th IO transaction and the X+200th IO transaction to its cache. In accordance with the present embodiment, all the IO transactions which fall before the X+200th IO transaction form part of a first snapshot and the X+200th IO transaction onwards, all the IO transactions form part of a second snapshot.

In one embodiment of the present invention, in case the number of IO transactions received at the source file system 16 at the first storage device 400 from the host 100 falls below a threshold, the first storage controller 402 may determine a waiting time associated with the snapshot creation request pending with the source file system 16, and on lapse of the waiting time, the first storage controller 402 initiates the creation of the snapshot associated with the request pending. This embodiment may apply to a situation when there is a sudden drop in incoming IO transactions from the host 100. So, the future IO transaction cannot be received and thus the snapshot may never be created. However, since the processing of the snapshot creation request has already been initiated in the source file system 16, the snapshot has to be created. In this case, a waiting time is determined or a pre-determined time-based boundary may be set, on the lapse of which the snapshot is created prior to receiving the future IO transaction.

In another embodiment, the first storage controller 402 may re-determine the throughput of successful IO transactions acknowledged both by the source file system 16 and the destination file system 18 in case the number of incoming Io transactions from the host 100 in the source file system 16 is reduced below a threshold. Based on the re-determined throughput of successful IO transactions, the future IO transactions marker may be determined.

In yet another embodiment, the first storage controller 402 re-determines the throughput of successful IO transactions in case the number of incoming IO transactions from the host 100 becomes so heavy, for example, that the IO transactions forming part of the first snapshot reach the destination file system 18 in the second storage device later than the snapshot creation request from the source file system 16 in the first storage device 400.

The primary cache 404 and the secondary cache 406 are associated with committing the IO transactions forming part of the first snapshot and the second snapshot, respectively. In one implementation, the primary cache 404 and the secondary cache 406 form separate partitions of the cache (for example, cache 204 shown in Fig. 2) of the first storage device 400. In another implementation, the primary cache 404 and the secondary cache 406, form two separate cache. The primary cache is configured to commit the IO transactions which are received from the host 100 prior to the IO transaction associated with the future IO transaction marker and the secondary cache is configured to commit the IO transactions which are received from the host 100 after the IO transaction associated with the future IO transaction marker until a snapshot is created. In the example above, all the IO transactions which fall up to the X+200th IO transaction are stored in the primary cache 404 and all the IO transactions which are received after X+200th IO transaction are stored in the secondary cache 406.

The first storage controller 400 processes the IO transactions cached in the secondary cache 406 after creating the snapshot for the IO transactions cached in the primary cache 404. In the present embodiment, the IO transactions stored in the secondary cache 406 are assigned an incremented TP value which is valid after the snapshot creation pertaining to the IO transactions present in the primary cache 404. Once the snapshot is created, the IO transactions stored in the secondary cache 406 are flushed without any performance delay. This means that the IO transactions committed to the secondary cache 406 are assigned a next valid TP value as the snapshot pertaining to the IO transactions in the primary cache has been created. Thus, there is no performance delay as the IO transactions with the next valid TP value are already present in the cache to be processed.

Referring back to Fig. 4, the first storage device 400 may include the sending unit 408 configured to communicate the future IO transaction marker to the second storage device (for example the second storage device 104) . In one implementation, the future IO transaction marker may be communicated to the second storage device by supplementing an information indicative of the future I/O transaction marker in a replicating IO transaction sent from the source file system in the first storage device to the destination file system in the second storage device. The replicating IO transaction may be a subsequent IO transaction received after the snapshot creation request at the source file system 16 from the host 100. By way of an example, if the snapshot creation request is received after the IO transaction with the sequence number 8, then the future IO transaction marker may be the IO with the sequence number 9. Accordingly, when the replicating IO transaction with sequence number 9 is written to the destination file system 18 in the second storage device, the indicator corresponding to the future IO transaction marker is supplemented along with said replicating IO transaction. The same is also illustrated in an example shown in Fig. 3B which shall be described later.

In another implementation, the future I/O transaction marker is communicated to the second storage device by sending a table from the first storage device 400 to the second storage device (for example the storage device 104) . The table includes the future I/O transaction marker and a time stamp, i.e., a TP value, corresponding to the snapshot creation request, wherein the table is sent upon receiving multiple snapshot creation requests at the source file system 16 in the first storage device 400. The table may comprise of a plurality of future IO transaction markers and a corresponding time stamp, each future IO transaction marker and the corresponding time stamp is associated with one of the multiple snapshot creations requests received at the source file system 16. Table 1 below illustrates one such example of the present embodiment.

In the above-illustrated example in Table 1, in the first row the time stamp value, i.e., TP=0 represents the IO transactions for a first snapshot, yet to be created, and the associated future IO transaction marker at IO=1344556. Further, in the second row the time stamp value, i.e. TP=1 represents the IO transactions for a second snapshot, yet to be created, and the associated future IO transaction marker at IO=1566778. For the third, fourth and fifth row, the snapshot creation requests have been received at the source file system 16 but the future IO transaction marker is yet to be determined. In one implementation, the table is sent with each replicating IO transaction from the source file system 16 to the destination file system 18. In another implementation, the table is sent with each replicating IO transaction from the source file system 16 to the destination file system 18, only when there is a snapshot creation request pending. Such table, in one example, is sent to the destination file system 18 with a replicating IO transaction and subsequent replication IO transactions when a snapshot creation request comes in at the source file system 16. Once an acknowledgment is received from the destination file system 18 regarding receipt of the table, the table need not be sent again by the sending unit 408. Further, in the example shown in Table 1 above, the last three rows may not be sent since they are placeholders for any future snapshot creation requests for which the future IO transaction marker has not been determined yet. In one further embodiment, when the snapshot is created both at the source file system 16 and the destination file system 18, and the acknowledgment regarding the creation of the snapshot at the destination file system 18 is received at the first storage device 400, the corresponding rows from the table can be removed. In accordance with the present embodiment of the present invention, both source file system 16 and the destination file system 18 may maintain a copy of the table.

The sending unit 408 may be further configured to communicate a revised or a determined future IO transaction marker in case the throughput of successful IO transactions is re-determined. The sending unit 408 may be further configured to communicate the waiting time as determined or the pre-determined time-based boundary as set by the first storage controller 402 in case the number of incoming IO transactions from the host 100 at the source file system 16 falls below a certain threshold.

Further, the first storage device 400 may include the receiving unit 410 configured to receive an acknowledgment from the second storage device (for example the second storage device 104) on successfully caching the incoming IO transactions at the second storage device. As described above, the IO transactions received at the second storage device is also referred to as replicating IO transactions. The replication IO transactions once successfully written to the cache of the second storage device are acknowledged to the first storage device which is received by the receiving unit 410.

Further, the receiving unit 410 is configured to receive a delivery delay communication from the second storage device (for example, the second storage device 104) , the delivery delay communication being associated with a delay in receiving the future IO transaction marker with respect to one or more intermediate IO transactions at the second storage device. ‘One or more intermediate IO transactions’ used herein refers to those IO transactions which form part of any subsequent snapshot creation request pending with the source file system 16 in the first storage device. This embodiment refers to a situation when the incoming IO transactions from the host 100 suddenly increase and the future IO transaction marker determined by the first storage controller 402 is still in-flight to the destination file system 18 at the second storage controller. In the meantime, the intermediate IO transactions which are received in future forming part of the next snapshot creation request are received prior to the future IO transaction marker at the destination file system 18. In such case, the acknowledgment from the destination file system 18 is delayed at the source file system 16. In this scenario, a delivery delay communication may be received at the receiving unit 410 of the first storage device 400 from the second storage device. Upon which, the first storage controller 402 may re-determine the future IO transaction marker.

Referring to Fig. 5, a second storage device 500 is illustrated where the second storage device 500 is configured to implement the handling method of the snapshot creation request in accordance with the embodiments of the present disclosure. The second storage device 500 is in communication with the first storage device 400 in a communication network and stores the destination file system 18 which is in a synchronous replication relationship with the source file system 16 in the first storage device 400. It should be understood that the second storage device 500 includes the second storage device 104 (shown in Fig. 1) and the storage device 20 (shown in Fig. 2) . As illustrated, the second storage device 500 includes a second storage controller 502 (for example the storage controller 200) , a primary cache 504, a secondary cache 506, a sending unit 508 and a receiving unit 510.

The second storage controller 502 implements the processing of the incoming replicating IO transaction received from the host 100 or the source file system 16 and creates the snapshot in accordance with the teachings of the present disclosure. The snapshot thus created is a time point copy of the destination file system 18. The second storage controller 502 identifies a sequence number of each replicating IO transaction received in the destination file system 18. For this purpose, the second storage controller 502 may rely upon the sequence no. of the IO transaction identified at the first storage device 400 where it may have been determined using the sequence no. generators 403. Accordingly, in one embodiment, the sequence no. of the IO transaction may be sent to the second storage device 500 via the sending unit 408 of the first storage device 400 which may be subsequently received by the receiving unit 510 of the second storage device. In an alternate embodiment, the second storage controller may employ a sequence no. generator 503 (shown in dotted lines) which may be employed to generate and assign a sequence no. to the each IO transaction received at the destination file system 18. In one embodiment, the sequence no. generator 503 may generate and assign the sequence no. only when a snapshot is to be created or when a snapshot creation request is received at the destination file system 18. Although, the sequences no. generator 503 is shown as a part of the second storage controller 502 using dotted lines in the embodiment shown in Fig. 5, the same should not be construed as limiting to the present invention and other modification may be possible.

Further, the second storage controller 502 receives the future IO transaction marker from the first storage controller 400 which determines the future IO transaction marker based the throughput of successful IO transactions acknowledged both by the source file system 16 in the first storage device 400 and the destination file system 18 in the second storage device 500. In this regard, the second storage controller 502 may receive the future IO transaction marker via the receiving unit 510 which may, in turn, receive the future IO transaction marker from the sending unit 408 of the first storage device 400. As described earlier, the receiving unit 510 may receive the future IO transaction marker in form of an indicator on a replication IO transaction and/or in the form of the table and communicate the same to the second storage controller 502. The future IO transaction marker is indicative of the sequence number of a future IO transaction which when committed to the cache of the second storage device 500, enables the second storage controller 502 to create a snapshot associated with a pending snapshot creation request pending at the destination file system 18. In the example described above, if the future IO transaction marker is determined to be X+ 200, then the snapshot creation shall be initiated by the second storage controller 502 only after committing all the IO transactions before X+200 ^th IO transaction and the X+200th IO transaction to its cache. In accordance with the present embodiment, all the IO transactions which fall before the X+200th IO transaction form part of a first snapshot and the X+200th IO transaction onwards, all the IO transactions form part of a second snapshot. Thus, the IO transactions which form part of a snapshot at the site 10 and the replicating IO transactions which form part of the corresponding snapshot at the site 12 are exact and same. In accordance with the present embodiment, the snapshot creation at the site 10, i.e., at the source file system 16 in the first storage device 400 and the snapshot creation at the site 12, i.e., at the destination file system 18 in the second storage device 500 are asynchronous with respect to each other. This means that the snapshot creation at the site 10 in the first storage device 400 and the snapshot creation at the site 12 in the second storage device 500 may not happen at the same point in time. Therefore, the source file system 16 may create its own snapshot as soon as the future IO transaction associated with the future IO transaction marker is committed to its cache, and the destination file system 18 will create its own snapshot when the same future IO transaction is committed to its own cache but the instant will be different because of latency between the first storage device 400 at the site 10 and the second storage device 500 at the site 12.

In one embodiment of the present invention, in case the number of IO transactions received at the source file system 16 at the first storage device 400 from the host 100 falls below a threshold, the second storage controller 502 receives the waiting time associated with the snapshot creation request pending with the destination file system 18, from the first storage device 400. The waiting time is determined by the first storage controller 402 and is communicated via its sending unit 408 to the receiving unit 510 of the second storage device 500. On the lapse of the waiting time, the second storage controller 502 initiates the creation of the snapshot associated with the request pending. Similarly, the predetermined time-based boundary may be set by the first storage controller 402 may be communicated to the second storage controller 502, via the respective sending unit 408 and the respective receiving unity 510. On lapse of the predetermined time-based boundary, the snapshot is created prior to receiving the future IO transaction. The waiting time and the predetermined time-based boundary is communicated when there is a sudden drop in incoming IO transactions from the host 100 as described above.

Further, in case the first storage controller 402 re-determines the throughput of successful IO transaction and re-determines the future IO transaction marker, the same is received via the receiving unit 510 of the second storage device 500, and the second storage controller 502 accordingly uses the same to identify the future IO transaction which when cached, is succeeded with the snapshot creation request pending with the destination file system 18 in the second storage device 500.

The primary cache 504 and the secondary cache 506 are associated with committing the IO transactions forming part of the first snapshot and the second snapshot, respectively. In one implementation, the primary cache 504 and the secondary cache 506 form separate partitions of the cache (for example, cache 204 shown in Fig. 2) of the second storage device 500. In another implementation, the primary cache 504 and the secondary cache 506, are form two separate cache. The primary cache 504 is configured to commit the replicating O transactions which are received at the destination file system 18 prior to the future IO transaction associated with the future IO transaction marker and the secondary cache 506 is configured to commit the IO transactions which are received at the destination file system 18 after the future IO transaction associated with the future IO transaction marker until a snapshot is created. In the example described above, all the IO transactions which fall up to the X+200th IO transaction are stored in the primary cache 504 and all the IO transactions which are received after X+200th IO transaction are stored in the secondary cache 506.

Fig. 3B illustrates an example of handling a snapshot creation request at the second storage device 500 based on a received future IO transaction marker from the first storage device 400. The example is shown in Fig. 3B includes a schematic representation of a sequence of client IO transactions handled along with a snapshot creation request by respective file systems in the two storage devices in a synchronous replication environment, according to an embodiment of the present invention. As shown in Fig. 3B, two sites, site A (which may include, for example, the site 10 where the first storage device 400 is located) and site B (which may include, for example, the second storage device 500 where the second storage device 500 is located) , form the two sites of the 2DC storage systems. The site A and the site B receive IO transactions sequentially numbered from 1 to 17, as depicted from a host (for example, the host 100) . Further, a snapshot creation request is received after the IO transaction with sequence no. 8, as depicted. In the example shown in Fig. 3B, the future IO transaction marker is 14, i.e., after committing the IO transaction with sequence no. 14 in the cache, which may include, for example, the primary cache 404, the snapshot will be created at the site A for all the IOP transactions up to the IO transaction with sequence no. 14. Accordingly, IO transactions up to the IO transaction with sequence no. 14 are indicated with a TP=0, i.e., falling within the first snapshot. The IO transactions with sequence no. from 15 to 17 which fall after the IO transaction with sequence no. 14, fall within any subsequent snapshot which may be created on receiving any subsequent IO transaction and are thus indicated with TP=1. Such IO transactions are committed to a second block of cache indicated as ‘future IO stored in cache’ . The second block of the cache may include, for example, the secondary cache 406. The IO transactions falling in the second block of cache will be committed after all the transactions in the cache with TP=0 are processed and on the creation of the snapshot under which they fall.

The above snapshot handling method applied to site A is also applied to site B. It is to be noted that the future IO transaction marker is communicated from the site A to the site B by sending a piggybank on the subsequent replicating IO transaction with sequence number 9 which falls immediately after the snapshot creation request. The IO transactions which are in the second block indicated ‘future IO stored in cache’ are not actually committed to the cache because they fall after the future Io transaction marker. After the snapshot is created, these IO transactions can be immediately committed to the cache with an incremented TP. So even when they are not really being committed to cache, these future IO transactions are acknowledged back to the host as at some point they will be committed to cache and they will not be lost.

The second storage controller 502 processes the IO transactions cached in the secondary cache 506 after creating the snapshot for the IO transactions cached in the primary cache 504. Once the snapshot is created, the IO transactions stored in the secondary cache 506 are flushed without any performance delay. On processing the IO transactions in the secondary cache 506, the sending unit 508 of the second storage device 500 sends an acknowledgment to the first storage device 400.

Further, the sending unit 508 is also is configured to send the delivery delay communication to the first storage device 400 when there is a delay in receiving the future IO transaction marker with respect to the one or more intermediate IO transactions at the second storage device 400.

The

storage systems

400 and 500 of the present disclosure may execute the methods of handling the snapshot creation requests as described above in the disclosed embodiments of the synchronous replication environment. The embodiments of the

storage systems

400 and 500 have been explained only in relation to the methods of handling the snapshot creation requests at the respective site 10 and the respective site 12. Details with respect to other functions of these units which are apparent to a person skilled in the art have not been described. It is understandable that the embodiments shown in Figs. 4 and 5 are merely exemplary. For example, the controller is merely logical function division and maybe other division in actual implementation. For example, a plurality of modules or components may be combined or integrated into another device, or some features may be ignored or not performed. In addition, the displayed or discussed mutual couplings or direct couplings or communication connections may be implemented by using some communications interfaces. The indirect couplings or communication connections between the units and the controller may be implemented in electronic, mechanical, or other forms.

Fig. 6 illustrates a method 600 of handling snapshot creating request received at the source file system 16 in the first storage device 400, in accordance with an embodiment of the present invention.

At step 602, the sequence number of each IO transaction received at the source file system 16 in the first storage device 400 from the host 100 is identified. In one embodiment, the sequence number of the IO transactions is generated and assigned to the respective IO transaction after receiving the snapshot creation request at the source file system 16 in the first storage device 400 from the host 100.

At step 604, the throughput of successful IO transactions acknowledged both by the source file system 16 and the destination file system 18 is determined.

At step 606, the future I/O transaction marker based on the throughput is determined, wherein the future I/O transaction marker is indicative of the sequence number of the future I/O transaction which upon successfully cached in a primary cache 404 of the first storage device 400 is succeeded with a snapshot creation associated with a snapshot creation request pending with the source file system 16. In one embodiment, if a number of the IO transactions received at the source file system 16 in the first storage device 400 is reduced below a threshold, the method 600 comprises of determining a waiting time associated with the snapshot creation request pending with the source file system 16. On the lapse of the waiting time, the method further comprises of initiating the creating the snapshot associated with the snapshot creation request prior to receipt of the future IO transaction. In another embodiment, if the number of the IO transactions received at the source file system 16 in the first storage system 400 is reduced below a threshold, the method 600 comprises of redetermining the throughput of successful IO transactions, acknowledged both by the source file system 16 and the destination file system 18. Based on the re-determined throughput of successful IO transactions, the future IO transactions is determined again.

On successfully caching the future I/O transaction in the primary cache, at step 608, the snapshot associated with the snapshot creation request pending at the source file system 16 is created. During the creating of the snapshot, an IO transaction received after the future IO transaction is cached in the secondary cache 406 of the first storage device 400.

The method 600 further comprises of communicating the future I/O transaction marker as determined to the second storage device 500.

In a further embodiment, the method 600 may further comprise of receiving the delivery delay communication from the second storage device 500 based on which the method 600 comprises of re-determining the future I/O transaction marker.

The method 600 further comprises of processing the IO transaction cached in the secondary cache 406 of the first storage device on creating the snapshot. The processing of the IO transactions in the secondary cache 406 may include committing the same I0 transactions to the primary cache 404 with an incremented TP value. The method 600 may further comprise of sending an acknowledgment to the host 100 on successfully committing these IO transactions to the primary cache 404. In one embodiment, the method 600 may include receiving an acknowledgment of processing of the same IO transactions at the second storage device 500 before sending an acknowledgment to the host 100. Further, the processing of the IO transactions at the first storage device 400 may include receiving an acknowledgment from the second storage device 500 regarding the processing of the same IO transactions.

In accordance with an embodiment of the present invention, the method 600 may further comprise of a storing all the transaction log details corresponding to the IO transactions received after the future IO transaction associated with the IO transaction marker in an assigned memory area of the first storage device 400. In case of any node failure of the data center including the first storage device 400 at the site 10, while an IO transaction in in-progress, the stored transaction log details of the IO transactions may be used to understand the state when the failure occurred based on which recovery mechanism of the node can be undertaken.

Fig. 7 illustrates a method 700 of handling snapshot creation request received at the source file system 16 in the second storage device 500, in accordance with an embodiment of the present invention.

At step 702, the sequence number of each IO transaction received at the destination file system 18 in the second storage device 500 is identified. In one embodiment, the sequence number of the IO transactions is received from the first storage device 400. In another embodiment the IO transaction may be generated at the second storage device 500. Further, if generated, the IO transaction is assigned to the respective IO transaction only after receiving the snapshot creation request at the destination file system 18 in the second storage device 500.

At step 704, the future IO transaction marker is received from the first storage device 400, the future IO transaction is determined at the first storage device 400 based on the throughput of successful IO transactions acknowledged both by the source file system 16 and the destination file system 18. The future I/O transaction marker is indicative of the sequence number of a future I/O transaction which upon successfully cached in the primary cache 504 of the second storage device 500 is succeeded with a snapshot creation associated with a snapshot creation request pending with the destination file system 18.

At step 706, a snapshot associated with the snapshot creation request pending at the destination file system 18 is created on successfully caching the future I/O transaction in the secondary cache 506. During the creating of the snapshot, an IO transaction received after the future IO transaction is cached in the secondary cache 506 of the second storage device 500.

In one embodiment, if a number of the IO transactions received at the source file system 16 in the first storage device 400 is reduced below a threshold, the method 700 comprises of receiving a waiting time associated with the snapshot creation request pending with the source file system 16, determined at the first storage device 400. On the lapse of the waiting time, the method 700 further comprises of initiating the creating the snapshot associated with the snapshot creation request prior to receipt of the future IO transaction. In another embodiment, if the number of the IO transactions received at the source file system 16 in the first storage system 400 is reduced below a threshold, the method 700 comprises of receiving a future IO transaction marker based on a redetermined throughput of successful IO transactions at the first storage device 400.

In a further embodiment, the method 700 may further comprise of sending the delivery delay communication to the first storage device 400.

The method 700 further comprises processing the IO transaction cached in the secondary cache 506 of the second storage device 500 on creating the snapshot. The processing of the IO transactions in the secondary cache 506 may include committing the same I0 transactions to the primary cache 504 with an incremented TP value. The method 600 may further comprise of sending an acknowledgment to the first storage device 400 on successfully committing these IO transactions to the primary cache 504.

In accordance with an embodiment of the present invention, the method 700 may further comprise of a storing all the transaction log details corresponding to the IO transactions received after the future IO transaction associated with the IO transaction marker in an assigned memory area of the second storage device 500. In case of any node failure of the data center including the first storage device 500 at the site 12, while an IO transaction in in-progress, the stored transaction log details of the IO transactions may be used to understand the state when the failure occurred based on which recovery mechanism of the node can be undertaken.

A person skilled in the art may understand that any known or new algorithms to be used for the implementation of the present invention. However, it is to be noted that, the present invention provides a method to achieve the above-mentioned benefits and technical advancement irrespective of using any known or new algorithms.

A person of ordinary skill in the art may be aware that in combination with the examples described in the embodiments disclosed in this specification, units and algorithm steps may be implemented by electronic hardware or a combination of computer software and electronic hardware. Whether the functions are performed by hardware or software depends on the particular inventions and design constraint conditions of the technical solution. A person skilled in the art may use different methods to implement the described functions for each particular invention, but it should not be considered that the implementation goes beyond the scope of the present invention.

In the several embodiments provided in the present invention, it should be understood that the disclosed system and method may be implemented in other manners. For example, the described apparatus embodiment is merely exemplary. For example, the unit division is merely logical function division and maybe other division in actual implementation. For example, a plurality of units or components may be combined or integrated into another system, or some features may be ignored or not performed. In addition, the displayed or discussed mutual couplings or direct couplings or communication connections may be implemented through some interfaces. The indirect couplings or communication connections between the apparatuses or units may be implemented in electronic, mechanical, or other forms.

When the functions are implemented in a form of a software functional unit and sold or used as an independent product, the functions may be stored in a computer-readable storage medium. Based on such an understanding, the technical solutions of the present invention essentially, or the part contributing to the prior art, or a part of the technical solutions may be implemented in a form of a software product. The computer software product is stored in a storage medium and includes several instructions for instructing a computer node (which may be a personal computer, a server, or a network node) to perform all or a part of the steps of the methods described in the embodiment of the present invention. The foregoing storage medium includes any medium that can store program code, such as a USB flash drive, a removable hard disk, a read-only memory (Read-Only Memory, ROM) , a random access memory (Random Access Memory, RAM) , a magnetic disk, or an optical disc.

Devices that are in communication with each other need not be in continuous communication with each other, unless expressly specified otherwise. In addition, devices that are in communication with each other may communicate directly or indirectly through one or more intermediaries.

When a single device or article is described herein, it will be readily apparent that more than one device/article (whether or not they cooperate) may be used in place of a single device/article. Similarly, where more than one device or article is described herein (whether or not they cooperate) , it will be readily apparent that a single device/article may be used in place of the more than one device or article or a different number of devices/articles may be used instead of the shown number of devices or programs. The functionality and/or the features of a device may be alternatively embodied by one or more other devices which are not explicitly described as having such functionality/features. Thus, other embodiments of the invention need not include the device itself.

Although implementations for system and method for handling snapshot creation requests in storage solutions in a synchronized replication environment have been described in language specific to structural features and/or methods, it is to be understood that the appended claims are not necessarily limited to the specific features or methods described. Rather, the specific features and methods are disclosed as examples of implementations of the handling method of snapshot creation request system in storage systems employing replication methods for storing data.

Claims

A method of handling snapshot creation request at a source file system in a first storage device in a communications network, the source file system having a synchronous replication relationship with a destination file system in a second storage device in the communication network, the method comprising:

determining a throughput of successful input/output (IO) transactions acknowledged both by the source file system and the destination file system;

determining a future I/O transaction marker based on the throughput as determined, wherein the future I/O transaction marker is indicative of a sequence number of a future I/O transaction;

creating a snapshot associated with a snapshot creation request pending at the source file system on successfully caching the future I/O transaction in a primary cache of the first storage device;

wherein during the creation of the snapshot, an IO transaction received after the future IO transaction, is cached in a secondary cache of the first storage device.
The method as claimed in claim 1 comprising identifying a sequence number of each IO transaction received at the source file system in the first storage device from a host file system in the client device.
The method as claimed in claim 2 wherein the sequence number of the each IO transaction is generated and assigned to the respective IO transaction after receiving a snapshot creation request at the source file system in the first storage device from the host file system in the client device.
The method as claimed in claim 1 wherein if a number of the IO transactions received at the source file system in the first storage device is reduced below a threshold, the method comprising:

determining a waiting time associated with the snapshot creation request pending with the source file system;

on lapse of the waiting time, initiating the creation of the snapshot associated with the snapshot creation request prior to receipt of the future IO transaction.
The method as claimed in claim 1 comprising communicating the future I/O transaction marker as determined to the second storage device to enable the destination file system in the second storage device to create a snapshot associated with a snapshot creation request received at the destination file system in the second storage device.
The method as claimed in claim 5 wherein the future I/O transaction marker is communicated to the second storage device by supplementing an information indicative of the future I/O transaction marker in a replicating IO transaction received at the destination file system in the second storage device.
The method as claimed in claim 6 wherein the replicating IO transaction corresponds to a subsequent IO transaction received after the snapshot creation request at the source file system in the first storage device.
The method as claimed in claim 5 wherein the future I/O transaction marker is communicated to the second storage device by sending a table from the first storage device to the second storage device, the table including at least the future I/O transaction marker and a time stamp corresponding to the snapshot creation request, wherein the table is sent upon receiving multiple snapshot creation requests at the source file system in the first storage device.
The method as claimed in claim 8 wherein the table comprises of a plurality of future IO transaction markers and a corresponding time stamp, each future IO transaction marker of the plurality of future IO transaction markers, and the corresponding time stamp, being associated with one of the multiple snapshot creations requests received at the source file system in the first storage device.
The method as claimed in claim 5 wherein the creation of the snapshot, associated with the snapshot creation request received at the destination file system in the second storage device is asynchronous to the creation of the snapshot at the source file system in the first storage device.
The method as claimed in claim 5 further comprising re-determining the future I/O transaction marker on receiving a delivery delay communication from the second storage device, the delivery delay communication being associated with a delay in receiving the future IO transaction marker at the second storage device.
The method as claimed in claim 1 wherein one or more IO transactions cached in the primary cache form part of the snapshot created and one or more IO transactions cached in the secondary cache form part of any subsequent snapshot created on receiving a corresponding subsequent snapshot creation request at the source file system.
The method as claimed in claim 1 wherein on creating the snapshot associated with the snapshot creation request, the method comprising processing the IO transaction cached in the secondary cache.
The method as claimed in claim 13 wherein the processing of the IO transaction cached in the secondary cache comprises receiving from the second storage device an acknowledgment of processing of replicating IO transactions in the second storage device on successful creation of the snapshot at the second storage device.
A method of handling snapshot creation requests at a destination file system in a second storage device in a communications network, the destination file system having a synchronous replication relationship with a source file system in a first storage device in the communication network, the method comprising:

receiving a future IO transaction marker from the first storage device, the future IO transaction being determined at the first storage device based on a throughput of successful input/output (IO) transactions acknowledged both by the source file system and the destination file system;

wherein the future I/O transaction marker is indicative of a sequence number of a future I/O transaction;

creating a snapshot associated with a snapshot creation request pending at the destination file system on successfully caching the future I/O transaction in a primary cache of the second storage device;

wherein during the creation of the snapshot, an IO transaction received after the future IO transaction, is cached in a secondary cache of the second storage device.
The method as claimed in claim 15 comprising receiving a waiting time associated with the snapshot creation request pending at the destination file system from the first storage device, when a number of the IO transactions received at the source file system in the first storage device is reduced below a threshold, the method further comprising on lapse of the waiting time, initiating the creating of the snapshot prior to receipt of the future IO transaction.
The method as claimed in claim 15 wherein the future I/O transaction marker is received from the first storage device in form of an information indicative of the future I/O transaction marker supplemented in a replicating IO transaction received from the source file system in the first storage device at the destination file system in the second storage device.
The method as claimed in claim 17 wherein the replicating IO transaction corresponds to a subsequent IO transaction received after the snapshot creation request at the source file system in the first storage device.
The method as claimed in claim 15 wherein the method comprising receiving a table at the second storage device sent from the first storage device, the table including at least the future I/O transaction marker and a time stamp corresponding to the snapshot creation request, wherein the table is sent upon receiving multiple snapshot creation requests at the source file system in the first storage device.
The method as claimed in claim 19 wherein the table comprises of a plurality of future IO transaction markers and a corresponding time stamp, each future IO transaction marker of the plurality of future IO transaction markers, and the corresponding time stamp, being associated with one of the multiple snapshot creations requests received at the source file system in the first storage device.
The method as claimed in claim 15 wherein the creation of the snapshot associated with the snapshot creation request received at the destination file system in the second storage device is asynchronous to a creation of a snapshot associated with a snapshot creation request at the source file system in the first storage device.
The method as claimed in claim 15 comprising communicating a delivery delay communication to the first storage device, the delivery delay communication being associated with a delay in receiving the future IO transaction marker at the second storage device.
The method as claimed in claim 15 wherein one or more IO transactions cached in the primary cache form part of the snapshot created and one or more IO transactions cached in the secondary cache form part of any subsequent snapshot created on receiving a corresponding subsequent snapshot creation request at the destination file system.
The method as claimed in claim 15 wherein on creating the snapshot associated with the snapshot creation request, the method comprising processing the IO transaction cached in the secondary cache.
The method as claimed in claim 24 comprising communicating to the first storage device, an acknowledgment of processing the IO transaction cached in the secondary cache on the successful creation of the snapshot at the destination file system.
A first storage device storing a source file system having a synchronous replication relationship with a destination file system in a second storage device, the first storage device and the second storage device in communication with each other in a communication network, the first storage device comprising:

a first storage controller;

a primary cache and a secondary cache;

the first storage controller configured to:

determine a throughput of successful input/output (IO) transactions acknowledged both by the source file system and the destination file system;

determine a future I/O transaction marker based on the throughput as determined, wherein the future I/O transaction marker is indicative of the sequence number of a future I/O transaction;

create a snapshot associated with a snapshot creation request pending at the source file system on successfully caching the future I/O transaction in the primary cache;

wherein during the creation of the snapshot, an IO transaction received after the future IO transaction, is cached in the secondary cache of the first storage device.
The first storage device as claimed in claim 26 wherein the first storage controller is configured to identify a sequence number of each IO transaction received at the source file system in the first storage device from a host file system in the client device.
The first storage device as claimed in claim 27 wherein the first storage controller is configured to generate and assign the sequence number of the each IO transaction to the respective IO transaction after receiving the snapshot creation request at the source file system in the first storage device from the host file system in the client device.
The first storage device as claimed in claim 26, wherein if a number of the IO transactions received at the source file system in the first storage device is reduced below a threshold, the first storage controller is configured to:

determine a waiting time associated with the snapshot creation request pending with the source file system;

on lapse of the waiting time, initiate the creation of the snapshot associated with the snapshot creation request prior to receipt of the future IO transaction.
The first storage device as claimed in claim 26, comprising:

a sending unit configured to communicate the future I/O transaction marker as determined to the second storage device to enable the destination file system in the second storage device to create a snapshot associated with a snapshot creation request received at the destination file system in the second storage device.
The first storage device as claimed in claim 30, wherein the sending unit is configured to communicate the future I/O transaction to the second storage device by supplementing an information indicative of the future I/O transaction marker in a replicating IO transaction sent from the source file system in the first storage device to the destination file system in the second storage device.
The first storage device as claimed in claim 31, wherein the replicating IO transaction corresponds to a subsequent IO transaction received after the snapshot creation request at the source file system in the first storage device.
The first storage device as claimed in claim 30, wherein the sending unit is configured to communicate the future I/O transaction marker as determined to the second storage device by sending a table from the first storage device to the second storage device, the table including at least the future I/O transaction marker and a time stamp corresponding to the snapshot creation request, wherein the table is sent upon receiving multiple snapshot creation requests at the source file system in the first storage device.
The first storage device as claimed in claim 33 wherein the table comprises of a plurality of future IO transaction markers and a corresponding time stamp, each future IO transaction marker of the plurality of future IO transaction markers, and the corresponding time stamp, being associated with one of the multiple snapshot creations requests received at the source file system in the first storage device.
The first storage device as claimed in claim 30, wherein the creation of the snapshot, associated with the snapshot creation request received at the destination file system in the second storage device from the source file system in the first storage device, is asynchronous to the creation of the snapshot at the source file system in the first storage device.
The first storage device as claimed in claim 35 comprising:

a receiving unit configured to receive a delivery delay communication from the second storage device, the delivery delay communication being associated with a delay in receiving the future IO transaction marker at the second storage device; and

wherein the first storage controller is configured to re-determining the future I/O transaction marker on receiving the delivery delay communication from the second storage device.
The first storage device as claimed in claim 26 wherein one or more IO transactions cached in the primary cache form part of the snapshot created and one or more IO transactions cached in the secondary cache form part of any subsequent snapshot created on receiving a corresponding subsequent snapshot creation request at the source file system.
The first storage device as claimed in claim 26 wherein the first storage controller is configured to process the IO transaction cached in the secondary cache on creating the snapshot.
A second storage device storing a destination file system having a synchronous replication relationship with a source file system in a first storage device, the first storage device and the second storage device in communication with each other in a communication network, the second storage device comprising:

a second storage controller;

a primary cache and a secondary cache;

the second storage controller configured to:

receive a future input/output (IO) transaction marker from the first storage device, the future IO transaction being determined at the first storage device based on a throughput of successful IO transactions acknowledged both by the source file system and the destination file system;

wherein the future I/O transaction marker is indicative of the sequence number of a future I/O transaction;

create a snapshot associated with a snapshot creation request pending at the destination file system on successfully caching the future I/O transaction in the primary cache;

wherein during the creation of the snapshot, an IO transaction received after the future IO transaction, is cached in the secondary cache of the second storage device.
The second storage device as claimed in claim 39, wherein the second storage controller is configured to receive a waiting time associated with the snapshot creation request pending at the destination file system from the first storage device, when a number of the IO transactions received at the source file system in the first storage device is reduced below a threshold, the second storage controller is further configured to, on lapse of the waiting time, initiate the creating of the snapshot prior to receipt of the future IO transaction.
The second storage device as claimed in claim 39 comprising:

a receiving unit configured to receive a replicating IO transaction from the source file system in the first storage device,

wherein the replicating IO transaction corresponds to a subsequent IO transaction received after the snapshot creation request at the source file system in the first storage device;

the receiving unit further configured to receive the future IO transaction marker from the first storage device,

wherein the future I/O transaction marker is received in form of an information indicative of the future I/O transaction marker supplemented in the replicating IO transaction,

.
The second storage device as claimed in claim 41, wherein the receiving unit is configured to receive a table at the second storage device sent from the first storage device, the table including at least the future I/O transaction marker and a time stamp corresponding to the snapshot creation request, wherein the table is sent upon receiving multiple snapshot creation requests at the source file system in the first storage device.
The second storage device as claimed in claim 42, wherein the table comprises of a plurality of future IO transaction markers and a corresponding time stamp, each future IO transaction marker of the plurality of future IO transaction markers, and the corresponding time stamp, being associated with one of the multiple snapshot creations requests received at the source file system in the first storage device.
The second storage device as claimed in claim 39, wherein the creation of the snapshot, associated with the snapshot creation request received at the destination file system in the second storage device from the source file system in the first storage device, is asynchronous to a creation of the snapshot at the source file system in the first storage device.
The second storage device as claimed in claim 39 comprising:

a sending unit configured to communicate a delivery delay communication to the first storage device, the delivery delay communication being associated with a delay in receiving the future IO transaction marker at the second storage device.
The second storage device as claimed in claim 39 wherein one or more IO transactions cached in the primary cache form part of the snapshot created and one or more IO transactions cached in the secondary cache form part of any subsequent snapshot created on receiving a corresponding subsequent snapshot creation request at the destination file system.
The second storage device as claimed in claim 39 wherein the second storage controller is configured to process the IO transaction cached in the secondary cache on creating the snapshot.
The second storage device as claimed in claim 47 comprising a sending unit configured to communicate to the first storage device an acknowledge on processing the IO transactions cached in the secondary cache on successful creation of the snapshot at the destination file system.