WO2017014814A1

WO2017014814A1 - Replicating memory volumes

Info

Publication number: WO2017014814A1
Application number: PCT/US2016/024707
Authority: WO
Inventors: Dhanaraj MARUTHACHALAM; Shanmugaraja NALLASAMY; Santosh Kumar PATNAIK
Original assignee: Hewlett Packard Enterprise Development Lp
Priority date: 2015-07-22
Filing date: 2016-03-29
Publication date: 2017-01-26

Abstract

Examples of replicating memory volumes are described herein. According to one example, a local memory volume in a local site is monitored to determine modification of any block in the local memory volume. In response to the modification, a modification metadata indicative of the modification of the block is generated and synchronized, in real-time, with a remote memory volume in a remote site coupled to the local site. Further, a backup of the local memory volume can be created at the remote memory volume at predetermined intervals to replicate the local memory volume, based on a snapshot. The creating further comprises reflecting, in the remote memory volume, the modification in the block in the local memory volume, based on the modification metadata.

Description

REPLICATING MEMORY VOLUMES

BACKGROUND

[0001] Backup and restore mechanisms ensure that information stored on any storage media on systems, such as databases and servers, is recoverable in the event of loss or damage to the device. One such backup and restore mechanism is remote replication to provide operational continuity to applications during a site failover. Remote replication involves replication of data in of a memory volume of a local site onto a memory volume of a remote site for the applications to use. In case the local site malfunctions, the replicated memory volume at the remote site can be used as a primary site for the applications to access data for operation.

BRIEF DESCRIPTION OF FIGURES

[0002] The detailed description is provided with reference to the accompanying figures. It should be noted that the description and figures are merely example of the present subject matter and are not meant to represent the subject matter itself.

[0003] Figure 1A illustrates a network environment having a replication system for replication of a memory volume, according to an example of the present subject matter.

[0004] Figure 1 B illustrates a schematic of the replication system, according to an example of the present subject matter.

[0005] Figure 1 C illustrates a detailed schematic of the replication system, according to an example of the present subject matter.

[0006] Figure 2 illustrates a method for replication of a memory volume, according to an example of the present subject matter.

[0007] Figure 3A illustrates a detailed method for replication of the memory volume, according to an example of the present subject matter.

[0008] Figure 3B illustrates a method for failover management, according to an example of the present subject matter.

[0009] Figure 4 illustrates a network environment to replicate a memory volume, according to an example of the present subject matter. DETAILED DESCRIPTION

[0010] Generally, remote replication may be achieved using several techniques for replicating blocks of data from a memory volume in a local site onto a memory volume at a remote site. For example, the replication may be achieved either in synchronous mode or asynchronous mode. In case of synchronous mode of replication, the data blocks in the memory volume of the local site are synchronized with the data blocks in the memory volume of the remote site. Accordingly, a change in any data block in the local site is reflected in the remote site in real-time. However, the replication by synchronous mode is resource-intensive. On the other hand, in the asynchronous mode, a snapshot of the data blocks of the memory volume in the local site is triggered periodically, and the latest snapshot is replicated to the memory volume at the remote site. As mentioned previously, during failure of the local site, the replicated memory volume at remote site is used by applications.

[0011] However, in the asynchronous mode of replication, there is a delay in replication of the data from the local site onto the remote site. In the event of a failure of the local site, the data blocks in the memory volume of the remote site are updated to the previous snapshot. Further, the modifications in the data blocks at the local site between the last snapshot and the failure are not updated at the remote site. Therefore, the applications accessing the data in the remote site may be unable to identify in-sync blocks, i.e., blocks that have not been modified, from out-of-sync blocks, i.e., blocks that have been modified. Therefore, to avoid errors, the entire data in the memory volume in the remote site is considered as being out-of-sync, made available for read operations and not for write operations.

[0012] Examples for replicating a memory volume are described herein. The present subject matter provides an approach of replicating blocks from a memory volume of a local site, referred to as local memory volume, to a memory volume of a remote site, referred to as remote memory volume, coupled to the local site. The approach provides for making available unmodified blocks of data replicated from the local memory volume to the remote memory volume for read as well as write operations, for example, during local site failover. According to an aspect, the approach involves communicating, in real-time, information about the modified block in the local memory volume to the remote memory volume.

[0013] In an example, the local memory volume is monitored to determine whether a block of data in the local memory volume has been modified or not. Further, in response to the occurrence of modification of the block, a modification metadata indicative of the modification of the block is concurrently generated and provided to the remote site. According to an aspect, in addition, the local memory volume is backed-up in the remote memory volume by asynchronous mode of replication. For example, at predetermined intervals, the local memory volume is replicated at the remote memory volume based on a snapshot of the local memory volume, in parallel to the providing of the modification metadata.

