CN102306115A

CN102306115A - Asynchronous remote copying method, system and equipment

Info

Publication number: CN102306115A
Application number: CN201110132517A
Authority: CN
Inventors: 高三海; 罗庆超; 王飞
Original assignee: Huawei Symantec Technologies Co Ltd
Current assignee: Chengdu Huawei Technology Co Ltd
Priority date: 2011-05-20
Filing date: 2011-05-20
Publication date: 2012-01-04
Anticipated expiration: 2031-05-20
Also published as: CN102306115B

Abstract

The invention provides an asynchronous remote copying method, an asynchronous remote copying system and asynchronous remote copying equipment. The asynchronous remote copying method comprises the following steps of: after a production center receives a writing request of a host machine, labeling a period number for the writing request according to the period number of the current period; writing the labeled writing request with the period number into a local remote copying master logic unit number (LUN) and labeling a sequence number for the labeled writing request with the period number according to a sequence of the period number written into the remote copying master LUN; and sending the labeled writing request with the period number and the sequence number to a disaster tolerance center. By the method, the system and the equipment, the problem of inconsistency of data stored in the remote copying master LUN of the production center and data stored in a remote copying slave LUN of the disaster tolerance center caused by inconsistency of the sequence of a plurality of writing requests which have conflicted accessing addresses reaching the disaster tolerance center and the sequence of the plurality of writing requests written into the production center within the same period can be avoided.

Description

Asynchronous remote copying method, system and equipment

Technical Field

The present invention relates to computer technologies, and in particular, to an asynchronous remote copy method, an asynchronous remote copy system, a production center, and a disaster recovery center.

Background

Disaster recovery systems generally include two types of data centers: the remote disaster recovery system comprises a local production center and a remote disaster recovery center, wherein the remote disaster recovery center is provided with a remote copy slave LUN for backing up data in a remote copy main logic storage object (LUN for short) of the production center. When the disaster recovery system encounters a catastrophic event, the remote copy master LUN in the local source volume production center is restored by remotely copying the data in the slave LUN through the disaster recovery center, so that the physical security of important data is ensured, and for example, data loss caused by power failure, fire or nature (earthquake, tsunami, etc.) is avoided. The process of updating the remote copy slave LUN according to the data in the remote copy master LUN is called a remote copy process, and the type of the remote copy process can be classified according to the difference between the enterprise service environment (such as available bandwidth, network latency, number of servers, size of copy data amount, and physical distance between hosts) and the requirements of the user on the duration of data loss (Recovery Point Object, RPO) and the maximum time required for application Recovery (RTO) after a disaster occurs: synchronous remote copy and asynchronous remote copy.

Synchronous remote copy means that after receiving a write request sent by an upper layer application in a host, a production center successfully sends data corresponding to the write request to a remote copy master LUN of the production center and a remote copy slave LUN of a disaster recovery center before returning a write success confirmation message to the upper layer application. Since sending data to the remote copy master LUN of the production center and the remote copy slave LUN of the disaster recovery center may take a certain time, performance of upper layer applications may be affected to some extent. Asynchronous remote copy means that a successful confirmation message can be written back to the upper layer application as long as data corresponding to a write request is successfully sent to a remote copy master LUN of a production center, and the successful confirmation message does not need to be returned until the data is sent to a remote copy slave LUN of a disaster recovery center, and then the remote copy slave LUN of the disaster recovery center is updated according to the remote copy master LUN of the production center.

The performance problem of synchronous remote copy can be eliminated by adopting asynchronous remote copy, and the disaster recovery center can basically copy in real time although possibly lagging behind the production center, and the performance of upper-layer application is not obviously influenced. The asynchronous replication technology can be classified into block-level asynchronous remote replication based on a snapshot and write request-level asynchronous remote replication based on a log LUN according to technical features of its implementation. The basic principle of asynchronous remote copy of write request level based on log LUN is as follows: when a write request is issued from a host of the production center to the remote copy main LUN, the write request is simultaneously written into the log LUN of the production center and is stamped with a periodic timestamp (timestamps of all write requests are consistent in the same period), so that the sequentiality of the write request can be maintained by the log LUN. And the asynchronous remote copying module at the background of the production center reads the written write request in the log LUN and sends the write request to the remote copying slave LUN positioned in the disaster recovery center. The method can reduce the recovery time and the data loss time of the disaster recovery system.

However, due to network delay and the like when sending a write request read from the log volume log LUN to the remote backup volume remote copy slave LUN, there is a possibility that the order of writing to the local source volume remote copy master LUN and the order of writing to the remote backup volume remote copy slave LUN for write requests in the same period are different, and if the access addresses of these write requests collide, a problem occurs in which the data stored in the local source volume remote copy master LUN and the remote backup volume remote copy slave LUN do not coincide.

Disclosure of Invention

The embodiment of the invention provides an asynchronous remote copying method, which is used for solving the defect that data stored in a remote copying main LUN and a remote copying slave LUN are inconsistent in the prior art.

Correspondingly, the embodiment of the invention also provides a production center, a disaster recovery center and an asynchronous remote copy system.

The embodiment of the invention provides an asynchronous remote copying method, which comprises the following steps:

after receiving a write request of a host, a production center marks a period number for the write request according to the period number of a current period;

writing the write request with the marked cycle number into a local remote copy main LUN, and marking a sequence number for the write request with the marked cycle number according to the sequence written into the remote copy main LUN;

and sending the write request with the marked cycle number and the sequence number to the disaster recovery center.

the method comprises the steps that a disaster recovery center receives a write request sent by a production center, wherein a cycle number and a sequence number are marked in the write request;

determining whether all write requests corresponding to a cycle number have been received,

and when the judgment result is that all the write requests corresponding to one cycle number are received, writing the received write requests into the local remote copy slave LUN according to the cycle number and the sequence number marked in the write requests.

