Group generation apparatus and group determination method

Abstract

To automatically determine a consistency group for providing consistency to a backup of a volume related to a distributed transaction.SOLUTION: A group generation apparatus determines a consistency group for providing consistency to replication processing from a first site, including a plurality of volumes, to a second site, including a plurality of volumes. The group generation apparatus includes a group determination section that forms one or more first groups that are groups of volumes at the first site on the basis of a relationship of distributed transactions at the first site, forms one or more second groups that are groups of volumes at the second site on the basis of a relationship of distributed transactions at the second site, identifies a correspondence relationship between the first group and the second group, and includes the first group and the second group that correspond to each other on the basis of the identified correspondence relationship in the same consistency group.SELECTED DRAWING: Figure 1

Description

[Technical Field]

[0001] The present invention relates to a group generation device and a method for determining a group. [Background technology]

[0002] Replication processing is known as one type of backup processing in the field of storage. Patent Document 1 discloses an apparatus including at least one processing device including a processor coupled to a memory. The at least one processing device is configured to identify a storage volume to be added to a first consistency group of a first synchronous replication session between a first storage system and a second storage system in an active-active configuration, create a second synchronous replication session for the added storage volume between the first storage system and the second storage system, and merge the first and second synchronous replication sessions in response to one or more specified criteria. The second synchronous replication session is illustratively configured to be completely independent from the first synchronous replication session. Merging the first and second synchronous replication sessions in response to one or more specified criteria illustratively includes merging the first and second synchronous replication sessions in response to the second synchronous replication session reaching a specified steady state. [Prior art documents] [Patent documents]

[0003] [Patent Document 1] U.S. Patent No. 1,127,5765 Summary of the Invention [Problem to be solved by the invention]

[0004] The invention described in Patent Document 1 cannot automatically determine a consistency group for ensuring consistency in backups of volumes related to distributed transactions. [Means for solving the problem]

[0005] A group generation device according to a first aspect of the present invention is a group generation device that determines a consistency group to ensure consistency in replication processing from a first site that includes a plurality of volumes to a second site that also includes a plurality of volumes, and includes a group determination unit that forms one or more first groups that are groups of volumes at the first site based on distributed transaction relationships at the first site, forms one or more second groups that are groups of volumes at the second site based on distributed transaction relationships at the second site, identifies a correspondence relationship between the first group and the second group, and includes the corresponding first group and second group in the same consistency group based on the identified correspondence relationship. A group determination method according to a second aspect of the present invention is a group determination method for determining a consistency group to ensure consistency in replication processing from a first site including a plurality of volumes to a second site also including a plurality of volumes, and includes forming one or more first groups which are groups of volumes at the first site based on distributed transaction relationships at the first site, forming one or more second groups which are groups of volumes at the second site based on distributed transaction relationships at the second site, identifying a correspondence relationship between the first groups and the second groups, and including the corresponding first groups and second groups in the same consistency group based on the identified correspondence relationship. [Effects of the Invention]

[0006] According to the present invention, a consistency group can be automatically determined to ensure consistency in backups of volumes related to distributed transactions. [Brief explanation of the drawings]

[0007] [Figure 1] Overall configuration of the data synchronization system [Figure 2] Hardware configuration diagram of on-premise server and cloud server [Figure 3] Consistency copy controller hardware configuration diagram [Figure 4] A diagram showing an example of a distributed transaction set list, a volume service relationship list, and a distributed transaction graph contained in a data table. [Figure 5] An example diagram showing related lists, consistency group sets, and replication lists in a data table [Figure 6] Flowchart showing the processing of the group determination unit [Figure 7] 6. A flowchart showing detailed processing when analyzing source code in step S32 of FIG. [Figure 8] An example of an undirected graph [Figure 9] A flowchart showing detailed processing when an API is used in step S32 of FIG. 6. [Figure 10] A diagram showing an example of a user interface DETAILED DESCRIPTION OF THE INVENTION

[0008] -First embodiment- A first embodiment of a data synchronization system will be described below with reference to FIGS.

[0009] 1 is a diagram showing the overall configuration of a data synchronization system 1. The data synchronization system 1 includes an on-premise server 3000, a cloud server 4000, and a consistency copy controller 6000. The consistency copy controller 6000 performs replication, with the system on the on-premise server 3000 as the replication source and the system on the cloud server 4000 as the replication destination. The on-premise server 3000 and the cloud server 4000 have a so-called active-active configuration.