[0014] Further, in accordance with the present subject matter, at the remote site, the modification metadata is synchronized with the remote memory volume to reflect the modification of the block in the local memory volume, based on the modification metadata. The synchronization is done as part of creation of a backup, or in other words, for replication of the local memory volume at the remote memory volume.

[0015] When any of the blocks in the local memory volume is modified, the modification metadata for that block is replicated onto the block in the remote memory volume. In the event of the failure of the local site or of the local memory volume, the modification metadata provides up-to-date information at the remote site about the blocks of the local memory volume modified between the preceding snapshot of the local memory volume and the failure event. In an example, the information about the modified blocks of the local memory volume is maintained at the remote memory volume and can be updated on a real-time basis. Therefore, the present subject matter provides for tracking the blocks replicated onto the remote memory volume as being in-sync or being out-of- sync. Accordingly, the in-sync blocks replicated in the remote memory volume can be made available for read as well as write operations and the out-of-sync blocks can be made available for read operations. In other words, the remote memory volume onto which the local memory volume is replicated can be made available to applications for read as well as write operations, and such operations can be carried out reliably and can be substantially error-free.

[0016] The above aspects are further described in the figures and associated description below. It should be noted that the description and figures merely illustrate the principles of the present subject matter. Therefore, various arrangements that embody the principles of the present subject matter, although not explicitly described or shown herein, can be devised from the description and are included within its scope.

[0017] Figure 1 A illustrates a network environment 100 having a replication system 102 for replicating a memory volume, according to an example of the present subject matter. Examples of the replication system 102 can include, but is not limited to, servers, desktop computers, laptops, and the like. The replication system 102 can replicate blocks of data from the memory volume on one site to another. Further, in one example, as depicted in Figure 1 A, the replication system 102 can be coupled to a local site 104 and a remote site 106 over a network 108. In addition, the local site 104 and the remote site 106 can be coupled to each other over the network 108 and the replication system 102 can achieve an interaction between the local site 104 and the remote site 106. Although the replication system 102 has been shown as being separate from the local site 104 and the remote site 106, in other examples, the replication system 102 can be deployed in the local site 104 or the remote site 106. In other words, in the above examples, the replication system 102 may carry out host-based replication or array-based replication.

[0018] The local site 104 can include a plurality of local systems 1 10-1 ,

1 10-2 1 10-N, collectively referred to as local systems 1 10 and individually referred to as local system 1 10. Each local system 1 10 may further include a memory volume, referred to as a local memory volume, where the local system 1 10 may store data. For example, the local systems 1 10 can be a group of application servers and each can include a local memory volume to collectively carry data of the application being hosted as well as for the operation of the application. In another example, the local site 104 may include a single local system 1 10 having the local memory volume to carry the data.

[0019] Similar to the local site 104, the remote site 106 can include a plurality of remote systems 1 12-1 , 1 12-2, 1 12-N, collectively referred to as remote systems 1 12 and individually referred to as remote system 1 12. Each remote system 1 12 can further include a memory volume, referred to as a remote memory volume. In an example, each local memory volume and remote memory volume can include memory blocks and can store data in the memory blocks. The data in each block is referred to as a block of data, or simply, a block, herein after. As part of replication, the replication system 102 can replicate the blocks of data from the local site 104 to the remote site 106 over the network 108, for example, to provide a backup of the blocks in event of failover of the local site 104 or a part thereof.

[0020] In an example, the local memory volume and the remote memory volume can be part of a storage area network (SAN), a direct attached storage (DAS), a network attached storage (NAS), or a file system-based storage. For instance, the local memory volume and the remote memory volume can be a virtual disk, a logical unit number (LUN) or a logical unit volume, or a logical memory unit. Further, in an example, the local memory volume may be similar to the remote memory volume or may be different. For instance, the local memory volume can be a virtual disk whereas the remote memory volume can be a logical memory unit. Similarly, in another example, the local memory volume can be a part of the SAN whereas the remote memory volume can be a part of the file-system based storage, both the volumes being connected over the network 108.

[0021] The network 108 may be a wireless network, a wired network, or a combination thereof. The network 108 can also be an individual network or a collection of many such individual networks, interconnected with each other and functioning as a single large network, e.g., the Internet or an intranet. The network 108 can be one of the different types of networks, such as intranet, local area network (LAN), wide area network (WAN), and the internet. The network 108 may either be a dedicated network, a virtual network, or a shared network, which represents an association of the different types of networks that use a variety of protocols, for example, Hypertext Transfer Protocol (HTTP), and Transmission Control Protocol/Internet Protocol (TCP/IP), to communicate with each other. An example of a network 108 may include Fiber Channel Protocol (FCP) on Fiber Channel media. In an example, the network 108 may include a Global System for Mobile Communication (GSM) network, a Universal Mobile Telecommunications System (UMTS) network, or any other communication network that use any of the commonly used protocols, for example, Hypertext Transfer Protocol (HTTP) and Transmission Control Protocol/Internet Protocol (TCP/IP).