An embodiment of the present invention provides a production center, including at least one production cluster system, where the production cluster system includes a first front-end platform and a first back-end platform, and the first back-end platform includes a first service processing device and a remote copy master LUN, where:

the first front-end platform is used for marking a period number according to the write request after receiving the write request of the host, and sending the write request marked with the period number to a first service processing device in a first back-end platform in the production cluster system;

the first service processing device is used for writing the write request with the marked cycle number into a remote copy main LUN, marking a sequence number for the write request with the marked cycle number according to the sequence written into the remote copy main LUN, and sending the write request with the marked cycle number and the sequence number to the disaster recovery center.

An embodiment of the present invention provides a disaster recovery center, including: the system comprises at least one disaster recovery cluster system, wherein the disaster recovery cluster system comprises a second front-end platform and a second back-end platform, the second back-end platform comprises a second service processing device and a remote copy slave LUN, and the disaster recovery cluster system comprises:

the second front-end platform is used for receiving a write request sent by a production center, and the write request is marked with a cycle number and a sequence number;

and the second service processing device is configured to determine whether the second front-end platform has received all write requests corresponding to a cycle number, and write the received write request into the remote copy slave LUN according to the cycle number and the sequence number marked in the write request when determining that all write requests corresponding to a cycle number have been received.

An embodiment of the present invention provides an asynchronous remote copy system, including:

the production center is used for marking the period number of the write request according to the period number of the current period after receiving the write request of the host; writing the write request with the marked cycle number into a local remote copy main LUN, and marking a sequence number for the write request with the marked cycle number according to the sequence written into the remote copy main LUN; sending the write request with the marked cycle number and the sequence number to a disaster recovery center;

the disaster recovery center is used for receiving a write request sent by the production center, and the write request is marked with a cycle number and a sequence number; and judging whether all the write requests corresponding to one period number are received or not, and writing the received write requests into the local remote copy slave LUN according to the period number and the sequence number marked in the write requests when the judgment result is that all the write requests corresponding to one period number are received.

In the embodiment of the present invention, when a production cluster system of a production center receives a write request from a host, a cycle number is marked for the write request, and after the write request is written into a remote copy master LUN, a sequence number written into the remote copy master LUN in a current cycle is marked for the write request. After the production center sends the write request marked with the cycle number and the sequence number to the disaster recovery center, the disaster recovery center can write the remote copy slave LUN according to the sequence number for the write request in the same cycle. Therefore, the problem that when the sequence of a plurality of write requests with conflicting access addresses reaching the disaster recovery center in the same period is inconsistent with the writing sequence of the production center is avoided, the data stored in the remote copy main LUN of the production center is inconsistent with the data stored in the remote copy slave LUN of the disaster recovery center.

Drawings

In order to more clearly illustrate the embodiments of the present invention or the technical solutions in the prior art, the drawings needed to be used in the description of the embodiments or the prior art will be briefly introduced below, and it is obvious that the drawings in the following description are some embodiments of the present invention, and for those skilled in the art, other drawings can be obtained according to these drawings without creative efforts.

Fig. 1 is a flowchart of an asynchronous remote copy method according to an embodiment of the present invention;

fig. 2A is a flowchart illustrating an asynchronous remote replication method applied to a distributed storage system according to an embodiment of the present invention;

fig. 2B is a schematic structural diagram of a production center according to an embodiment of the present invention;

FIG. 2C is a flowchart illustrating an asynchronous remote copy method applied to a non-distributed storage system according to an embodiment of the present invention;

fig. 3 is a flowchart of another asynchronous remote copy method according to an embodiment of the present invention:

FIG. 4A is a flowchart illustrating an asynchronous remote replication method applied to a distributed storage system according to an embodiment of the present invention;

fig. 4B is a schematic structural diagram of a disaster recovery center according to an embodiment of the present invention;

fig. 4C is a schematic diagram of a write request linked list stored in a remote cache in the disaster recovery cluster system according to the embodiment of the present invention;

fig. 5 is a schematic structural diagram of a second service processing apparatus in a disaster recovery center according to an embodiment of the present invention;

fig. 6 is a schematic structural diagram of an asynchronous remote copy system according to an embodiment of the present invention.

Detailed Description

In order to make the objects, technical solutions and advantages of the embodiments of the present invention clearer, the technical solutions in the embodiments of the present invention will be clearly and completely described below with reference to the drawings in the embodiments of the present invention, and it is obvious that the described embodiments are some, but not all, embodiments of the present invention. All other embodiments, which can be derived by a person skilled in the art from the embodiments given herein without making any creative effort, shall fall within the protection scope of the present invention.

Example one

Fig. 1 is a flowchart of an asynchronous remote copy method according to an embodiment of the present invention. The embodiment of the present invention provides a technical solution of an asynchronous remote copy method from a production center perspective. The execution subject of the present embodiment is a storage system of the production center. As shown in fig. 1, the present embodiment includes:

step 11: and after receiving the write request of the host, the production center marks the cycle number for the write request according to the cycle number of the current cycle.

The marking of the cycle number for the write request according to the cycle number of the current cycle is to mark the cycle in which the production center processes the write request.

Step 12: the production center writes the write request with the marked cycle number into a local remote copy main LUN, and marks a sequence number for the write request with the marked cycle number according to the sequence written into the remote copy main LUN.

After writing the write request with the marked cycle number into the local remote copy main LUN, the production center marks the sequence number written into the remote copy main LUN in the current cycle for the write request according to the sequence of the write request written into the remote copy main LUN. Therefore, the write request is not only marked with the cycle number corresponding to the write request, but also marked with the sequence number of the write request when writing to the remote copy master LUN.

Step 13: and the production center sends the write request with the marked cycle number and the sequence number to the disaster recovery center.