[0010] Hereinafter, the on-premise server 3000 will also be referred to as "local" and the cloud server 4000 will also be referred to as "remote." However, the on-premise server 3000 and the cloud server 4000 are merely named as typical environments indicating different environments, and they can also be referred to as the "first site" and the "second site." Furthermore, the physical distance between the first site and the second site is not important; they can be located within the same server rack or can be thousands or tens of thousands of kilometers apart.

[0011] The on-premises server 3000 includes first management software 3100 and on-premises storage 3200. The first management software 3100 is management software that runs in an on-premises environment and is also called "orchestration software" or "orchestration tool." For example, the first management software 3100 is Kubernetes or OpenShift. The first management software 3100 manages multiple microservices. While FIG. 1 illustrates the first management software 3100 running a first microservice 3110 and a second microservice 3120, the first management software 3100 may manage three or more microservices. The first management software 3100 and the on-premises storage 3200 support APIs and respond to queries via the API, for example, from the consistency copy controller 6000.

[0012] Each microservice is realized by one or more pods. A pod is a collection of one or more containers. Reference numerals 3111 to 3116 indicate a set of pods that execute applications on the on-premise server 3000. Reference numerals 4111 to 4116 indicate a set of pods that execute applications on the cloud server 4000. In FIG. 1, the first microservice 3110 and the second microservice 3120 both have three pods, but the number of pods that implement each microservice may be different, as long as it is one or more. In this embodiment, a pod that manages a database (DB) is called a "DB pod."

[0013] Because the DB pod reads and writes from and to the volume in which the database is stored, the DB pod is connected to one of the volumes in the on-premises storage 3200. It is not a mandatory configuration for a microservice to include a DB pod. However, the microservices managed by the first management software 3100 perform distributed transactions. The first management software 3100 has a distributed transaction management framework 3130 that manages distributed transactions in the on-premises server 3000. The distributed transaction management framework 3130 tracks data flows and transactions.

[0014] The on-premise storage 3200 is one or more non-volatile storage devices, and virtualisation technology may be applied to it. The on-premise storage 3200 includes multiple volumes. Some volumes included in the on-premise storage 3200 form a local CTG 3210 through processing described below. "CTG" stands for consistency group. Multiple local CTGs 3210 may be formed in the on-premise storage 3200. Data stored in the on-premise storage 3200 is set to be readable by the consistency copy controller 6000. Hereinafter, the local CTG 3210 will also be referred to as the "first group".

[0015] In this embodiment, at least one distributed transaction is executed in the on-premise server 3000. Therefore, the on-premise storage 3200 has at least two volumes. As described above, replication is performed from the on-premise server 3000 to the cloud server 4000, and the same processing as that of the on-premise server 3000 is performed, so that at least one distributed transaction is also executed in the cloud server 4000.

[0016] The cloud server 4000 includes second management software 4100 and cloud storage 4200. The second management software 4100 is management software that operates in a cloud environment and is the same type of software as the first management software 3100. The second management software 4100 manages one or more microservices. The second management software 4100 includes a distributed transaction management framework 4130 that manages distributed transactions in the cloud server 4000.

[0017] The cloud storage 4200 is one or more non-volatile storage devices, and virtualization technology may be applied. The cloud storage 4200 includes multiple volumes. Some volumes included in the cloud storage 4200 form a remote CTG 4210 through processing described below. Multiple remote CTGs 4210 may be formed in the cloud storage 4200. Each volume of the cloud storage 4200 is set to be writable by the consistency copy controller 6000. Hereinafter, the remote CTG 4210 is also referred to as the "second group."

[0018] The consistency copy controller 6000 includes a group determination unit 6200, a copy controller 6300, and a controller storage 6510. The group determination unit 6200 determines a group of volumes (hereinafter referred to as a "consistency group") for achieving consistent copying in the on-premise server 3000 and the cloud server 4000. The operation of the group determination unit 6200 will be described in detail below. The consistency copy controller 6000 includes a group determination unit 6200 that determines consistency groups, and can therefore also be called a "group generation device." In the following, the copy controller 6300 is also called a "copy control unit."