[0022] In operation, the replication system 102 can achieve the replication of the local memory volume to the remote memory volume in such a manner that in the event of failover of the local site 104 or of the local memory volume, the remote memory volume on which the local memory volume is replicated is available for read as well as write operations. Accordingly, the replication system can constantly update the remote memory volume, for example, in real-time, regarding a modification of any block in the local memory volume.

[0023] The replication system 102, according to an aspect, can operate in an asynchronous mode of replication as well in a synchronous mode of replication. In one example, the replication system 102 can operate in both the modes of replication in parallel, i.e., simultaneously to achieve the replication of the local memory volume in the remote memory volume, and to provide the remote memory volume with the replicated data for read and write operations.

[0024] The operation of the replication system 102 is described with reference to Figure 1 B and Figure 1 C.

[0025] Figure 1 B illustrates a schematic of the replication system 102 showing components of the replication system 102, according to an example of the present subject matter. The replication system 102 may include, for example, a processor 1 14 and modules 1 16 communicatively coupled to the processor 1 14. The processor 1 14 may include microprocessors, microcomputers, microcontrollers, digital signal processors, central processing units, state machines, logic circuitries, and/or any other devices that manipulate signals and data based on computer-readable instructions. Further, functions of the various elements shown in the figures, including any functional blocks labeled as "processor(s)", may be provided through the use of dedicated hardware as well as hardware capable of executing computer-readable instructions.

[0026] The modules 1 16, amongst other things, include routines, programs, objects, components, and data structures, which perform particular tasks or use particular abstract data types. The modules 1 16 may also be used as, signal processor(s), state machine(s), logic circuitries, and/or any other device or component that manipulates signals based on operational instructions. Further, the modules 1 16 can be used by hardware, by computer- readable instructions executed by a processing unit, or by a combination thereof. The modules 1 16 can include an asynchronous replication module 1 18 and a synchronization module 120.

[0027] As mentioned previously, the replication system 102 can simultaneously operate in the asynchronous mode and synchronous mode of replication to replicate the local memory volume in the remote memory volume such that the out-of sync blocks and the in-sync blocks can be reliably marked in the remote memory volume having the replicated data of the local memory volume.

[0028] Accordingly, in an example, the asynchronous replication module 1 18 can replicate the blocks of data from the remote memory volume to the local memory volume by asynchronous mode. In said example, the asynchronous replication module 1 18 can periodically obtain a snapshot of the local memory volume at predetermined intervals and replicate the snapshot at the remote memory volume.

[0029] In addition, the synchronization module 120 can function in a manner similar to the synchronous mode of replication. Instead of replicating the blocks of data from the local memory volume, the synchronization module 120 can synchronize the local memory volume with the remote memory volume to update at the remote memory volume the modification of any block in the local memory volume. In an example, the synchronization module 120 can generate a modification metadata indicating modification of the block in the local memory volume concurrent to the modification and provide the modification metadata to the remote site in real-time. The modification metadata can indicate that the block in the local memory volume has been modified.

[0030] Accordingly, to indicate at the remote memory volume, the modified blocks, the synchronization module 120 can affix the modification metadata to the remote memory volume, for example, to corresponding blocks in the remote memory volume, to indicate the modified block as being out-of- sync in the remote memory volume. Further, since the synchronization module 120 can achieve such a tagging of the blocks in real-time, at any given instant, the blocks in the remote memory volume not having the modification metadata affixed therewith can be identified as the blocks which have not been modified.

[0031] The various components of the replication system 102 are described in detail in conjunction with Figure 1 C.

[0032] Figure 1 C illustrates a detailed schematic of the replication system 102 showing various components of the replication system 102, according to an example of the present subject matter. The replication system 102, among other things, may include the processor 1 14, modules 1 16, a memory 122, data 124, and interface(s) 126. The processor 1 14, among other capabilities, may fetch and execute computer-readable instructions stored in the memory 122. The memory 122, communicatively coupled to the processor 1 14, can include a non- transitory computer-readable medium including, for example, volatile memory, such as Static Random Access Memory (SRAM) and Dynamic Random Access Memory (DRAM), and/or non-volatile memory, such as Read-Only-Memory (ROM), erasable programmable ROM, flash memories, hard disks, optical disks, and magnetic tapes.