Further, after the current period is finished, the production center sends the period number of the current period and the corresponding write request number of the host received in the current period to the disaster recovery center. Therefore, the disaster recovery center can determine whether all the write requests of the period corresponding to the period number have been received or not according to the period number and the corresponding write request number, and write all the write requests in the period into the remote copy slave LUN when determining that all the write requests of the period corresponding to the period number have been received.

In the embodiment of the present invention, when a storage system of a production center receives a write request from a host, a cycle number is marked for the write request, and after the write request is written into a remote copy master LUN, a sequence number written into the remote copy master LUN in a current cycle is marked for the write request. After the production center sends the write request marked with the cycle number and the sequence number to the disaster recovery center, the disaster recovery center can write the remote copy slave LUN according to the sequence number for the write request in the same cycle. Therefore, the problem that when the sequence of a plurality of write requests with conflicting access addresses reaching the disaster recovery center in the same period is inconsistent with the writing sequence of the production center is avoided, the data stored in the remote copy main LUN of the production center is inconsistent with the data stored in the remote copy slave LUN of the disaster recovery center.

Example two

In the embodiment, specific application examples of the asynchronous remote replication method shown in fig. 1 in a distributed storage system and a non-distributed storage system are respectively given.

Fig. 2A is a flowchart illustrating an application of an asynchronous remote replication method to a distributed storage system according to an embodiment of the present invention. Fig. 2B is a schematic structural diagram of a production center according to an embodiment of the present invention. This embodiment illustrates the technical solution of the asynchronous remote copy method from the perspective of a production center. As shown in fig. 2B, the distributed storage system of the production center in this embodiment includes at least two production cluster systems. The production cluster system is used for processing write requests issued by a host of the production center. Each production cluster system comprises a first front-end platform and a first back-end platform, wherein the first back-end platform comprises a first service processing device and a remote copy main LUN. The first front-end platforms in each production cluster system can be connected through an internal network. As shown in fig. 2A, the present embodiment includes:

step 21: each production cluster system in the production center receives a write request issued by a host of the production center.

Optionally, the host communicates with the first front-end platform in each production cluster system through a SCSI protocol, and the first front-end platform of each production cluster system receives, through the SCSI protocol, a write request issued by the host of the production center.

Step 22: each production cluster system determines the physical address of the write request according to the address mapping table, and determines whether the physical address space processed by the production cluster system includes the physical address of the write request, if the determination result is that the physical address space processed by the production cluster system includes the physical address of the write request, step 23 is entered; otherwise, the write request is ignored or forwarded to the first front-end platform of the other production cluster system.

After a first front-end platform in each production cluster system receives a write request issued by a host, a physical address of the write request is determined by searching an address mapping table according to a logical address carried in the write request, and the mapping relation between the logical address and the physical address in the distributed storage system is stored in the address mapping table.

Since the physical address space of the write request handled by each production cluster system in the production center is different from the physical address space of the write requests handled by other production cluster systems in the production center (e.g., a first production cluster system is used for handling write requests with physical addresses within 000000000000 ~ 1FFFFF physical address space, and a second production cluster system is used for handling write requests with physical addresses within 20000000 ~ 3FFFFF physical address space). And when the first front-end platform in each production cluster system determines that the physical address of the write request is not in the physical address space processed by the production cluster system, ignoring the write request or forwarding the write request to the first front-end platforms of other production cluster systems.

Step 23: the production cluster system whose physical address space includes the physical address of the write request acquires the cycle number of the current cycle, marks the cycle number for the write request according to the acquired cycle number of the current cycle, and proceeds to step 24.

Optionally, the first front-end platform in the production cluster system obtains the cycle number of the current cycle, and marks the cycle number for the write request according to the obtained cycle number of the current cycle.

The scheme for the first front-end platform in the production cluster system to obtain the cycle number of the current cycle includes but is not limited to:

in the first aspect, a first front-end platform in a production cluster system is obtained from a setting device in a production center, the setting device being used for setting a cycle number, and the method specifically includes: when a write request is received, sending a current period number acquisition request to the setting device, and receiving a period number of a current period fed back by the setting device; or, the setting device periodically sends the period number of the current period to the first front-end platform in each production cluster system in the production center. And the first front-end platform periodically receives the cycle number of the current cycle sent by the setting device.

In the second scheme, one production cluster system is selected from the production cluster systems of the production center in advance as a master control production cluster system, and a first front-end platform in the master control production cluster system may be referred to as a master control first front-end platform for short. Wherein the master first front end platform is used for setting a period number.

The production cluster system for marking the cycle number for the write request may be a master control production cluster system or a non-master control production cluster system. When the production cluster system marking the cycle number for the write request is the master control production cluster system, the master control first front-end platform may use the currently set cycle number set by itself as the acquired cycle number of the current cycle; when the production cluster system marking the cycle number for the write request is a non-master control production cluster system, the modes of the non-master control first front-end platform obtaining the cycle number of the current cycle include, but are not limited to, the following:

in the first mode, the master control first front-end platform sends the current cycle number to the non-master control first front-end platform sending the request according to the request of the non-master control first front-end platform of the production center.

In a second mode, the master control first front-end platform periodically sends the cycle number of the current cycle to each non-master control first front-end platform in the production center. The non-master control first front-end platform periodically receives the cycle number of the current cycle sent by the master control first front-end platform. The master first front end platform and each non-master first front end platform may be interconnected using an internal network.

Compared with the first mode, the second mode periodically sends the period numbers to the first front-end platforms in the non-master control production cluster systems through the master control first front-end platform instead of frequently requesting the period numbers from the master control first front-end platforms by a plurality of non-master control first front-end platforms, so that the load of the master control first front-end platform is reduced, and the system performance is improved.