[0019] The copy controller 6300 performs replication processing 10 from the on-premise server 3000 to the cloud server 4000 for the consistency group determined by the group determination unit 6200. The controller storage 6510 is a non-volatile storage device. The controller storage 6510 stores in advance the source code of all pods running on the on-premise server 3000 and the cloud server 4000. Furthermore, this source code directly describes the pods that are the target of the write processing. This can also be said to mean that the write target is hard-coded in the source code.

[0020] FIG. 2 is a hardware configuration diagram of the on-premise server 3000 and the cloud server 4000. Although FIG. 2 illustrates the on-premise server 3000 and the cloud server 4000 as a single device, each of the on-premise server 3000 and the cloud server 4000 may be realized by multiple devices. The on-premise server 3000 includes a first processor 3900, a first memory 3300, a first network adapter 3500, a first storage adapter 3700, and an on-premise storage 3200, all of which are connected via a communication bus 310. The first processor 3900 is a central processing unit. The first memory 3300 is a volatile memory capable of high-speed reads and writes. The first network adapter 3500 is a device, such as a network interface card, that enables the on-premise server 3000 to communicate with other devices. The first storage adapter 3700 mediates data input and output to and from the on-premise storage 3200.

[0021] The first memory 3300 stores a server OS 3320, a pod 3303, a distributed transaction management framework 3130, first management software 3100, and data 3302. The server OS 3320 is an operation system that runs the on-premise server 3000. The pod 3303 is a general term for the pods shown in FIG. 1. The distributed transaction management framework 3130 and the first management software 3100 are as described above. The data 3302 is a general term for data stored in the first memory 3300, and is input / output to / from the on-premise storage 3200. The program stored in the first memory 3300 is a program that the first processor 3900 has expanded from a program stored in a ROM (not shown).

[0022] The cloud server 4000 includes a second processor 4900, a second memory 4300, a second network adapter 4500, a second storage adapter 4700, and a cloud storage 4200, all of which are connected via a communication bus 410. The second processor 4900 is a central processing unit. The second memory 4300 is a volatile memory that can be read and written at high speed. The second network adapter 4500 is a device, such as a network interface card, that enables the cloud server 4000 to communicate with other devices. The second storage adapter 4700 mediates the input and output of data to and from the cloud storage 4200.

[0023] The second memory 4300 stores a server OS 4320, a pod 4303, a distributed transaction management framework 4130, second management software 4100, and data 4302. The server OS 4320 is an operation system that runs the cloud server 4000. The pod 4303 is a general term for the pods shown in FIG. 1. The distributed transaction management framework 4130 and the second management software 4100 are as described above. The data 4302 is a general term for data stored in the second memory 4300, and is input / output to / from the cloud storage 4200. The program stored in the second memory 4300 is a program that the second processor 4900 has expanded from a program stored in a ROM (not shown).

[0024] 3 is a hardware configuration diagram of the consistency copy controller 6000. The consistency copy controller 6000 includes a third processor 6900, a third memory 6800, a third network adapter 6500, a third storage adapter 6700, and a controller storage 6400, which are connected by a communication bus 610. The third processor 6900 is a central processing unit. The third memory 6800 is a volatile memory that can be read and written at high speed. The third network adapter 6500 is a device, such as a network interface card, that enables the consistency copy controller 6000 to communicate with other devices. The third storage adapter 6700 mediates the input and output of data to and from the controller storage 6400.

[0025] The third memory 6800 stores a server OS 6320, a group determination unit 6200, a copy controller 6300, and a data table 1000. The server OS 6320 is an operation system that runs the consistency copy controller 6000. The data table 1000 stores data created by the group determination unit 6200.

[0026] FIG. 4 shows an example of a distributed transaction set list 1100, a volume service relation list 1200, and a distributed transaction graph 1300 contained in the data table 1000.

[0027] The distributed transaction set list 1100 shows the relationship between a transaction ID 1110, a service ID 1120, and a location 1130. The transaction ID 1110 is an identifier of a distributed transaction. The service ID 1120 is an identifier of a service. The location 1130 indicates whether the location where the service is executed is "local" or "remote." In this embodiment, the identifier of a distributed transaction is expressed as a combination of "T" and a number, and the identifier of a service is expressed as a combination of "S" and a number.