[0033] As mentioned earlier, the replication system 102 may include the modules 1 16. In an example, in addition to the asynchronous replication module 1 18 and the synchronization module 120, the modules 1 16 can include a failover operation module 128 and other module(s) 130. The other module(s) 130 may include computer-readable instructions that supplement applications or functions performed by the replication system 102. Further, the data 124 can include modification metadata 132, replication data 134, and other data 136. The other data 136 may include data generated and saved by the modules 1 16 for providing various functionalities to the replication system 102.

[0034] As mentioned previously, the replication system 102 can be coupled to the local site 104 and the remote site 106 over the network 108. In an example, the replication system 102 can be coupled to the network 108 through the interface(s) 126. The interfaces 126 may include a variety of commercially available interfaces, for example, interfaces for peripheral device(s), such as data input output devices, referred to as I/O devices, storage devices, network devices, and intermediate power devices. The interfaces 126 may facilitate multiple communications within a wide variety of networks and protocol types, including wired networks and wireless networks.

[0035] As explained above, the replication system 102 can achieve replication of the blocks from the local memory volume in the local site 104 to the remote memory volume in the remote site 106. As part of the replication, the replication system 102 can concurrently replicate the data in asynchronous mode as well as in synchronous mode. As part of the synchronous mode of replication, the replication system 102 can constantly communicate, in real-time, the information regarding the modified blocks in the local memory volume to the remote memory volume to update the remote memory volume with the modifications in the local memory volume in real-time. Such replication as achieved by the replication system 102 can provide failover support, i.e., in case the local site 104 or the local memory volume is unavailable, the remote memory volume can be used for operation of an application accessing the local memory volume without any downtime till the time the local site 104 is not operational again.

[0036] According to an example, as part of the asynchronous mode of replication, the asynchronous replication module 1 18 can periodically obtain a snapshot of the local memory volume. For instance, the snapshot can be indicative of a status of the blocks in the local memory volume at the instant the snapshot has been taken, i.e., the snapshot indicates the modified and the unmodified blocks in the local memory volume at the instant that the snapshot has been taken. Further, the asynchronous replication module 1 18 can replicate the snapshot at the remote memory volume to achieve replication by asynchronous mode. In an example, the asynchronous replication module 1 18 can store the snapshots in the replication data 134.

[0037] In addition, the synchronization module 120 can achieve the replication of the blocks in the local memory volume in the remote memory volume in the manner similar to synchronous mode of replication, in an example, in parallel to the operation of the asynchronous replication module 1 18. The synchronization module 120 can constantly monitor the local memory volume for a modification of any of the blocks. As soon as the synchronization module 120 detects that a block has been modified, the synchronization module 120, in real time, generates a modification metadata indicative of the modification of that block. In other words, as soon as the modification occurs, the synchronization module 120 can generate the modification metadata.

[0038] In one example, the synchronization module 120 can include a location identifier of the local memory volume and a location identifier of the modified block in the local memory volume in the modification metadata. For instance, the synchronization module 120 can include a memory volume number, such as a virtual disk number, of the local memory volume and a block number of the modified block in the local memory volume. In another example, in case the local memory volume is a logical memory volume, the modification metadata can include a logical unit number (LUN). Further, the synchronization module 120 can store the modification metadata in the modification metadata 132.

[0039] In addition, the synchronization module 120 can, concurrent to the modification of the block, provide the modification metadata to the remote site. The modification metadata can be used to reflect, in the remote memory volume, the modification of the block in the local memory volume. In an example, to reflect the modification at the remote memory volume, the synchronization module 120 can append the modification metadata with the remote memory volume. For instance, the synchronization module 120 can affix the modification metadata to the block of the remote memory volume corresponding to the block of the local memory volume which is modified. In such a case, the synchronization module 120 can modify the status code, for instance, with the modification metadata, in real time, to indicate that the block in the local memory volume is modified and the block is marked as out-of-sync.

[0040] In another example, the synchronization module 120 can maintain a bitmap of the remote memory volume. For instance, the synchronization module 120 can update, based on the modification metadata, the bitmap associated with remote memory volume in real time, i.e., concurrent to the modification of the block in the local memory volume, to record that modification in the remote memory volume. The bitmap can indicate the block in the local memory volume that has been modified as out-of-sync allowing easy identification of the modified blocks replicated to the remote memory volume.