Further, the master control first front-end platform also counts the number of write requests of the host received in the current period, and after the current period is finished, the master control production cluster system sends the period number of the current period and the corresponding number of write requests of the host received in the current period to the disaster recovery center.

Step 24, the production cluster system writes the write request with the marked cycle number into the remote replication main LUN of the production cluster system.

Optionally, the first front-end platform in the production cluster system issues the write request marked with the cycle number of the current cycle to the first service processing device in the first back-end platform in the production cluster system, and then the first service processing device in the first back-end platform in the production cluster system writes the write request marked with the cycle number into the remote copy main LUN.

Step 25: the production cluster system marks the sequence number for the write request marked with the cycle number according to the sequence written into the local remote copy main LUN.

Optionally, the first service processing apparatus in the production cluster system marks sequence numbers for the write requests with marked cycle numbers according to the sequence of writing to the local remote copy master LUNs.

Step 26: and the production cluster system sends the write request with the marked cycle number and sequence number to the disaster recovery center.

Optionally, the first service processing device in the production cluster system sends the write request with the cycle number and the sequence number marked to the disaster recovery center.

Optionally, the first service processing apparatus may write the write request with the cycle number and the sequence number marked into a cache, and send the write request to the disaster recovery center through the cache.

In the embodiment of the invention, the storage system of the production center is a distributed storage system, wherein each production cluster system is respectively used for processing write requests of different physical address spaces. After receiving the write request, when the production cluster system judges that the physical address space processed by the production cluster system comprises the physical address of the write request, marking a period number for the write request, and marking a sequence number for the write request according to the sequence of writing the write request into the remote copy master LUN. After the production cluster system sends the write request marked with the cycle number and the sequence number to the disaster recovery center, the disaster recovery center receives the write request marked with the cycle number and the sequence number, and the disaster recovery center can write in the remote copy slave LUN according to the sequence number for the write request in the same cycle. Therefore, the problem that when the sequence of a plurality of write requests with conflicting access addresses reaching the disaster recovery center in the same period is inconsistent with the writing sequence of the production center is avoided, the data stored in the remote copy main LUN of the production center is inconsistent with the data stored in the remote copy slave LUN of the disaster recovery center.

It should be noted that the asynchronous remote replication method shown in fig. 1 can also be applied to a non-distributed storage system, that is, a production center storage system only includes one production cluster system shown in fig. 2B. A non-distributed storage system may also be considered a special case of a distributed storage system. Fig. 2C is a flowchart of an asynchronous remote copy method applied to a non-distributed storage system according to an embodiment of the present invention:

step 201: the production cluster system receives a write request issued by a host of a production center.

Optionally, the first front-end platform in the production cluster system receives a write request issued by a host of the production center.

Since the storage system of the production center in this example only contains one production cluster system, the determination step of step 22 in fig. 2A need not be performed.

Step 202: the production cluster system acquires the cycle number of the current cycle and marks the cycle number for the write request according to the acquired cycle number of the current cycle.

Optionally, the first front-end platform in the production cluster system obtains the cycle number of the current cycle, and marks the cycle number for the write request according to the obtained cycle number of the current cycle, where the cycle number may be set by the first front-end platform in the production cluster system, or may be set by a device in the production platform for setting the current cycle number and periodically delivered to the first front-end platform in the production cluster system.

Step 203: the production cluster system writes the write request marked with the cycle number of the current cycle to the local remote copy master LUN.

The first front-end platform in the production cluster system issues the write request marked with the cycle number of the current cycle to the first service processing device in the first back-end platform in the production cluster system, and then the first service processing device in the first back-end platform in the production cluster system writes the write request marked with the cycle number into the remote copy main LUN.

In step 204, the production cluster system marks the sequence number for the write request with the marked cycle number according to the sequence written into the remote copy master LUN.

Optionally, the first service processing apparatus in the production cluster system marks the sequence number for the write request with the marked cycle number according to the sequence of writing to the local remote copy master LUN.

Step 205, the production cluster system sends the write request with the marked cycle number and sequence number to the disaster recovery center.

Optionally, the first service processing device in the production cluster system sends the write request with the marked cycle number and sequence number to the disaster recovery center. Further, the first service processing device in the production cluster system may write the write request with the cycle number and the sequence number marked into the cache, and periodically send the write request to the disaster recovery center through the cache.

EXAMPLE III

Corresponding to the first embodiment, this embodiment describes the technical solution of the asynchronous remote copy method in the present invention from the perspective of a disaster recovery center. Fig. 3 is a flowchart of another asynchronous remote copy method according to an embodiment of the present invention. The execution subject of the embodiment is a storage system of the disaster recovery center. As shown in fig. 3, the present embodiment includes:

step 31: the disaster recovery center receives a write request sent by the production center, and the write request is marked with a cycle number and a sequence number.

Step 32: the disaster recovery center judges whether all write requests corresponding to one period number are received.

Step 33: and when determining that all the write requests corresponding to one cycle number are received, the disaster recovery center writes the received write requests into the remote copy slave LUN according to the cycle number and the sequence number marked in the write requests.

The method for the disaster recovery center to determine whether all write requests corresponding to one cycle number have been received in step 32 includes, but is not limited to:

in the first mode, for the case that the duration of each cycle of the production center is equal, and the number of write requests sent by the host received in each cycle is variable. When one period is finished, the production center sends the period number of the current period and the corresponding write request number sent by the host computer received in the current period to the disaster recovery center; the disaster recovery center determines whether all the write requests corresponding to a cycle number have been received according to the cycle number and the corresponding number of write requests sent by the production center, and the cycle number and the sequence number marked in the write request received in step 31.