[0028] The volume service relationship list 1200 shows the relationship between a service name 1210, a service ID 1220, a volume connection destination 1230, a location 1240, and a pod ID 1250. The service name 1210 is the name of the service. The service ID 1220 is the identifier of the service and is the same as the service ID 1120 in the distributed transaction set list 1100. The volume connection destination 1230 is the identifier of the volume that is the write destination for the corresponding service. The location 1240 indicates whether the location where the service is executed is "local" or "remote." The pod ID 1250 is the identifier of the pod that executes the write process. In this embodiment, the service name is expressed as a combination of "MS" and a number, the volume is expressed as a combination of "V" and a number, and the pod identifier is expressed as a combination of "P" and a number.

[0029] The distributed transaction graph 1300 indicates the relationship between a graph ID 1310, a node ID 1320, a location 1330, a pod ID 1340, and a service ID 1350. The graph ID 1310 is an identifier of an undirected graph indicating a series of distributed transactions. In this embodiment, the identifier of an undirected graph is expressed as a combination of "G" and a number, and the identifier of a node is expressed as a combination of "N" and a number. The node ID 1320 is the identifier of a node that constitutes the undirected graph.

[0030] The location 1330 is the same as the location 1130 in the distributed transaction set list 1100 and the location 1240 in the volume service relationship list 1200. The pod ID 1340 is the same as the pod ID 1250 in the volume service relationship list 1200. The service ID 1350 is an identifier of the service, and is the same as the service ID 1120 in the distributed transaction set list 1100 and the service ID 1220 in the volume service relationship list 1200.

[0031] FIG. 5 is a diagram showing an example of an association list 1400, a consistency group set 1500, and a replication list 1600 included in the data table 1000.

[0032] The relationship list 1400 shows the relationship between a source node ID 1410 and a destination node ID 1420. The source node ID 1410 is the identifier of the node that is the source of data in a distributed transaction. The destination node ID 1420 is the identifier of the node that is the destination of data in a distributed transaction. The source node ID 1410 and the destination node ID 1420 are the same as the node ID 1320 in the distributed transaction graph 1300.

[0033] The consistency group set 1500 indicates the relationship between a transaction ID 1510 and a service name 1520. The transaction ID 1510 is an identifier of a distributed transaction and is the same as the transaction ID 1110 in the distributed transaction set list 1100. The service name 1520 is the name of the service and is the same as the service name 1210 in the volume service relationship list 1200.

[0034] The replication list 1600 shows the relationship between a CTG ID 1690, a local CTG ID 1610, a remote CTG ID 1620, a local volume 1630, a remote volume 1640, and a replication 1650. The CTG ID 1690 is an identifier of the total CTG, which is a combination of the local CTG and the remote CTG. The local CTG ID 1610 is an identifier of the local CTG. The remote CTG ID 1620 is an identifier of the remote CTG.

[0035] In this embodiment, the identifier of the total CTG is expressed as a combination of "C" and a number, the identifier of the local CTG is expressed as a combination of "L" and a number, and the identifier of the remote CTG is expressed as a combination of "R" and a number. Local volume 1630 is the identifier of a volume belonging to the local CTG. Remote volume 1640 is the identifier of a volume belonging to the remote CTG. Replication 1650 indicates whether replication is required as specified by the user, and is either "yes" or "no".

[0036] 6 is a flowchart showing the processing of the group determination unit 6200. First, in step S31, the group determination unit 6200 uses the first management software 3100 and the second management software 4100 to identify all services and pods.

[0037] In the following step S32, the group determination unit 6200 determines the grouping of pods at each of the local and remote sites, i.e., either a local CTG or a remote CTG, based on the relationship between the distributed transactions. Specifically, the group determination unit 6200 obtains the relationship between the distributed transactions by analyzing the source code or using an API. In this step, the correspondence between pods and services is also clarified. Details of the processing in this step will be described later, with the case where the source code is analyzed shown in FIG. 7 and the case where an API is used shown in FIG. 9. Note that which of the processing shown in FIG. 7 or the processing shown in FIG. 9 the group determination unit 6200 will execute may be set in advance, or may be specified by the user each time execution is performed. Alternatively, one of the pre-set processing may be executed first, and if the processing does not complete normally, the other may be executed.

[0038] In the following step S33, the group determination unit 6200 identifies the volumes mounted in each pod and generates the volume-service relationship list 1200. Specifically, the group determination unit 6200 identifies the volumes mounted in each pod using APIs provided by the first management software 3100 and the second management software 4100. In the following step S34, the group determination unit 6200 identifies the correspondence between local and remote services. The correspondence between service IDs and service names may be created in advance by a user or the like, or the group determination unit 6200 may identify the correspondence between services based on a match between service names.