[0041] Accordingly, the blocks in the remote memory volume which are modified with the modification metadata, for example, having the modification metadata affixed therewith, are identified as being out-of-sync and the ones which are not modified are marked as in-sync. Such a labeling of the blocks provides visibility of out-of-sync and in-sync blocks in the remote memory volume to the application, for example, in case the local site 104 fails and the operations are shifted from the local memory volume to the remote memory volume. Accordingly, in case of failover of the local site 104, the in-sync blocks in the remote memory volume can be made available to the application for read as well as write operations and the out-of-sync blocks can be made available for read operations. However, in an example, the data in the out-of-sync blocks can be made available to the application with additional information and not otherwise. For example, in case of a Small Computer System Interface-based (SCSI-based) system, the command descriptor block (CDB) response layout associated with the out-of-sync block in the remote memory volume can include a status code to indicate that the block is out-of-sync. Accordingly, the application can make use of data in the out-of-sync blocks with the awareness that the data is out-of-sync. [0042] According to an example, in case of a failover of the local site 104 or of the local memory volume in the local site 104, the failover operation module 128 shifts the operations, such as input-output operations performed by the application, from the local site 104 to the remote site 106. Accordingly, the failover operation module 128 can mark the remote memory volume at the remote site 106 as a primary site for accessing data for the application to function. As explained above, the modification metadata provided at the remote memory volume provides real-time information to the application about the blocks of the local memory volume modified from the preceding snapshot of the local memory volume and right until the failure event. Accordingly, the failover operation module 128 can make the remote memory volume available for read and write operations.

[0043] According to an example, the failover operation module 128 can provide such functioning of the remote memory volume for the operation of the application for as long as the local site 104 is unavailable and has not been retrieved. As soon as the local site 104 is recovered, the failover operation module 128 can mark the local site 104 as the primary site and shift the operations to the local site 104.

[0044] According to an aspect, before the operations can be shifted onto the local memory volume, the failover operation module 128 can ensure that the modifications in the blocks in the remote memory volume during the period of unavailability of the local site 104 are also reflected in the local site 104. Accordingly, in an example, the failover operation module 128 can obtain a snapshot of the remote memory volume to capture the modifications in the blocks of the remote memory volume between the event of failure of the local site 104 and when the local site 104 is recovered. Further, the failover operation module 128 can replicate the snapshot of the remote memory volume to the local memory volume.

[0045] In case the local site 104 is recovered to a condition immediately prior to the event failure, in an example, the failure operation module 128 can replicate the snapshot of the remote memory volume to merge the modifications in the remote memory volume with the local memory volume. For instance, in such a case, the failure operation module 128 can, based on the snapshot, update the modifications during the period of availability along with the previous modifications already available on the recovered local memory volume.

[0046] The replication of the local memory volume by the replication system 102, in accordance with the present subject matter, is explained further with the help of the following examples.

[0047] Consider a case in which the local site 104 is hosting a ticket reservation application for booking movie tickets. In such an application, the margin for error of reading and writing data may be miniscule. In accordance with the present subject matter, the synchronization module 120 can communicate the information about the modified block and can keep a track of the modified blocks in the local memory volume, on a real-time basis. At the same time, the asynchronous replication module 1 18 can replicate the local memory volume to the remote memory volume by asynchronous mode of replication.

[0048] In the event of the failover of the local memory volume, the failover operation module 128 can shift the operations of the ticket reservation application to the remote memory volume. In accordance with the present subject matter, if the modification metadata is affixed with a block in the remote memory volume or if the bit is set, the application identifies that the block is out- of-sync, i.e., the block is modified in the local memory volume before the failover. Accordingly, the block is available for read operations and not for write operations. Further, the application is able to identify the blocks among the replicated which are up-to-date and are in-sync, i.e., available for write operations. Therefore, using the aspects of the present subject matter, the application can identify the in-sync blocks during the failover of the local site 104.

[0049] Accordingly, the present subject matter provides data availability and preempts discontinuity in the operation of the application. For example, if 20% of blocks in the local memory volume are modified between the replication of the latest snapshot and the failure of the local memory volume, the application can treat the rest of the 80% of blocks on the blocks replicated to the remote memory volume as up-to-date or in-sync. In the absence of such a provision, the application treats 100% of the blocks as out-of-sync.

[0050] Methods 200, 300 and 318 are described in Figure 2, Figure 3A, and Figure 3B, respectively, for replicating a memory volume, according to an example of the present subject matter. While Figure 2 illustrates an overview of the method 200 for replicating a memory volume, Figure 3A illustrates a detailed method 300 for replicating a memory volume. Figure 3B illustrates a method 318 for failover management which is a continuation of the method 300.

[0051] The order in which the methods 200, 300, and 318 are described is not intended to be construed as a limitation, and any number of the described method blocks can be combined in any appropriate order to execute the methods 200, 300, and 318 or an alternative method. Additionally, individual blocks may be deleted from the methods 200, 300, and 318 without departing from the spirit and scope of the subject matter described herein.