And secondly, the duration of each period of the production center is not fixed, and the number of the write requests sent by the host received in each period is a fixed preset value. The disaster recovery center can determine whether all the write requests corresponding to a cycle number have been received according to the cycle number and the sequence number marked in the write requests received in step 31, for example, when the same cycle number is identified and the number of the write requests with different sequence numbers reaches the fixed preset value, it indicates that all the write requests corresponding to a cycle number have been received.

According to the embodiment of the invention, the write request received by the disaster recovery center is marked with the cycle number and the sequence number, and the write request disaster recovery center in the same cycle can write the remote copy slave LUN according to the sequence number. Therefore, the problem that when the sequence of a plurality of write requests with conflicting access addresses reaching the disaster recovery center in the same period is inconsistent with the writing sequence of the production center is avoided, the data stored in the remote copy main LUN of the production center is inconsistent with the data stored in the remote copy slave LUN of the disaster recovery center.

Example four

In the embodiment, specific application examples of the asynchronous remote replication method shown in fig. 3 in a distributed storage system and a non-distributed storage system are respectively given.

Fig. 4A is a flowchart illustrating an application of another asynchronous remote replication method to a distributed storage system according to an embodiment of the present invention. Fig. 4B is a schematic structural diagram of an embodiment of a disaster recovery center according to an embodiment of the present invention. This embodiment describes a technical solution of the asynchronous remote copy method from the perspective of a disaster recovery center. As shown in fig. 4B, the distributed storage system of the disaster recovery center in this embodiment includes at least two disaster recovery cluster systems. Each disaster recovery cluster system comprises a second front-end platform and a second back-end platform, wherein the second back-end platform comprises a second service processing device and a remote copy slave LUN, and optionally the second back-end platform further comprises a remote cache. In this embodiment, the disaster recovery center determines whether all the write requests corresponding to one cycle number have been received by adopting the first method of determining whether all the write requests corresponding to one cycle number have been received in the third embodiment. As shown in fig. 4A, the present embodiment includes:

step 41: a disaster recovery cluster system in a disaster recovery center receives a write request sent by a production center, and the write request is marked with a cycle number and a sequence number. The write request is sent by a production cluster system in the production center that has the same physical address space as the disaster recovery cluster system.

Optionally, a second front-end platform in the disaster recovery cluster system receives a write request sent by a production cluster system in the production center.

That is, the physical address space processed by the disaster recovery cluster system that receives the write request in the disaster recovery center is the same as the physical address space processed by the production cluster system that sends the write request in the production center.

Step 42: the disaster recovery cluster system judges whether all write requests corresponding to a period number have been received or not according to the period number and the corresponding write request number sent by the production center and the period number and the sequence number marked in the temporarily-stored received write requests, if the judgment result is that all write requests corresponding to a period number have been received, step 43 is executed, otherwise, step 41 is returned, and the write requests sent by the production center are continuously received.

Optionally, after receiving the write request sent by the first service processing device of the production center, the second front-end platform of the disaster recovery cluster system issues the write request to the second service processing device in the second back-end platform of the disaster recovery cluster system, and the second service processing device may write the received write request into the remote cache of the second back-end platform. Specifically, according to the cycle number in the write request, the second service processing apparatus writes the write request into the queue corresponding to the cycle number in the remote cache. For example, the write requests in the remote cache are stored in a linked list form, one cycle number corresponds to one linked list, and the write requests in the linked list are sorted by sequence numbers. And when the second service processing device writes the write request into the chain table in the remote cache according to the cycle number of the write request, inserting the write request into a corresponding position in the chain table according to the sequence number marked in the write request. Fig. 4C is a schematic diagram of a write request linked list stored in a remote cache in the disaster recovery cluster system according to the embodiment of the present invention. As shown in fig. 4C, each cycle number corresponds to a linked list, and the write requests in the linked list are sorted by sequence number.

Further, the second front-end platform of the disaster recovery cluster system may also receive the cycle number sent by the production center and the number of write requests received in the cycle corresponding to the cycle number, and send the received cycle number and the corresponding number of write requests to the second service processing device in the second back-end platform of the disaster recovery cluster system. And the second service processing device judges whether all the write requests corresponding to one period number are received or not according to the period number and the corresponding write request number sent by the second front-end platform and the temporarily stored period number and sequence number marked in the received write requests. Specifically, the second service processing device determines whether the number of received write requests with the same cycle number and different sequence numbers is the same as the number of write requests corresponding to the cycle number sent by the production center; if the number of the received write requests with the same cycle number and different sequence numbers is the same as the number of the write requests corresponding to the cycle number sent by the production center, determining that all the write requests corresponding to the cycle number are received; otherwise, determining that all write requests corresponding to the cycle number are not received.

Step 43: and when the disaster recovery cluster system receives all the write requests corresponding to a cycle number, judging whether the write requests with access address conflict exist in all the write requests corresponding to the cycle number. If yes, go to step 44, otherwise go to step 45.

Step 44: and if the write request with conflicting access addresses exists, the disaster recovery cluster system sequentially writes the write requests corresponding to the cycle number into the remote copy slave LUN of the disaster recovery cluster system according to the sequence number in the write request.

Optionally, the second service processing apparatus of the disaster recovery cluster system searches for a queue corresponding to a cycle number in the write request in a queue of the remote cache, and writes the write request in the queue into the remote copy slave LUN according to the sequence number in the write request.

Step 45: and if the write request with conflicting access addresses does not exist, the disaster recovery cluster system writes the write request corresponding to the cycle number into the remote copy slave LUN in parallel.