[0039] In the following step S35, the group determination unit 6200 identifies the correspondence between the local CTG and the remote CTG, generates a replication list 1600, and ends the processing shown in FIG. 6. Specifically, the group determination unit 6200 first converts the pod group identified in step S32 into a volume group using the volume service relationship list 1200 generated in step S33. Next, the group determination unit 6200 clarifies the correspondence between the local volume group and the remote volume group from the result of step S34. The group determination unit 6200 then writes the clarified correspondence into the replication list 1600. However, at this stage, no instruction has been received from the user regarding the replication 1650 indicating whether replication processing is required. Here, the group determination unit 6200 may inquire of the user about whether replication is required, or may subject all volumes to replication processing. Note that when the processing shown in FIG. 6 is completed, replication processing by the copy controller 6300 becomes possible.

[0040] 7 is a flowchart showing detailed processing when analyzing source code in step S32. In step S32A1, the group determination unit 6200 reads the source code for all services in all local and remote pods. In the following step S32A2, the group determination unit 6200 analyzes the source code to identify all pods, all services, and all distributed transactions.

[0041] In the next step S32A3, the group determination unit 6200 references the calls to the write function in the source code, identifies the relationships between all distributed transactions, and creates the association list 1400. Specifically, the group determination unit 6200 searches for the descriptions of the write function in the source code to identify the source pod and destination pod for all writes between pods or services in each distributed transaction. Then, it replaces each pod with a node to create the association list 1400. In addition, the correspondence between pods and nodes is written to the distributed transaction graph 1300. However, when the processing of this step is completed, the graph ID 1310 column in the distributed transaction graph 1300 is blank.

[0042] In the next step S32A4, the group determination unit 6200 generates an undirected graph. In this undirected graph, vertices V represent the pods of each service, and edges E represent write relationships between pods. For example, an undirected graph can be generated by placing all pods identified in step S32A2 as vertices and creating edges connecting the vertices based on the association list 1400 created in step S32A3.

[0043] Figure 8 is a diagram showing an example of an undirected graph created in step S32A4. Note that this diagram does not correspond to Figures 1, 4, 5, etc. In Figure 8, Pod 3 is connected to Pod 1, Pod 2, and Pod 4. This undirected graph does not distinguish between the pod that wrote and the pod that was written to, but it shows that Pod 3 has a write-related relationship with Pod 1, Pod 2, and Pod 4.

[0044] In the next step S34A5, the group determination unit 6200 classifies the undirected graph generated in step S32A4 into clusters based on whether or not the nodes are connected. Specifically, a set of nodes connected by edges is considered to be one cluster, and nodes not connected by edges are classified into different clusters, and the pods are grouped. For example, in the example of the undirected graph shown in FIG. 8, Pods 1 to 7 form one cluster, and Pods 8 to 14 form another cluster. Note that distributed transactions are performed both locally and remotely, and there are no distributed transactions that span local and remote nodes, so in this step the pods are classified into at least two clusters.

[0045] In the following step S32A6, the group determination unit 6200 groups the pods based on the cluster classification in step S34A5. Specifically, the group determination unit 6200 assigns a graph ID to each cluster classified in step S34A5 and enters the graph ID in the graph ID 1310 of the distributed transaction graph 1300. Pods assigned the same graph ID in the distributed transaction graph 1300 belong to the same group. As described above, distributed transaction processing is not performed between local pods and remote pods, so local pods and remote pods always belong to different groups. The local CTG 3210 described above is a group of local pods. The remote CTG 4210 described above is a group of remote pods.

[0046] 9 is a flowchart showing detailed processing when an API is used in step S32. In the following step S32B1, the group determination unit 6200 identifies all pods and services using the APIs of the distributed transaction management framework 3130 and the distributed transaction management framework 4130.

[0047] In the following step S32B2, the group determination unit 6200 uses the API to identify the relationships between all distributed transactions and creates the association list 1400. Specifically, the group determination unit 6200 uses the API to identify the source pod and destination pod for all writes between pods or services in each distributed transaction. Then, the group determination unit 6200 replaces each pod with a node to create the association list 1400. In addition, the correspondence between pods and nodes is written to the distributed transaction graph 1300. However, when the processing of this step is completed, the graph ID 1310 column in the distributed transaction graph 1300 is blank. The processing of the writing steps in steps S32B3 to S32B5 is the same as steps S32A4 to S32A6, so a description thereof will be omitted. This concludes the description of the flowchart shown in FIG. 9.