[0052] The methods 200, 300, and 318 can be performed by programmed computing devices, for example, based on instructions retrieved from non-transitory computer readable media. The computer readable media can include machine-executable or computer-executable instructions to perform all or portions of the described method. The computer readable media may be, for example, digital memories, magnetic storage media, such as a magnetic disks and magnetic tapes, hard drives, or optically readable data storage media.

[0053] The methods 200, 300, and 318 may be performed by a computing system, such as the replication system 102. For the sake of brevity of description of Figure 2, Figure 3A, and Figure 3B, the components of the replication system 102 performing the various steps of the methods 200, 300, and 318 are not described in detail with reference to Figure 2, Figure 3A, and Figure 3B. Such details are provided in the description provided with reference to Figure 1 A, Figure 1 B, and Figure 1 C.

[0054] Referring to Figure 2, at block 202, the local memory volume is monitored to determine whether a block of data in the local memory volume has been modified or not. [0055] At block 204, in response to the occurrence of modification of the block, a modification metadata indicative of the modification of the block is concurrently generated and provided to the remote site. In an example, the modification metadata can include a location identifier of the local memory volume and a location identifier of the modified block in the local memory volume.

[0056] At block 206, at the remote site, the modification metadata can be synchronized with the remote memory volume to reflect the modification of the block in the local memory volume at the local site, based on the modification metadata. The synchronization can be achieved as part of replicating the local memory volume to the remote memory volume.

[0057] At block 208, a backup of the local memory volume is created in the remote memory volume by asynchronous mode of replication, i.e., at predetermined intervals, a snapshot of the local memory volume can be obtained and the local memory volume replicated at the remote memory volume based on the snapshot. In an example, such replication of the local memory volume can be achieved in parallel to the providing of the modification metadata.

[0058] Referring to Figure 3A, at block 302, the local memory volume can be constantly monitored for a modification of any of the blocks.

[0059] At block 304, it is determined whether any block in the local memory block has been modified.

[0060] In case any block in the local memory volume is modified (YES path from block 304), then at block 306, a modification metadata indicative of the modification of that block can be generated as soon as the modification occurs. In other words, the generation of the modification metadata can be concurrent to the modification of the block in the local memory volume. In an example, the modification metadata can be generated based on a memory volume number, such as a virtual disk number, of the local memory volume and a block number of the modified block in the local memory volume.

[0061] Further, at block 308, concurrent to the modification of the block, the modification metadata can be provided to the remote site. [0062] Furthermore, at block 310, the modification metadata can be used to reflect, in the remote memory volume, the modification of the block in the local memory volume. In an example, to reflect the modification at the remote memory volume, the modification metadata can be appended with the remote memory volume. For instance, the modification metadata can be affixed to the block of the remote memory volume corresponding to the block of the local memory volume which is modified. In another example, a bitmap of the remote memory volume can be maintained. For instance, based on the modification metadata, the bitmap associated with remote memory volume can be updated in real time, i.e., concurrent to the modification of the block in the local memory volume, to record that modification in the remote memory volume.

[0063] Accordingly, the blocks in the remote memory volume which are modified with the modification metadata, for example, having the modification metadata affixed therewith, are identified as being out-of-sync and the ones which are not modified are marked as in-sync. Such a labeling of the blocks provides visibility of out-of-sync and in-sync blocks in the remote memory volume to an application accessing the data in the remote memory volume having the replicated data of the local memory volume.

[0064] On the other hand, in case any block in the local memory volume is not modified (NO path from block 304), then at block 312, it is determined whether the predetermined interval for carrying out the replication of the local memory volume by asynchronous mode of replication has lapsed or not.

[0065] In case the predetermined interval has not lapsed (NO path from block 312), then the determining at block 304 is achieved again and the subsequent steps followed as explained above.

[0066] On the other hand, in case the predetermined interval has lapsed (YES path from block 312), then the local memory volume can be replicated to the remote memory volume by asynchronous mode of replication.

[0067] Accordingly, at block 314, a snapshot of the local memory volume is obtained for achieving the replication by asynchronous mode of replication. For instance, the snapshot can be indicative of a status of the blocks in the local memory volume at the instant the snapshot has been taken, i.e., the snapshot indicates the modified and the unmodified blocks in the local memory volume at the instant that the snapshot has been taken.

[0068] At block 316, the snapshot can be replicated at the remote memory volume to achieve replication by asynchronous mode.

[0069] Further, in the event of the failure of the local site 104, failover management can be achieved, as explained with reference to method 318 shown in Figure 3B. In an example, method 318 can be a continuation of method 300 beyond block 316.

[0070] At block 320, it is periodically determined whether the local site 104 or, in other words, the local memory volume in the local site 104, has failed.