Optionally, the second service processing apparatus of the disaster recovery cluster system searches for a queue corresponding to a cycle number in the write request in a queue of the remote cache, and concurrently writes the write request corresponding to the cycle number into the remote copy slave LUN. For example, in a period T2, the Host1 and the Host2 of the production center issue an a write request for accessing the logical address LBA1 and a B write request for accessing the logical address LBA1 to the first front-end platform first, and the order of writing the write requests in the local remote copy master LUN of the first back-end platform is a first and then B. When the B write request arrives at the disaster recovery center before the A write request due to network delay and the like and is written into the remote cache of the second rear-end platform of the disaster recovery center before the A write request, the second rear-end platform writes the A write request into the remote cache firstly according to the cycle number and the sequence number, writes the B request into the remote cache, and writes the remote copy slave LUN according to the remote cache, thereby avoiding the problem of inconsistency of data stored in the remote copy master LUN and the remote copy slave LUN.

In the embodiment of the invention, the storage system of the disaster recovery center is a distributed storage system, and each disaster recovery cluster system is respectively used for processing write requests of different physical address spaces. After receiving the write requests sent by the production cluster systems in the production center, which have the same physical address space processed by the disaster recovery cluster system, the disaster recovery cluster system judges whether all the write requests corresponding to one cycle number have been received. And when all the write requests are determined to be received, judging whether the write requests with conflicting physical addresses exist in all the write requests corresponding to the cycle number, so as to determine whether the write requests with the cycle number are sequentially written into the remote copy slave LUN or are concurrently written into the remote copy slave LUN according to the sequence number marked in the write requests.

It should be noted that the asynchronous remote replication method shown in fig. 3 may also be applied to a non-distributed storage system, that is, a disaster tolerance central storage system only includes one disaster tolerance cluster system shown in fig. 4B. The non-distributed storage system can also be regarded as a specific example of the distributed storage system, and the processing flow is basically similar to that of fig. 4A, except that in step 41, because there is only one disaster recovery cluster system, it is not necessary to limit the received write request to the write request sent by the production cluster system in the same physical address space as that processed by the disaster recovery cluster system in the production center, and only the write request sent by the production center is needed.

EXAMPLE five

Fig. 2B is a schematic structural diagram of a distributed storage system of a production center according to an embodiment of the present invention. As shown in fig. 2B, the production center comprises at least one production cluster system, each production cluster system comprises a first front-end platform 51 and a first back-end platform 52, and the first back-end platform comprises a first service processing device 521 and a remote copy master LUN 522.

The first front-end platform 51 is configured to, after receiving the write request from the host, mark a cycle number for the write request according to the cycle number of the current cycle, and send the write request with the marked cycle number to the first service processing apparatus 521 in the first back-end platform 52 in the production cluster system to which the first front-end platform belongs.

The first service processing device 521 is configured to write the write request with the marked cycle number into the remote copy master LUN, mark a sequence number for the write request with the marked cycle number according to the sequence written into the remote copy master LUN, and send the write request with the marked cycle number and sequence number to the disaster recovery center.

Further, the production center comprises at least two production cluster systems, that is, when the storage system of the production center is a distributed storage system: the first front-end platform 51 is further configured to, before the period number according to the current period is the write request mark period number, determine a physical address of the write request according to the logical address in the received write request and an address mapping table in which a mapping relationship between the logical address and the physical address is stored, and determine that the physical address of the write request is in a physical address space processed by the production cluster system to which the physical address belongs.

Further, the production center comprises at least two production cluster systems, namely a master production cluster system and at least one non-master production cluster system;

the first front-end platform 51 in the master control production cluster system is further configured to set a cycle number of a current cycle, and issue the set cycle number of the current cycle to each non-master control production cluster system;

the first front-end platform 51 in the master control production cluster system is further configured to mark a cycle number of a current cycle set by the first front-end platform in the write request;

the first front-end platform 51 in the master control production cluster system is further configured to count the number of write requests received by the host in the current period; after the current period is finished, sending the number of the write requests of the host received by the first front-end platform in the current period and the period number of the current period to a disaster recovery center;

the first front end platform 51 in the non-master production cluster system is further configured to obtain a cycle number of a current cycle periodically issued by the first front end platform in the master production cluster system.

The first front-end platform 51 in the non-master production cluster system is further configured to mark the acquired cycle number of the current cycle in the write request.

The working mechanism of each device is described with reference to the corresponding embodiment in fig. 2A, and is not described again here.

When the production center includes at least two production cluster systems, the storage system of the production center in the embodiment of the present invention is a distributed storage system, and each production cluster system is respectively used for processing write requests of different physical address spaces. The processed physical address space comprises a production cluster system of the physical address of the write request, wherein the first front-end platform marks the period number for the write request according to the period number issued by the main control first front-end platform. The first service processing device of the production cluster system marks sequence numbers for the write requests according to the sequence of the write requests written into the remote copy main LUNs. The disaster recovery center receives the write request marked with the cycle number and the sequence number, and for the write request in the same cycle, the disaster recovery center can write in the remote copy slave LUN according to the sequence number. Therefore, the problem that when the sequence of a plurality of write requests with conflicting access addresses reaching the disaster recovery center in the same period is inconsistent with the writing sequence of the production center is avoided, the data stored in the remote copy main LUN of the production center is inconsistent with the data stored in the remote copy slave LUN of the disaster recovery center.

EXAMPLE six

Fig. 4B is a schematic structural diagram of an embodiment of a disaster recovery center according to an embodiment of the present invention. As shown in fig. 4B, the disaster recovery center includes at least one disaster recovery cluster system, the disaster recovery cluster system includes a second front-end platform 61 and a second back-end platform 62, and the second back-end platform 62 includes a second service processing device 621 and a remote copy slave LUN 622. Wherein,

and the second front-end platform 61 is configured to receive a write request sent by the production center, where the write request is marked with a cycle number and a sequence number.

Further, when the disaster recovery center comprises at least two disaster recovery cluster systems: the second front-end platform 61 is specifically configured to receive a write request sent by a production cluster system in the production center, where the physical address space processed by the disaster recovery cluster system to which the second front-end platform 61 belongs is the same.