[0048] FIG. 10 is a diagram illustrating an example of a user interface. The copy controller 6300 provides a user interface to the user via the third network adapter 6500. FIG. 10 illustrates CTG groups calculated by the group determination unit 6200. Reference numerals G3100 and G3200 in FIG. 10 indicate that there are two local CTGs, "L1" and "L2," and two remote CTGs, "R3" and "R4." The total CTG "C1" includes the local CTG "L1" and the remote CTG "R3," and the total CTG "C2" includes the local CTG "L2" and the remote CTG "R4." In the replication list 1600 illustrated by reference numeral G3300, only the rightmost column indicating whether replication is required is displayed as a checkbox that can be set by the user.

[0049] After checking this checkbox, the user can press the "Create replication" button indicated by the symbol G2500 at the bottom of the figure to cause the copy controller 6300 to execute replication processing. In the example shown in Fig. 10, replication processing is performed for "C1" of the total CTG, but replication processing is not performed for "C2" of the total CTG.

[0050] According to the first embodiment described above, the following advantageous effects can be obtained. (1) The consistency copy controller 6000, which can also be called a group generation device, determines a total CTG for ensuring consistency in replication processing from an on-premise server 3000 including multiple volumes to a cloud server 4000 including multiple volumes. The consistency copy controller 6000 includes a group determination unit 6200 that performs the following processing. The group determination unit 6200 forms one or more local CTGs 3210, which are groups of volumes in the on-premise server 3000, based on the relationships between distributed transactions in the on-premise server 3000, and forms one or more remote CTGs 4210, which are groups of volumes in the cloud server 4000, based on the relationships between distributed transactions in the cloud server 4000 (S32 in FIG. 6). Furthermore, the group determination unit 6200 identifies the correspondence between the local CTG 3210 and the remote CTG 4210 (S34 in FIG. 6), and includes the corresponding local CTG 3210 and remote CTG 4210 in the same total CTG based on the identified correspondence (S35 in FIG. 6).

[0051] (2) The group determination unit 6200 creates an undirected graph with pods as vertices and write relationships to volumes as edges (S32A4 in Figure 7, S32B3 in Figure 8), and classifies undirected graphs that are not connected into different local CTGs 3210 (S32A6 in Figure 7, S32B5 in Figure 8).

[0052] (3) The group determination unit 6200 identifies the relationship of the distributed transactions by analyzing the source code (S32A1 in FIG. 7). Therefore, the relationship of the distributed transactions can be identified without relying on an API such as the distributed transaction management framework 3130.

[0053] (4) Distributed transactions are managed by the distributed transaction management framework 3130 and the distributed transaction management framework 4130. The group determination unit 6200 identifies the relationship between the distributed transactions by using the APIs of the distributed transaction management framework 3130 and the distributed transaction management framework 4130 (S32B1 in FIG. 8).

[0054] (5) The consistency copy controller 6000 includes a copy controller 6300 that presents the consistency groups set by the group determination unit 6200 and provides a user interface for receiving a user's designation as to whether replication is required.

[0055] (6) The consistency copy controller 6000 includes a copy controller 6300 that executes replication processing for the total CTG.

[0056] (Variation 1) In the first embodiment described above, the group determination unit 6200 is included in the consistency copy controller 6000. However, the group determination unit 6200 may be included in the on-premise server 3000 or the cloud server 4000, or may be mounted on another device. That is, the group determination unit 6200 may be mounted on a computing device that has previously acquired source code of pods that run on the on-premise server 3000 and the cloud server 4000, or on a computing device that can make inquiries to the on-premise server 3000 or the cloud server 4000, and the group determination unit 6200 may output the calculation results to the consistency copy controller 6000, thereby achieving consistent replication as in the first embodiment.

[0057] (Variation 2) The controller storage 6510 of the consistency copy controller 6000 is pre-stored with the source code of all pods running on the on-premise server 3000 and the cloud server 4000. However, if the group determination unit 6200 always uses an API, the consistency copy controller 6000 does not need to include the controller storage 6510.

[0058] (Variation 3) The distributed transaction management framework 3130 and the distributed transaction management framework 4130 do not have to be provided.