[0071] In case the local site 104 has not failed (NO path from block 320), then at block 300, method 300 is executed, as explained with reference to Figure 3A. In an example, method 300 can be executed for as long as failure of the local site 104 does not occur.

[0072] Accordingly, as soon as it is determined that the local site 104 has failed (YES path from block 320), then at block 322, the remote memory volume, to which the local memory volume is replicated, is marked as a primary site for use by the application.

[0073] At block 324, the remote memory volume is made available to the application for read and write operations. In an example, the in-sync blocks of remote memory volume can be made available for read as well as write operations for the application. As mentioned previously, the labeling of the blocks, based on whether each block has the modification metadata associated therewith, provides visibility of out-of-sync and in-sync blocks in the remote memory volume to the application.

[0074] Further, at block 326, it is determined as to whether the local site 104 has been recovered from the failover.

[0075] In case the local site 104 has not been recovered (NO path from block 326), then the remote memory volume is still provided as the primary site.

[0076] In case the local site 104 has re-covered from the failover (YES path from block 326), the operations are transferred back to the local memory volume of the local site 104. However, before the operations can be shifted onto the local memory volume, the modifications in the blocks in the remote memory volume during the period of unavailability of the local site 104 are also reflected in the local site 104.

[0077] Accordingly, at block 328, a snapshot of the remote memory volume is obtained to capture the modifications in the blocks of the remote memory volume between the interval of the event of failure of the local site 104 and when the local site 104 is recovered.

[0078] Further, at block 330, the snapshot of the remote memory volume can be replicated to a recovered local memory volume. In case the local site 104 is recovered to a condition immediately prior to the event failure, in an example, the replication can involve merging the modifications in the remote memory volume with the recovered local memory volume. For instance, in such a case based on the snapshot, the modifications during the period of availability can be updated along with the previous modifications already available on the recovered local memory volume.

[0079] Further, at block 332, the local site 104 can be marked as the primary site to make the local site 104 available for read and write operations to the application.

[0080] Figure 4 illustrates an example network environment 400 using a non-transitory computer readable medium 402 for replicating memory volumes, according to an example of the present subject matter. The network environment 400 may be a public networking environment or a private networking environment. In one example, the network environment 400 includes a processing resource 404 communicatively coupled to the non-transitory computer readable medium 402 through a communication link 406.

[0081] For example, the processing resource 404 can be a processor of a computing system, such as the replication system 102. The non-transitory computer readable medium 402 can be, for example, an internal memory device or an external memory device. In one example, the communication link 406 may be a direct communication link, such as one formed through a memory read/write interface. In another example, the communication link 406 may be an indirect communication link, such as one formed through a network interface. In such a case, the processing resource 404 can access the non-transitory computer readable medium 402 through a network 408. The network 408 may be a single network or a combination of multiple networks and may use a variety of communication protocols.

[0082] The processing resource 404 and the non-transitory computer readable medium 402 may also be communicatively coupled to data sources 410 over the network 408. The data sources 410 can include, for example, databases and computing devices. The data sources 410 may be used by the database administrators and other users to communicate with the processing resource 404.

[0083] In one example, the non-transitory computer readable medium 402 includes a set of computer readable instructions, such as the asynchronous replication module 1 18 and the synchronization module 120. The set of computer readable instructions, referred to as instructions hereinafter, can be accessed by the processing resource 404 through the communication link 406 and subsequently executed to perform acts for network service insertion.

[0084] For discussion purposes, the execution of the instructions by the processing resource 404 has been described with reference to various components introduced earlier with reference to description of Figure 1 A, Figure 1 B, and Figure 1 C.

[0085] On execution by the processing resource 404, the asynchronous replication module 1 18 can replicate blocks of data from a local memory volume to a remote memory volume by asynchronous mode of replication. In said example, the asynchronous replication module 1 18 can obtain a snapshot of the local memory volume at predetermined intervals and replicate the snapshot at the remote memory volume after every such predetermined interval.

[0086] In addition, the synchronization module 120 can achieve the replication in a manner similar to the synchronous mode of replication. In an example, the synchronization module 120 can constantly monitor the local memory volume for a modification of any of the blocks. Further, as soon as the synchronization module 120 detects that a block has been modified, the synchronization module 120 can generate, in real-time, a modification metadata indicating modification of the block in the local memory volume. Further, the synchronization module 120 can provide the modification metadata to the remote site in real-time. The modification metadata can indicate that the block in the local memory volume has been modified. Accordingly, the synchronization module 120 can update the modification metadata to the remote memory volume to reflect at the remote memory volume the modification of the block in the local memory volume.