The second service processing device 621 is configured to determine whether the second front-end platform 61 has received all write requests corresponding to a period number, and write the received write request into the remote copy slave LUN622 according to the period number and the sequence number marked in the write request when determining that all write requests corresponding to a period number have been received.

Optionally, the disaster recovery cluster system further includes a remote cache 623.

The remote buffer 623 is configured to store the write requests received by the second front-end platform 61 in a linked list manner, specifically, each cycle number corresponds to one linked list, the write requests in the linked list corresponding to each cycle number are sorted by a sequence number,

the second service processing device 621 determines whether the second front-end platform 61 has received all write requests corresponding to a cycle number according to the linked list stored in the remote cache 623.

The working mechanism of each device is described with reference to the corresponding embodiment in fig. 4A, and is not described again here.

When the disaster recovery center includes at least two disaster recovery cluster systems, the storage system of the disaster recovery center in the embodiment of the present invention is a distributed storage system, and a physical address space of a write request for processing by each disaster recovery cluster system is different from physical address spaces of write requests for processing by other disaster recovery cluster systems in the disaster recovery center. The physical address space processed by the disaster recovery cluster system receiving the write request in the disaster recovery center is the same as the physical address space processed by the production cluster system sending the write request in the production center. When the second service processing device of the disaster recovery cluster system receives the write request forwarded by the second front-end platform, whether all the write requests corresponding to one period number have been received is judged according to the number of the write requests and the period number forwarded by the second front-end platform. And when all the write requests are determined to be received, judging whether the write requests with conflicting physical addresses exist in all the write requests corresponding to the cycle number, so as to determine whether the write requests with the cycle number are sequentially written into the remote copy slave LUN or are concurrently written into the remote copy slave LUN according to the sequence number marked in the write requests.

EXAMPLE seven

Fig. 5 is a schematic structural diagram of a second service processing apparatus in a disaster recovery center according to an embodiment of the present invention. As shown in fig. 5, the second traffic processing device 621 includes: a request number judging module 6211, a conflict judging module 6212, a serial writing module 6213, and a concurrent writing module 6214.

The second front-end platform is further used for receiving the period number sent by the production center and the number of write requests received in the period corresponding to the period number.

The request number determining module 6211 is configured to determine whether all write requests corresponding to a cycle number have been received according to the cycle number and the write request number sent by the production center and received by the second front-end platform, and the cycle number and the sequence number marked in the received write request that has been temporarily stored.

The conflict determining module 6212 is configured to determine whether there is a write request with an access address conflict in all write requests corresponding to a period number when the request number determining module 6211 determines that all write requests corresponding to the period number have been received.

A serial write module 6213, configured to, if the conflict determination module 6212 determines that there is a write request with conflicting access addresses, sequentially write the write requests corresponding to the cycle number into the remote copy slave LUN according to the sequence number in the write request.

A concurrent writing module 6214, configured to, if the conflict judging module 6212 judges that there is no writing request with an access address conflict, concurrently write the writing request corresponding to the cycle number into the remote copy slave LUN.

Example eight

Fig. 6 is a schematic structural diagram of an asynchronous remote copy system according to an embodiment of the present invention. As shown in fig. 6, the production center includes at least one production cluster system, each production cluster system includes a first front-end platform 51 and a first back-end platform 52, and the first back-end platform 52 includes a first service processing device 521 and a remote copy master LUN 522. The disaster recovery center comprises at least one disaster recovery cluster system, the disaster recovery cluster system comprises a second front-end platform 61 and a second back-end platform 62, and the second back-end platform 62 comprises a second service processing device 621 and a remote copy slave LUN 622.

The working mechanism of each device is described in the corresponding embodiment of fig. 2B and fig. 4B, and is not described again here.

Those of ordinary skill in the art will understand that: all or part of the steps for implementing the method embodiments may be implemented by hardware related to program instructions, and the program may be stored in a computer readable storage medium, and when executed, the program performs the steps including the method embodiments; and the aforementioned storage medium includes: various media that can store program codes, such as ROM, RAM, magnetic or optical disks.

Finally, it should be noted that: the above examples are only intended to illustrate the technical solution of the present invention, but not to limit it; although the present invention has been described in detail with reference to the foregoing embodiments, it will be understood by those of ordinary skill in the art that: the technical solutions described in the foregoing embodiments may still be modified, or some technical features may be equivalently replaced; and such modifications or substitutions do not depart from the spirit and scope of the corresponding technical solutions of the embodiments of the present invention.

Claims

1. An asynchronous remote copy method, comprising:

2. The method of claim 1, further comprising:

and after the current period is finished, sending the period number of the current period and the write request number of the host received in the current period to the disaster recovery center.

3. The method of claim 2, wherein the storage system of the production center comprises at least two production cluster systems, and the marking of the cycle number for the write request according to the cycle number of the current cycle comprises:

each production cluster system determines the physical address of the write request according to the logical address in the write request and an address mapping table which stores the mapping relation between the logical address and the physical address;

judging whether a physical address space processed by the production cluster system comprises a physical address of the write request;

if the physical address space processed by the production cluster system comprises the physical address of the write request, the production cluster system acquires the cycle number of the current cycle and marks the cycle number of the current cycle in the write request; otherwise, the write request is ignored or forwarded to other production cluster systems;

the writing of the write request with the marked cycle number into the remote copy main LUN specifically includes:

the production cluster system writes the write request with the marked cycle number into a remote replication master LUN of the production cluster system.

4. The method of claim 3, wherein the at least two production cluster systems are one master production cluster system and at least one non-master production cluster system;

the production cluster system is a non-master control production cluster system, and the production cluster system acquires the cycle number of the current cycle, and specifically comprises the following steps:

the production cluster system receives the cycle number of the current cycle issued by the master control production cluster system according to the request of the production cluster system, or