[0059] (Variation 4) In the above-described embodiment, the formation of a consistency group has been described to achieve consistent copying in replication from the on-premise server 3000 to the cloud server 4000. However, the configuration in which the replication source is local and the replication destination is remote is merely an example, and the reverse relationship is also possible, or both may be remote, or both may be local.

[0060] (Variation 5) In the above-described embodiment, the pod to be the target of the write process is hard-coded in the source code stored in the consistency copy controller 6000. However, the pod to be the target of the write process may be identified by a combination of the source code and a setting file (not shown).

[0061] (Variation 6) The copy controller 6300 does not need to provide a user interface. For example, the copy controller 6300 may subject all of the total CTGs set by the group determination unit 6200 to replication processing without querying the user.

[0062] In each of the above-described embodiments and modifications, the functional block configurations are merely examples. Some functional configurations shown as separate functional blocks may be configured as an integrated unit, or a configuration shown in a single functional block diagram may be divided into two or more functions. Furthermore, some of the functions of each functional block may be provided by other functional blocks.

[0063] In the above-described embodiments and modifications, the programs are stored in a ROM (not shown). However, the programs may be stored in a rewritable nonvolatile device. Furthermore, the on-premise server 3000 or the cloud server 4000 may have an input / output interface (not shown), and the programs may be loaded from another device via the input / output interface and a medium available to the on-premise server 3000 or the cloud server 4000 when necessary. Here, the medium refers to, for example, a storage medium detachable from the input / output interface, or a communication medium, i.e., a wired, wireless, or optical network, or a carrier wave or digital signal propagating through the network. Furthermore, some or all of the functions implemented by the programs may be implemented by a hardware circuit or an FPGA.

[0064] The above-described embodiments and modifications may be combined with each other. Although various embodiments and modifications have been described above, the present invention is not limited to these. Other embodiments conceivable within the scope of the technical concept of the present invention are also included within the scope of the present invention. [Explanation of symbols]

[0065] 1000: Data Table 1100: Distributed Transaction Set List 1110: Transaction ID 1200: Volume Service Relationship List 1300: Distributed Transaction Graph 1400: Related Lists 1600: Replication List 3000: On-premise server 3100: Primary management software 3130: Distributed Transaction Management Framework 4000: Cloud server 4100: Secondary management software 4130: Distributed Transaction Management Framework 6000: Consistency Copy Controller 6200: Group Decision Department 6300: Copy Controller

Claims

1. 1. A group generation device that determines a consistency group for ensuring consistency in a replication process from a first site including a plurality of volumes to a second site including a plurality of volumes, a group determination unit that forms one or more first groups, which are groups of volumes at the first site, based on the relationship of distributed transactions at the first site, forms one or more second groups, which are groups of volumes at the second site, based on the relationship of distributed transactions at the second site, identifies a correspondence between the first groups and the second groups, and includes the corresponding first groups and second groups in the same consistency group based on the identified correspondence.

2. 2. The group generation device according to claim 1, the group determination unit creates an undirected graph with pods as vertices and relationships of writing to the volumes as edges, and classifies the undirected graphs that are not in a connection relationship into different first groups; A group generation device, in which the pod is connected to the volume, or the pod writes to other pods connected to the volume.

3. 2. The group generation device according to claim 1, The group determination unit identifies the relationship between the distributed transactions by analyzing source code.

4. 2. The group generation device according to claim 1, the distributed transaction is managed by a distributed transaction management framework; The group determination unit identifies the relationship between the distributed transactions by utilizing an API of a distributed transaction management framework.

5. 2. The group generation device according to claim 1, The group generation device further comprises a copy control unit that presents the consistency groups set by the group determination unit and provides a user interface that receives a designation from a user as to whether replication is required.

6. 2. The group generation device according to claim 1, The group generation device further comprises a copy control unit that executes replication processing for the consistency group.

7. 1. A method for determining a consistency group for ensuring consistency in a replication process from a first site including a plurality of volumes to a second site including a plurality of volumes, comprising: forming one or more first groups, which are groups of volumes at the first site, based on the relationship of the distributed transaction at the first site; forming one or more second groups, which are groups of volumes at the second site, based on the relationship of the distributed transaction at the second site; Identifying a correspondence between the first group and the second group; and including the first group and the second group that correspond based on the identified correspondence relationship in the same consistency group.

Images