[0087] Accordingly, to indicate at the remote memory volume, the modified blocks, the synchronization module 120 can affix the modification metadata to the remote memory volume, for example, to corresponding blocks in the remote memory volume, to indicate the modified block as being out-of- sync in the remote memory volume. Further, since the synchronization module 120 can achieve such a tagging of the blocks in real-time, at any given instant, the blocks in the remote memory volume not having the modification metadata affixed therewith can be identified as the blocks which have not been modified.

[0088] Although examples for replicating memory volumes have been described in language specific to structural features and/or methods, it is to be understood that the appended claims are not limited to the specific features or methods described. Rather, the specific features and methods are disclosed as examples for replicating memory volumes.

Claims

CLAIMS What is claimed is:

1 . A method comprising:

monitoring a local memory volume in a local site to determine modification of a block in the local memory volume;

generating, in response to the modification, a modification metadata indicative of the modification of the block;

synchronizing the modification metadata with a remote memory volume in a remote site coupled to the local site, wherein the synchronizing comprises providing the modification metadata to the remote site in realtime; and

creating a backup, at the remote memory volume in the remote site, of the local memory volume in the local site at predetermined intervals to replicate the local memory volume, based on a snapshot, wherein the creating further comprises reflecting, in the remote memory volume, the modification in the block in the local memory volume based on the modification metadata.

2. The method as claimed in claim 1 , wherein the modification metadata comprises a location identifier of the local memory volume and a location identifier of the modified block in the local memory volume.

3. The method as claimed in claim 1 , wherein the creating the backup comprises appending the modification metadata with the remote memory volume to indicate in-sync and out-of-sync blocks in the remote memory volume.

4. The method as claimed in claim 3, further comprising:

determining whether a failover of the local site has occurred; and making the in-sync blocks in the remote memory volume available for read and write operations.

5. The method as claimed in claim 4, further comprising: determining whether the local site has been recovered;

obtaining a snapshot of modified remote memory volume in the remote site; and

replicating the snapshot of the modified remote memory volume to merge with the local memory volume in the local site.

6. A replication system comprising:

a processor;

an asynchronous replication module to replicate, at a remote memory volume in a remote site, a snapshot of a local memory volume in a local site coupled to the remote site at predetermined intervals to replicate the local memory volume in the remote memory volume; and

a synchronization module coupled to the processor to,

generate a modification metadata indicating modification of a block in the local memory volume;

provide the modification metadata to the remote site in real-time; and

affix the modification metadata to the remote memory volume to indicate the modified block as being out-of-sync in the remote memory volume.

7. The replication system as claimed in claim 6, wherein the synchronization module is to generate the modification metadata based on a location identifier of the local memory volume and a location identifier of the modified block in the local memory volume.

8. The replication system as claimed in claim 6, further comprising a failover operation module coupled to the processor to shift input-output operations from the local site to the remote site when a failover of the local site occurs, wherein the failover operation module is to make selected blocks from among non- metadata affixed blocks in the remote memory volume available for read and write operations.

9. The replication system as claimed in claim 8, wherein the failover operation module is to:

obtain a snapshot of modified remote memory volume in the remote site when the local site has recovered from the failover; and

replicate the snapshot of the modified memory volume to merge with the local memory volume in the local site, the local memory volume being recovered in a condition as prior to the failover.

10. The replication system as claimed in claim 6, wherein the synchronization module is to maintain a bitmap of the remote memory volume to indicate blocks having the modification metadata affixed thereto.

1 1 . A non-transitory computer-readable medium comprising instructions executable by a processing resource to:

replicate, at a remote memory volume in a remote site, a snapshot of a local memory volume in a local site at predetermined intervals to replicate the local memory volume at the remote site;

determine modification of a block in the local memory volume;

generate, in response to the modification, a modification metadata indicative of the modification of the block; and

update, in real-time, the modification metadata to the remote memory volume in the remote site, wherein the updating comprises reflecting, at the remote memory volume, the modification in the block of the local memory volume, based on the modification metadata.

12. The non-transitory computer-readable medium as claimed in claim 1 1 further comprising instructions executable by the processor to append the modification metadata with the remote memory volume to indicate in-sync and out-of-sync blocks in the remote memory volume.

13. The non-transitory computer-readable medium as claimed in claim 12 further comprising instructions executable by the processor to:

determine whether a failover of the local site has occurred; and provide the in-sync blocks in the remote memory volume for read and write operations.

14. The non-transitory computer-readable medium as claimed in claim 1 1 further comprising instructions executable by the processor to generate the modification metadata based on a location identifier of the local memory volume and a location identifier of the modified block in the local memory volume.

15. The non-transitory computer-readable medium as claimed in claim 1 1 further comprising instructions executable by the processor to update a bitmap of the remote memory volume in real-time to indicate blocks having the modification metadata affixed thereto.