The production cluster system receives a current cycle number periodically issued by the master control production cluster system;

the production cluster system is a master control production cluster system, and the production cluster system acquires the cycle number of the current cycle, and specifically comprises the following steps:

the production cluster system takes the cycle number of the current cycle set by the production cluster system as the cycle number of the current cycle;

after the current period is finished, sending the write request number of the host and the period number of the current period received in the current period to the disaster recovery center, specifically:

the master control production cluster system counts the number of write requests received by the host in the current period;

and after the current period is finished, the master control production cluster system sends the period number of the current period and the write request number of the host received in the current period to a disaster recovery center.

5. An asynchronous remote copy method, comprising:

judging whether all write requests corresponding to one period number are received;

6. The method of claim 5, wherein before said determining whether all write requests for a cycle number have been received, further comprising:

receiving a period number sent by a production center and the number of write requests received in a period corresponding to the period number;

the determining whether all write requests corresponding to one cycle number have been received specifically includes:

and judging whether all the write requests corresponding to one cycle number are received or not according to the cycle number sent by the production center, the number of the write requests received in the cycle corresponding to the cycle number, and the cycle number and the sequence number marked in the temporarily-stored received write requests.

7. The method according to claim 5 or 6, wherein when the determination result is that all write requests corresponding to one cycle number have been received, the writing the received write request into the remote copy slave LUN according to the cycle number and the sequence number marked in the write request includes:

judging whether write requests with access address conflict exist in all write requests corresponding to the period number;

if the write requests with conflicting access addresses exist, writing the write requests corresponding to the cycle number into the remote copy slave LUN in sequence according to the sequence number marked in the write requests;

and if the write request with the conflict of the access address does not exist, the write request corresponding to the cycle number is concurrently written into the remote copy slave LUN.

8. The method according to claim 5 or 6, wherein when the storage system of the disaster recovery center includes at least two disaster recovery cluster systems, the disaster recovery center receives a write request sent by a production center, specifically:

a disaster tolerance cluster system in a disaster tolerance center receives a write request sent by a production cluster system in the production center, wherein the physical address space of the production cluster system is the same as that of the disaster tolerance cluster system;

the writing of the received write request into the local remote copy slave LUN specifically includes:

and the disaster recovery cluster system in the disaster recovery center writes the received write request into the remote copy slave LUN of the disaster recovery cluster system.

9. A production center comprising at least one production cluster system, said production cluster system comprising a first front-end platform and a first back-end platform, said first back-end platform comprising first business processing devices and a remote copy master LUN, wherein:

10. The production center of claim 9, wherein the production center comprises at least two production cluster systems:

the first front-end platform is further configured to determine, before the period number according to the current period is the write request mark period number, a physical address of the write request according to a logical address in the received write request and an address mapping table in which a mapping relationship between the logical address and the physical address is stored; and judging that the physical address space processed by the production cluster system comprises the physical address of the write request.

11. The production center of claim 9 or 10, wherein the production center comprises a master production cluster system and at least one non-master production cluster system;

the first front-end platform in the master control production cluster system is also used for setting the cycle number of the current cycle and periodically sending the set cycle number of the current cycle to each non-master control production cluster system;

the first front-end platform in the master control production cluster system is further configured to mark, in the write request, a cycle number of a current cycle set by the first front-end platform in the master control production cluster system;

the first front-end platform in the master control production cluster system is also used for counting the number of write requests received by the host in the current period; after the current period is finished, sending the number of the write requests of the host received by the first front-end platform in the current period and the period number of the current period to a disaster recovery center;

the first front-end platform in the non-master control production cluster system is also used for acquiring the cycle number of the current cycle periodically issued by the first front-end platform in the master control production cluster system;

the first front-end platform in the non-master control production cluster system is further configured to mark, in the write request, a cycle number of a current cycle that is periodically issued by the first front-end platform in the master control production cluster system.

12. A disaster recovery center, comprising at least one disaster recovery cluster system, wherein the disaster recovery cluster system comprises a second front-end platform and a second back-end platform, and the second back-end platform comprises a second service processing device and a remote copy slave LUN, wherein:

13. The disaster recovery center of claim 12, wherein:

the second front-end platform is also used for receiving the period number sent by the production center and the request number received in the period corresponding to the period number;

the second service processing apparatus specifically includes:

the request number judging module is used for judging whether all the write requests corresponding to one period number are received or not according to the period number and the write request number received by the second front-end platform and the temporarily stored period number and sequence number marked in the received write requests;

the conflict judging module is used for judging whether write requests with access address conflicts exist in all write requests corresponding to the period number when the request number judging module determines that all write requests corresponding to the period number are received;

the serial write module is used for sequentially writing the write requests corresponding to the cycle number into the remote copy slave LUN according to the sequence number in the write requests if the write requests with access address conflict exist;

and the concurrent writing module is used for writing the write request corresponding to the cycle number into the remote copy slave LUN in a concurrent manner if the write request with the access address conflict does not exist.

14. The disaster recovery center of claim 12 wherein said disaster recovery cluster system further comprises:

the remote cache is used for storing the write requests received by the second front-end platform in a linked list mode, specifically, each cycle number corresponds to one linked list, and the write requests in the linked list corresponding to each cycle number are sorted according to the sequence number;

the second service processing device is further configured to determine whether the second front-end platform has received all write requests corresponding to one cycle number according to the linked list stored in the remote cache.

15. The disaster recovery center according to claim 12 or 13, wherein when said disaster recovery center comprises at least two disaster recovery cluster systems:

and the second front-end platform is further configured to determine, when receiving the write request sent by the production center, that the write request is sent by the production cluster system in the production center, where the physical address space of the write request is the same as that of the production cluster system to which the write request is processed.

16. An asynchronous remote copy system, comprising: