STORAGE SYSTEM AND DATA DURATION METHOD THEREFOR
The described storage system improves snapshot and I/O performance by using a multi-controller architecture with assigned meta-information areas and hierarchical data associations to optimize data access and load balancing.
Patent Information
- Application Number
- JP2024210102
- Authority / Receiving Office
- JP · JP
- Patent Type
- Patents
- Current Assignee / Owner
- Filing Date
- 2024-12-03
- Publication Date
- 2026-01-27
- Estimated Expiration
- 2040-07-31
AI Technical Summary
The Redirect on Write (RoW) method in storage systems results in poor read performance due to the need for searching meta-information trees, and uneven load distribution among controllers affects I/O performance as the tree hierarchy deepens.
A storage system with multiple controllers, each assigned logical volumes and meta-information areas, uses first and second-level meta-information to associate data locations, allowing efficient data access and load balancing.
This approach enhances both snapshot operation and I/O performance by optimizing data access and resource utilization across controllers.
Smart Images

Figure 0007807518000001 
Figure 0007807518000002 
Figure 0007807518000003
Abstract
Description
[Technical Field]
[0001] The present invention relates to a storage system and a data replication method in a storage system. [Background technology]
[0002] In recent years, the need for data utilization has increased, leading to more opportunities for data replication. Accordingly, snapshot functions have become increasingly important in storage systems. A typical method for implementing snapshots has traditionally been the Redirect on Write (RoW) method (see, for example, Patent Document 1). The RoW method has the advantage of having little impact on I / O performance when creating snapshots, since it does not involve copying data or meta-information. The RoW method is widely adopted in AFA (All Flash Array) devices.
[0003] The RoW method is a method of writing data after it has been written. After it has been written, when data is written to a storage system, the data stored before the write is not overwritten, but the write data is stored in a new area, and the meta-information is rewritten to reference the data stored in the new area. Meta-information is managed in a tree structure. When a snapshot of a source volume is taken, the root of the meta-information tree of the source volume at that time is referenced from the root of the meta-information tree of the snapshot. At this point, the root of the source volume is referenced by the snapshot, so it cannot be rewritten and only reads are permitted. Furthermore, when a write is made to the source volume, a new root is prepared in the source, and new meta-information that references the storage location of the updated data is created and connected under the new root. Furthermore, the old root is referenced from the new root so that the data storage location in the unwritten area can be identified. In other words, when a snapshot is taken, the meta-information cannot be directly rewritten, and the meta-information is also after it has been written. [Prior art documents] [Patent documents]
[0004] [Patent Document 1] U.S. Patent No. 9,646,039 Summary of the Invention [Problem to be solved by the invention]
[0005] However, the conventional RoW method requires searching for the desired data and meta-information from the meta-information tree when reading, which results in poor read performance (especially response).Furthermore, as the number of writes increases, the tree hierarchy becomes deeper, which requires asynchronous processing to reduce the number of tree levels, which affects I / O performance.
[0006] Furthermore, meta information other than the root of the tree is shared by multiple volumes and snapshots. However, the root meta information is information for each volume and snapshot. Therefore, if the load is unevenly distributed to a specific volume or snapshot, the load will be concentrated on a specific controller among the multiple controllers that control each volume and each snapshot, resulting in the problem of not being able to fully utilize the resources of the multi-controller.
[0007] The present invention has been made in view of the above-mentioned problems, and has as its object to achieve both snapshot operation performance and I / O performance in a storage system. [Means for solving the problem]
[0008] In order to achieve the above object, the present invention provides a storage system having a plurality of controllers and capable of replicating logical volumes, wherein the controllers are assigned the logical volumes they are responsible for, and are assigned an appending area for storing data of the logical volumes and a meta-information area for storing meta-information of data appended to the appending area, the storage system comprising: a data control unit that appends data of the logical volumes to the appending area; and a data management unit that stores meta-information of the data appended to the appending area by the data control unit in the meta-information area, wherein the meta-information comprises first-level meta-information and second-level meta-information that associate location information of data in the logical volumes with location information of the data in the appending area, and the first-level meta-information associates location information of data in the logical volumes with location information of the data in the appending area. The second hierarchical meta information is information that relates the storage locations of the two hierarchical meta information, and the second hierarchical meta information is information that manages the location information of the data in the appending area.When creating a second logical volume that is a copy of a first logical volume, the data management unit creates a copy of the first hierarchical meta information stored in multiple meta information areas assigned to multiple controllers in the same meta information area as the original, and the data control unit of the controller associated with the meta information area that created the copy of the first hierarchical meta information accesses the data in the appending area from the first logical volume based on the second hierarchical meta information referenced based on the first hierarchical meta information, and accesses the data in the appending area from the second logical volume based on the second hierarchical meta information referenced based on the copy of the first hierarchical meta information. [Effects of the Invention]
[0009] According to the present invention, it is possible to achieve both good snapshot operation performance and good I / O performance in a storage system. [Brief explanation of the drawings]
[0010] [Figure 1] FIG. 1 is an explanatory diagram illustrating an outline of the logical configuration of a storage system according to an embodiment. [Figure 2]FIG. 1 is an explanatory diagram of a hardware configuration of a computer system according to a first embodiment. [Figure 3] FIG. 2 is an explanatory diagram of programs and information used by the storage system. [Figure 4] FIG. 4 is an explanatory diagram of the configuration of a directory table. [Figure 5] FIG. 4 is an explanatory diagram of the configuration of a mapping table. [Figure 6] FIG. 4 is an explanatory diagram of the configuration of a volume management table. [Figure 7] FIG. 4 is an explanatory diagram of the configuration of a directory area management table. [Figure 8] FIG. 10 is an explanatory diagram of the configuration of a mapping area management table. [Figure 9] FIG. 4 is an explanatory diagram of the configuration of a directory area allocation table. [Figure 10] FIG. 4 is an explanatory diagram of the configuration of a mapping area allocation table. [Figure 11] FIG. 10 is an explanatory diagram of the configuration of a snapshot generation management table. [Figure 12] 10 is a flowchart showing the processing steps of a VOL creation process. [Figure 13] 10 is a flowchart showing the processing procedure of a snapshot creation process. [Figure 14] 10 is a flowchart showing the processing procedure of an additional writing process. [Figure 15] 10 is a flowchart showing the processing procedure of a read process. [Figure 16] 10 is a flowchart showing the processing procedure of front-end write processing (common to PVOL / Snapshot). [Figure 17] 10 is a flowchart showing the processing procedure of back-end write processing. [Figure 18] 10 is a flowchart showing the processing procedure of restore processing according to the first embodiment. [Figure 19] 10 is a flowchart showing the processing procedure of a resync process according to the first embodiment. [Figure 20] 10 is a flowchart showing the processing steps of a PVOL / Snapshot deletion process. [Figure 21] FIG. 1 is a diagram (part 1) for explaining the effect of the first embodiment. [Figure 22] FIG. 2 is a diagram (part 2) for explaining the effect of the first embodiment. [Figure 23] 10 is a flowchart showing the processing steps of a restore process according to the second embodiment. [Figure 24] 10 is a flowchart showing the processing procedure of a resync process according to the second embodiment. DETAILED DESCRIPTION OF THE INVENTION
[0011] Hereinafter, embodiments of the present invention will be described with reference to the drawings. Note that the embodiments described below do not limit the invention according to the claims, and not all of the elements and combinations thereof described in the embodiments are necessarily essential to the solution of the invention. Furthermore, illustrations and descriptions of elements that are essential to the configuration of the invention but are well known may be omitted.
[0012] In the following explanation, information that produces an output for an input may be described using expressions such as "xxx table," but this information may be data of any structure. Therefore, "xxx table" can also be called "xxx information."
[0013] Furthermore, in the following description, the configuration of each table is an example, and one table may be divided into two or more tables, or all or part of two or more tables may be one table.
[0014] In the following explanation, processing may be described using the "program" as the subject. The program is executed by the processor unit to perform a predetermined process using a storage unit and / or an interface unit as appropriate, so the subject of the process may be the processor unit (or a device such as a controller that has the processor unit).
[0015] The program may be installed in a device such as a computer, or may be stored in, for example, a program distribution server or a computer-readable (e.g., non-transitory) recording medium. Also, in the following description, two or more programs may be realized as one program, or one program may be realized as two or more programs.
[0016] Furthermore, a "processor unit" refers to one or more processors. The processor is typically a microprocessor such as a CPU (Central Processing Unit), but may also be other types of processors such as a GPU (Graphics Processing Unit). The processor may be single-core or multi-core. The processor may also be a processor in the broader sense, such as a hardware circuit that performs part or all of the processing (for example, an FPGA (Field-Programmable Gate Array) or an ASIC (Application Specific Integrated Circuit)).
[0017] In the following description, identification numbers are used as identification information for various objects, but other types of identification information (for example, identifiers including alphabetic characters or symbols) may also be used. In the following description, "#" represents a number, and for example, "xxx#" represents xxx identified by a number.
[0018] In the following description, when elements of the same type are described without distinction, reference signs (or common signs among reference signs) may be used, and when elements of the same type are described with distinction, identification numbers (or reference signs) of the elements may be used. Furthermore, the number of elements shown in each drawing is an example and is not limited to the number shown. [Example]
[0019] 1 is an explanatory diagram illustrating an outline of the logical configuration of a storage system 201 according to an embodiment. The storage system 201 is a storage system that uses a RoW (Redirect on Write) method when creating a snapshot. As shown in FIG. 1, the storage system 201 has, as its logical configuration, a PVOL (Primary Volume) 100, a Snapshot 101, a DSVOL (Data Store Volume) 102, and a Pool 107.
[0020] PVOL100 is a logical volume provided to the host device. Snapshot101 is a replica volume of PVOL100 created by the RoW method, and is provided to the host device.
[0021] Pool 107 is allocated a physical storage area from a physical drive (not shown). DSVOL 102 is a logical storage area extracted from Pool 107 and includes multiple DSVOLs 102-i (i = 0, 1, . . . , n-1 (n is the fixed number of DSVOLs for each Pool 107)). All DSVOLs 102-i have the same capacity.
[0022] In DSVOL102, directory tables 103 for PVOL that store management information (meta information) of PVOL100 are distributed and allocated to each DSVOL102-i as directory tables 103-i (i=0, 1, . . . , n-1). The management information of PVOL100 is mapping information in a two-level tree structure, and directory table 103 for PVOL corresponds to the mapping information of the first level.
[0023] The directory table 103 for PVOL is a group of directory tables 103-i (i=0, 1, . . . , n-1), and is provided for each PVOL 100. A directory # is assigned to each directory table 103. Depending on the capacity of the PVOL, multiple directory tables 103 may be assigned to one PVOL. In that case, multiple directory #s are also assigned.
[0024] The PVOL directory table 103 is a table that converts the address in the PVOL of the data 111-j (j=0, 1, 2) on the PVOL 100 into an address in the DSVOL 102 where the mapping table 105 is stored.
[0025] In addition, in the DSVOL 102, directory tables 104 for SS (SnapShot) that store management information (meta information) of Snapshot 101 are distributed and allocated as directory tables 104-i (i=0, 1, . . . , n-1) in each of the DSVOLs 102-i. Directory table 104-i of the directory tables 104 for SS is a copy of directory table 103-i of the directory table 103 for PVOL.
[0026] The directory table 104 for SS is a group of directory tables 104-i (i=0, 1, . . . , n-1), and is provided for each snapshot 101. A directory # is assigned to each directory table 104. Depending on the capacity of the snapshot, multiple directory tables 104 may be assigned to one snapshot. In that case, multiple directory #s are also assigned. The directory table 104 for SS has the same table configuration as the directory table 103 for PVOL.
[0027] The directory table 104 for SS is a table that converts an address in the snapshot of the data 111-j (j=1, 2, 3) on the snapshot 101 into an address in the DSVOL 102 where the mapping table 105 is stored.
[0028] Furthermore, in DSVOL102, mapping tables 105 that store management information (meta information) of PVOL100 and Snapshot101 are distributed and allocated as mapping tables 105-i (i=0, 1, . . . , n-1) in each DSVOL102-i. The mapping tables 105 correspond to the second layer of mapping information in the above-mentioned two-stage tree structure.
[0029] The mapping table 105 is a group of mapping tables 105-i (i=0, 1, . . . , n-1), and is provided for each PVOL 100. Multiple mapping tables 105 are distinguished by numbers such as mapping #. Mapping # is assigned to each snapshot tree (a group of snapshots with a certain PVOL as the root), and increases according to an increase in the data capacity due to writing to the PVOL or snapshot.
[0030] The mapping table 105 is a table that converts an address in the PVOL / Snapshot of the data 111-j (j=0, 1, 2, 3) into an address in the additional write area 106.
[0031] In addition, in the DSVOL 102, additional write areas 106 for storing data of the PVOL 100 and Snapshot 101 are distributed and allocated as additional write areas 106-i (i=0, 1, . . . , n-1) in each DSVOL 102-i.
[0032] As described above, each DSVOL 102-i is provided with one or more directory tables 103-i (for PVOL), one or more directory tables 104-i (for SS), one or more mapping tables 105-i, and an append area 106-i.
[0033] 2 is an explanatory diagram of the hardware configuration of a computer system 100 according to a first embodiment. The computer system 100 includes a storage system 201, a server system 202, and a management system 203. The storage system 201 and the server system 202 are connected via an FC (Fiber Channel) network 204. The storage system 201 and the management system 203 are connected via an IP (Internet Protocol) network 205. The FC network 204 and the IP network 205 may be the same communication network.
[0034] The storage system 201 comprises a plurality of storage controllers 210 and a plurality of PDEVs 220. The PDEVs 220, which are physical drives, are connected to the storage controllers 210. One or a plurality of DSVOLs 102-i (i=0, 1, . . . , n-1) are allocated to one storage controller 210.
[0035] The storage controller 210 comprises one or more processors 211 , one or more memories 212 , a PI / F 213 , an SI / F 214 , and an MI / F 215 .
[0036] The processor 211 is an example of a processor unit. The processor 211 may include a hardware circuit that performs compression and decompression. In this embodiment, the processor 211 performs control related to snapshot creation, restoration, resynchronization, compression, and decompression.
[0037] The memory 212 is an example of a storage unit. The memory 212 stores programs executed by the processor 211, data used by the processor 211, etc. The processor 211 executes the programs stored in the memory 212. In this embodiment, for example, the memory is duplicated by a set of the memory 212 and the processor 211.
[0038] The PI / F 213, the SI / F 214, and the MI / F 215 are examples of interface units.
[0039] The PI / F 213 is a communication interface device that mediates the exchange of data between the PDEV 220 and the storage controller 210. A plurality of PDEVs 220 are connected to the PI / F 213.
[0040] The SI / F 214 is a communication interface device that mediates the exchange of data between the server system 202 and the storage controller 210. The server system 202 is connected to the SI / F 214 via the FC network 204.
[0041] The MI / F 215 is a communication interface device that mediates the exchange of data between the management system 203 and the storage controller 210. The management system 203 is connected to the MI / F 215 via an IP network 205.
[0042] The server system 202 is configured to include one or more host devices. The server system 202 transmits an I / O request (write request or read request) specifying an I / O destination to the storage controller 210. The I / O destination is, for example, a logical volume number such as a LUN (Logical Unit Number), a logical address such as a LBA (Logical Block Address), or the like.
[0043] The management system 203 includes one or more management devices and manages the storage system 201.
[0044] 3 is an explanatory diagram of programs and information used by the storage system 201. The memory 212 includes memory areas such as a local memory 300, a cache memory 301, and a shared memory 302. At least one of these memory areas may be an independent memory. The local memory 300 is used by a processor 211 that belongs to the same group as the memory 212 that includes this local memory 300.
[0045] The local memory 300 stores a volume creation program 303, a snapshot creation program 304, a read program 305, a front-end write program 306, a back-end write program 307, a restore program 308, a resync program 309, and a PVOL / Snapshot deletion program 310. These programs are provided for each of the multiple storage controllers 210, and work together to perform the desired processing. These programs will be described later.
[0046] The cache memory 301 temporarily stores data sets that are written to or read from the PDEV 220 .
[0047] The shared memory 302 is used by both a processor 211 that belongs to the same set as the memory 212 that includes this shared memory 302, and a processor 211 that belongs to a different set. The shared memory 302 stores management information.
[0048] The management information includes a volume management table 311, a directory area management table 312, a mapping area management table 313, a directory area allocation table 314, a mapping area allocation table 315, and a snapshot generation management table 316. These tables will be described later with reference to the drawings.
[0049] FIG. 4 is an explanatory diagram of the configuration of directory tables 103-i and 104-i (i = 0, 1, . . . , n-1). The directory table 103-i for PVOL and the directory table 104-i for SS have the same configuration and the same data size, and are distributed across DSVOLs 102-i. One entry in each directory table 103-i and 104-i corresponds to data in units of the granularity of the logical data of PVOL 100 (for example, 256 KB). In other words, the directory tables 103 and 104 are distributed across multiple DSVOLs 102-i, with the granularity of the logical data of PVOL 100 as a unit. The directory table 104-i (i = 0, 1, . . . , n-1) is a table into which the directory table 103-i (i = 0, 1, . . . , n-1) is copied under the control of the storage controller 210 of DSVOL 102-i.
[0050] Directory tables 103-i and 104-i have an address in PVOL / Snapshot 400 and a referenced address (address in mapping area) 401. In the case of directory table 103-i, the address in PVOL / Snapshot 400 is the logical address at which the target data is stored in PVOL 100, and in the case of directory table 104-i, it is the logical address at which the target data is stored in Snapshot 101. The referenced address (address in mapping area) 401 is pointer information to mapping table 105-i. The address in PVOL / Snapshot 400 has an upper limit (1000000 in the example of FIG. 4), and if the upper limit is exceeded, a directory table for a new group (directory #) is created.
[0051] In addition, which directory table 103-i, 104-i of the relevant directory # is the table that stores the correspondence between the accessed address 400 in the PVOL / Snapshot and the reference address (address in the mapping area) 401 is determined by taking the remainder when the address 400 in the PVOL / Snapshot is divided by the number n of DSVOLs.
[0052] The reference address (address within mapping area) 401 corresponds to the address within mapping area 500 of the mapping table 105-i associated with the directory table 103-i or 104-i.
[0053] 5 is an explanatory diagram of the configuration of a mapping table 105-i (i=0, 1, . . . , n-1). The mapping table 105-i has an address in the mapping area 500, a reference address (address in the additional area) 501, and a capacity after compression 502.
[0054] The address in the mapping area 500 is the reference address (address in the mapping area) 401 of the directory tables 103-i, 104-i associated with the mapping table 105-i. The reference address (address in the appending area) 501 is an address in the appending area 106 where the target data is stored. The compressed capacity 502 is the amount of data after compression when the target data of the PVOL 100 or Snapshot 101 is stored in the appending area 106-i.
[0055] 6 is an explanatory diagram of the configuration of the volume management table 311. The volume management table 311 is a table for managing volumes such as PVOL100, Snapshot101, and DSVOL102. The volume management table 311 includes a VOL#600, an attribute 601, a directory#602, a mapping#603, a capacity 604, and a pool#605.
[0056] VOL#600 is a number that identifies the volume. Attribute 601 is the type of volume identified by VOL#600, such as PVOL, Snapshot, DSVOL, etc. Directory# is the number of a group in the directory table that is assigned to the volume identified by VOL#600.
[0057] As the directory #, multiple areas on DSVOL102 are allocated according to the capacity of the volume. For example, in Fig. 6, a group of directory tables for PVOLs with directory #s of 0, 10, and 200 is allocated to a PVOL with VOL# of 0. Also, a group of directory tables for snapshots with directory #s of 1, 5, and 20 is allocated to a snapshot with VOL# of 1. Directory #602 of DSVOL102 is NULL.
[0058] Mapping #603 is the number of the mapping table group assigned to the volume identified by VOL#600. The mapping # of Snapshot101, which is a copy of PVOL100, is the same as that of the source PVOL. For example, in Figure 6, volumes with VOL#0 and 1 are assigned mapping table groups with mapping#2, 5, and 10. Mapping #603 of DSVOL102 is NULL.
[0059] The capacity 604 is the capacity of the volume identified by VOL# 600. The pool# 605 is the number of the pool from which the volume identified by VOL# 600 is extracted.
[0060] 7 is an explanatory diagram of the configuration of the directory area management table 312. The directory area management table 312 is a table that manages the starting address of each directory # on DSVOL102. The directory area management table 312 has a directory # 700 and a directory area starting address 701. For example, for a directory with a directory # of 0, an area with address 50 on the same DSVOL102 as its starting address is secured.
[0061] The address of the target data in the PVOL / Snapshot is divided by the manageable capacity of one directory table to obtain the sequence number of the directory # in the VOL / Snapshot. Directory #700 can be obtained from the sequence number of the directory # by referencing directory #602 in Figure 6.
[0062] 8 is an explanatory diagram of the configuration of the mapping area management table 313. The mapping area management table 313 is a table that manages the start address of each mapping # on the DSVOL 102. The mapping area management table 313 has a mapping #800 and a mapping area start address 801.
[0063] 9 is an explanatory diagram of the configuration of the directory area allocation table 314. The directory area allocation table 314 is a table that manages each directory # assigned to a directory area start address 900 on the DSVOL102, and is a reverse lookup table of the directory area management table 312. The directory area allocation table 314 has a directory area start address 900 and an assigned directory #901.
[0064] 10 is an explanatory diagram of the configuration of the mapping area allocation table 315. The mapping area allocation table 315 is a table that manages each mapping # assigned to a mapping area start address 1000 on the DSVOL 102, and is a reverse lookup table of the mapping area management table 313. The mapping area allocation table 315 has a mapping area start address 1000 and an assigned mapping #1001.
[0065] 11 is an explanatory diagram of the configuration of the Snapshot generation management table 316. The Snapshot generation management table 316 manages the latest generation of a Snapshot for each PVOL# of PVOL100, which is the replication source. The Snapshot generation management table 316 has PVOL#1100, latest generation#1101, generation#1102, Snapshot creation time 1103, Snapshot#1104, and status 1105. The Snapshot generation management table 316 manages, for example, 1024 generations for each PVOL# (generation#=0 to 1023).
[0066] In the snapshot generation management table 316, the latest generation # is incremented each time a snapshot is created for each PVOL #, and the snapshot creation time 1103, snapshot # 1104, and status 1105 corresponding to the latest generation # 1101 are updated. The status 1105 includes PAIR, which synchronizes the data of the PVOL and snapshot while disabling I / O to the snapshot after a snapshot of the PVOL is created. The status 1105 also includes SUSPEND (split), which does not synchronize the data of the PVOL and snapshot.
[0067] 12 is a flowchart showing the procedure for the VOL creation process, which is executed by the volume creation program 303 in response to an instruction from the management system 203.
[0068] First, in S1200, the volume creation program 303 checks with all storage controllers 210 that control each DSVOL 102-i whether it is possible to secure a directory area and mapping area for a PVOL that satisfies the specified conditions (volume capacity, etc.) in each DSVOL 102-i. If it is determined in S1200 that the area can be secured (S1201 Yes), the volume creation program 303 proceeds to S1202, and if it is determined in S1200 that the area cannot be secured (S1201 No), it terminates the VOL creation process.
[0069] In S1202, the volume creation program 303 determines the start address and allocation directory # of the directory area to be allocated to the PVOL that was determined to be allocatable in S1201. The volume creation program 303 adds the start address and allocation directory # of the determined directory area to update the directory area allocation table 314.
[0070] Next, in S1203, the volume creation program 303 determines the start address and allocation mapping # of the mapping area to be allocated to the PVOL that was determined to be allocatable in S1201. The volume creation program 303 updates the mapping area allocation table 315 by adding the determined start address of the mapping area and the allocation mapping #.
[0071] Next, in S1204, the volume creation program 303 updates the directory area management table 312 by setting the value of the directory area start address 900 in the directory area allocation table 314 updated in S1202 to the value of the directory area start address 701, and setting the value of the allocated directory #901 to the value of the directory #700.
[0072] Next, in S1205, the volume creation program 303 updates the mapping area management table 313 by setting the value of mapping area start address 1000 in the mapping area allocation table 315 updated in S1203 as the value of mapping area start address 801, and the value of allocated mapping #1001 as the value of mapping #800.
[0073] Next, in S1205, the volume creation program 303 updates the volume management table 311 by adding volume information including the directory #, mapping #, capacity, and Pool # of the attribute=PVOL created in this VOL creation process.
[0074] 13 is a flowchart showing the processing steps of the snapshot creation process, which is executed by the snapshot creation program 304 in response to an instruction from the management system 203.
[0075] First, in S1300, the snapshot creation program 304 receives the VOL# of the source VOL, which is the PVOL for which the snapshot is to be created. Next, in S1301, the snapshot creation program 304 determines whether the dirty data received in S1300 that has not been destaged to the source VOL is in the cache memory 301. If there is dirty data that has not been destaged to the source VOL (S1301 Yes), the snapshot creation program 304 proceeds to S1302, and if there is no dirty data (S1301 No), the snapshot creation program 304 proceeds to S1303. In S1302, the snapshot creation program 304 performs an append process for the dirty data, the details of which will be described later with reference to FIG. 14.
[0076] In S1303, the snapshot creation program 304 obtains the capacity and directory # of the source VOL from the volume management table 311. Next, in S1304, the snapshot creation program 304 checks whether a directory area for the snapshot (copy destination), which is a copy of the source VOL, can be secured in DSVOL 102. If the directory area for the snapshot (copy destination) can be secured (S1305 Yes), the snapshot creation program 304 proceeds to S1306, and if it cannot be secured (S1305 No), it terminates this snapshot creation process.
[0077] In S1306, the snapshot creation program 304 adds and updates volume information including the directory #, mapping #, capacity, and Pool # of the attribute=Snapshot created in this snapshot creation process to the volume management table 311. The value of the mapping # 603 of the snapshot is a copy of the value of the mapping # of the replication source PVOL.
[0078] Next, in S1307, the snapshot creation program 304 increments the latest generation #1101 of the created snapshot by +1, sets the snapshot creation time 1103, snapshot #1104 (corresponding to VOL# in the volume management table 311), and status 1105=SUSPEND, and updates the snapshot generation management table 316.
[0079] Next, in S1308, the snapshot creation program 304 updates the directory area allocation table 314 by adding the start address and allocation directory # of the directory area to be allocated to the snapshot that was determined to be allocatable in S1305.
[0080] Next, in S1309, the snapshot creation program 304 updates the directory area management table 312 by setting the value of the directory area start address 900 in the directory area allocation table 314 updated in S1308 to the value of the directory area start address 701, and setting the value of the allocated directory #901 to the value of the directory #700.
[0081] Next, in S1310, the snapshot creation program 304 instructs each storage controller 210 of the multiple DSVOLs 102-i to perform a directory copy. Next, in 1311, the snapshot creation program 304 receives the directory copy instruction of S1310, controls each storage controller 210 of the multiple DSVOLs 102-i, and copies the directory table 103-i of the PVOL, which is the replication source VOL, to the directory area of each DSVOL 102-i secured in S1308 and S1309 in parallel processing. A new directory # is assigned to the directory table 104-i created by copying.
[0082] Fig. 14 is a flowchart showing the processing steps of the append process. Fig. 14 shows details of the append processes executed in S1302 of Fig. 13, S1604 of Fig. 16, S1701 of Fig. 17, S1802 of Fig. 18, S1902 of Fig. 19, S2102 of Fig. 23, and S2202 of Fig. 24. Below, the append process executed in S1302 of Fig. 13 will be explained with the Snapshot creation program 304 as the processing subject.
[0083] Note that the processing entity is the front-end write program 306 at S1604 in Figure 16, the back-end write program 307 at S1701 in Figure 17, the restore program 308 at S1802 in Figure 18, the resync program 309 at S1902 in Figure 19, the restore program 308 at S2102 in Figure 23, and the resync program 309 at S2202 in Figure 24.
[0084] First, in S1400, the Snapshot creation program 304 identifies dirty data. Next, in S1401, the Snapshot creation program 304 references the Snapshot generation management table 316 and determines whether the PVOL has a Snapshot in a SUSPEND state. If there are no Snapshots in a SUSPEND state (S1401 No), the Snapshot creation program 304 proceeds to S1404, and if there are Snapshots in a SUSPEND state (S1401 Yes), the Snapshot creation program 304 proceeds to S1402.
[0085] In S1402, the snapshot creation program 304 determines whether the directory copy corresponding to the logical address (LBA) of the dirty data to be appended has been completed. If the directory copy has been completed (S1402 Yes), the snapshot creation program 304 proceeds to S1404, and if the directory copy has not been completed (S1402 No), it performs a purge copy of the directory information of the area. Purge copy is a process of pinpointing and copying only the directory information of the area to be appended when appending an area that has not been copied in the copy process at S1311 in Figure 13.
[0086] Next, in S1404, the snapshot creation program 304 compresses the dirty data identified in S1400. Next, in S1405, the snapshot creation program 304 copies the compressed data set compressed in S1404 to the append area of the copy source VOL.
[0087] Next, in S1406, the snapshot creation program 304 stores the storage location in the append area of the data compressed in S1404 in an unused entry in which the reference address (address in the append area) 501 is not set among the entries of the mapping table 105. In other words, the copy destination address of the compressed data is set in the reference address (address in the append area) 501.
[0088] Next, in S1407, the snapshot creation program 304 sets the address 500 within the mapping area of the mapping information created in S1406 to the reference address (address within the mapping area) 401 of the entry in the directory table 103 that corresponds to the logical address (LBA accessible from the host) of the data.
[0089] Next, in S1408, the snapshot creation program 304 destages the dirty data that was copied to the additional write area in S1405.
[0090] 15 is a flowchart showing the processing steps of the read process. The read process is executed by the read program 305 in response to a read request from the host device.
[0091] First, in S1500, the read program 305 acquires the address within the PVOL or snapshot of the data targeted by the read request from the server system 202. Next, in S1501, the read program 305 determines whether the targeted data of the read request is a cache hit. If the targeted data of the read request is a cache hit (S1501 Yes), the read program 305 proceeds to S1505, and if it is not a cache hit (S1501 No), the read program 305 proceeds to S1502.
[0092] In S1502, the read program 305 references the directory tables 103, 104, and acquires the referenced address (address in the mapping area) 401 based on the address in the PVOL / Snapshot acquired in S1500. The read program 305 references the directory table 103 for PVOL if the target data of the read request is data in PVOL 100, and references the directory table 104 for Snapshot if the target data is data in Snapshot 101.
[0093] Next, in S1503, the read program 305 references the mapping table 105 and acquires the reference address (address in the append area) 501 based on the reference address (address in the mapping area) acquired in S1502. Next, in S1504, the read program 305 decompresses the data stored in the address in the append area identified in S1503 and stages it in the cache memory.
[0094] Next, in S1505, the read program 305 transfers the data that was a cache hit in S1501 or the data that was staged in S1504 to the host device.
[0095] 16 is a flowchart showing the processing steps for front-end write processing (common to PVOL / Snapshot). Front-end write processing is executed by the front-end write program 306 when a write request to PVOL 100 or Snapshot 101 is received from the host device.
[0096] First, in S1600, the front-end write program 306 determines whether the target data of the write request from the host device is a cache hit. If the target data of the write request is a cache hit (S1600 Yes), the front-end write program 306 proceeds to S1602, and if there is no cache hit (S1600 No), the front-end write program 306 proceeds to S1601. In S1601, the front-end write program 306 reserves a cache area in the cache memory 301.
[0097] In S1602, the front-end write program 306 determines whether the target data that was a cache hit in S1600 is dirty data. If the target data that was a cache hit in S1600 is dirty data (S1602 Yes), the front-end write program 306 proceeds to S1603, and if the data is not dirty data (S1602 No), the front-end write program 306 proceeds to S1605.
[0098] In S1603, the front-end write program 306 determines whether the WR (WRight) generation # of the dirty data determined in S1602 matches the generation # of the target data of the write request. The WR generation # is held in cache data management information (not shown). Furthermore, the generation # of the target data of the write request is acquired from the latest generation #1101 in FIG. 11. S1603 prevents the target data (dirty data) of the most recently acquired snapshot from being updated with the target data of the write request before the append process for that data has been completed, thereby overwriting the data in the snapshot. If the WR generation # and the latest generation # match (S1603 Yes), the front-end write program 306 proceeds to S1605, and if the WR generation # and the latest generation # do not match (S1603 No), the front-end write program 306 proceeds to S1604.
[0099] In S1604, the front-end write program 306 executes the append process described with reference to Fig. 14. In S1604, dirty data of the WR generation # that does not match the latest generation # is written to the append area and destaged from the cache memory 301.
[0100] In S1605, the front-end write program 306 writes the target data of the write request to the cache area secured in S1601, or to a cache area in which dirty data that requires additional writing has been added and dirty data can be generated again.
[0101] In S1606, the front-end write program 306 sets the WR generation # of the cache data written to the cache memory 301 in S1605 to the latest generation # compared in S1603. In S1607, the front-end write program 306 returns a normal response (Good response) to the host device.
[0102] 17 is a flowchart showing the processing steps of backend write processing. The backend write processing is a process in which, when data (dirty data) that has not been reflected in the additional write area 106 of the DSVOL 102 is present in the cache memory 301, the unreflected data is written to the additional write area 106. The backend write processing is performed synchronously or asynchronously with the frontend processing. The backend write processing is executed by the backend write program 307.
[0103] First, in S1700, the backend write program 307 determines whether there is dirty data in the cache memory 301. If there is dirty data in the cache memory 301 (S1700 Yes), the backend write program 307 proceeds to S1701, and if there is no dirty data (S1700 No), this backend write processing ends. In S1701, the backend write program 307 executes the append processing described in FIG. 14.
[0104] 18 is a flowchart showing the processing procedure of the restore processing of the embodiment 1. The restore processing is executed by the restore program 308 in response to a restore (data recovery) instruction from the management system 203.
[0105] First, in S1800, the restore program 308 receives the restore destination PVOL# and restore source Snapshot# from the management system 203. Next, in S1801, the restore program 308 determines whether there is dirty data in the restore source Snapshot for which the Snapshot# was received in S1800. If there is dirty data in the restore source Snapshot (S1801 Yes), the restore program 308 proceeds to S1802, and if there is no dirty data (S1801 No), the restore program 308 proceeds to S1803.
[0106] In S1802, the restore program 308 executes the append process described with reference to FIG.
[0107] In S1803, the restore program 308 obtains the directory # of the restore source snapshot and the directory # of the restore destination PVOL from the volume management table 311. Next, in S1804, the restore program 308 instructs each storage controller 210 of the multiple DSVOLs 102-i to copy the restore source / destination directories obtained in S1803.
[0108] Next, in S1805, the restore program 308 copies the directory table 104-i of the directory # of the snapshot of the restore source acquired in S1803 to the directory table 103-i of the directory # of the PVOL of the restore destination through parallel processing of each storage controller 210.
[0109] 19 is a flowchart showing the processing procedure of the resync process of Example 1. The resync process is executed by the resync program 309 in response to a resync (data resynchronization) instruction from the management system 203.
[0110] First, in S1900, the resync program 309 receives the resync destination Snapshot# and the resync source PVOL# from the management system 203. Next, in S1901, the resync program 309 determines whether there is dirty data in the resync source PVOL. If there is dirty data in the resync source PVOL (S1901 Yes), the resync program 309 proceeds to S1902, and if there is no dirty data (S1901 No), the resync program 309 proceeds to S1903.
[0111] In S1902, the resync program 309 executes the append process described with reference to FIG.
[0112] In S1903, the resync program 309 obtains the directory # of the resync source PVOL and the directory # of the resync destination Snapshot from the volume management table 311. Next, in S1904, the resync program 309 instructs each storage controller 210 of the multiple DSVOLs 102-i to copy the directory obtained in S1903.
[0113] Next, in S1905, the resync program 309 copies the directory table 103-i of the directory # of the PVOL of the resync source obtained in S1903 to the directory table 104-i of the directory # of the Snapshot of the resync destination through parallel processing of each storage controller 210.
[0114] 20 is a flowchart showing the processing steps of the PVOL / Snapshot deletion processing. The PVOL / Snapshot deletion processing is executed by the PVOL / Snapshot deletion program 310 in response to an instruction from the management system 203 to delete a volume or a snapshot.
[0115] First, in S2000, the PVOL / Snapshot deletion program 310 receives the PVOL# or Snapshot# to be deleted. Next, in S2001, the PVOL / Snapshot deletion program 310 obtains the directory# and mapping# of the PVOL or Snapshot to be deleted from the volume management table 311.
[0116] Next, in S2002, the PVOL / Snapshot deletion program 310 instructs each storage controller 210 that controls each DSVOL 102 in which each directory table is distributed to delete the directory table of the PVOL or Snapshot to be deleted.
[0117] Next, in S2003, the PVOL / Snapshot deletion program 310 deletes the record corresponding to the directory table deleted in S2002 from the directory area management table 312. Next, in S2004, the PVOL / Snapshot deletion program 310 deletes from the directory area allocation table 314 the record of the directory area start address 900 corresponding to the record deleted from the directory area management table 312 in S2003.
[0118] Next, in S2005, the PVOL / Snapshot deletion program 310 determines whether the mapping area can be deleted (that is, whether the deletion target is a PVOL with no snapshots, or a single PVOL with snapshots). If the mapping area can be deleted (S2005 Yes), the PVOL / Snapshot deletion program 310 proceeds to S2006, and if the mapping area cannot be deleted (S2005 No), it proceeds to S2009.
[0119] In S2006, the PVOL / Snapshot deletion program 310 instructs each storage controller 210 that controls each DSVOL 102 in which each mapping table is distributed to delete the mapping table of the PVOL to be deleted.
[0120] Next, in S2007, the PVOL / Snapshot deletion program 310 deletes the record corresponding to the deleted mapping table from the mapping area management table 313. Next, in S2008, the PVOL / Snapshot deletion program 310 deletes from the mapping area allocation table 315 the record with the mapping area start address 1000 that corresponds to the record deleted from the mapping area management table 313 in S2007.
[0121] Next, in S2009, the PVOL / Snapshot deletion program 310 deletes the record of the volume corresponding to the deleted PVOL or Snapshot from the volume management table 311.
[0122] Next, in S2010, the PVOL / Snapshot deletion program 310 determines whether the deleted volume is a Snapshot. If the deleted volume is a Snapshot (S2010 Yes), the PVOL / Snapshot deletion program 310 proceeds to S2011, and if the deleted volume is a PVOL (S2010 No), this PVOL / Snapshot deletion process ends.
[0123] In S2011, the PVOL / Snapshot deletion program 310 deletes the record of the deleted Snapshot from the Snapshot generation management table 316. At this time, if the deleted Snapshot is the latest generation in the Snapshot generation management table 316, the Snapshot of the next newest generation after the deleted Snapshot is made the latest generation.
[0124] Next, the effects of the first embodiment will be described with reference to FIGS.
[0125] In this embodiment, as shown in Fig. 21, the meta-information tree has a two-tier structure consisting of a directory table 103 for PVOL, which is meta-information in the first tier, and a mapping table 105 shared by PVOL and snapshots, which is meta-information in the second tier. The directory table 103 for PVOL is a table that manages pointers to meta-information that reference data.
[0126] When a snapshot is taken, only the directory table 103 for the PVOL in the first stage is copied to create a directory table 104 for the snapshot. When reading or writing from PVOL 100, data is accessed based on the directory table 103 and mapping table 105. When reading or writing from snapshot 101, data is accessed based on the directory table 104 and mapping table 105. This reduces the search overhead when accessing data.
[0127] In this embodiment, as shown in Fig. 22, the directory tables 103 for PVOLs are distributed at a fine granularity to the multiple DSVOLs 102 controlled by each storage controller 210. When a snapshot is taken, the multiple storage controllers 210 perform table copying in units of the directory tables 103 for PVOLs distributed within each DSVOL 102. This parallel processing of copying reduces the time required to create a snapshot. Furthermore, even if the I / O load is unevenly distributed to a specific PVOL / snapshot, the load is distributed across the multiple storage controllers 210, making it possible to effectively utilize the resources of the multiple storage controllers.
[0128] Therefore, according to this embodiment, it is possible to achieve both I / O performance and storage system operation performance without impairing the performance of the functions required of the storage system. Furthermore, even if the I / O load is uneven, the benefits of multi-controllers can be fully enjoyed without being limited by the performance of a single storage controller. Furthermore, volume copies can be created on demand without worrying about deterioration in storage system performance or capacity. [Example]
[0129] The restore process and resync process of the second embodiment are different from those of the first embodiment. In the restore process of the second embodiment, the directory table is not copied, the volume management table (FIG. 6) is updated so that the directory # of the restore destination is the same as the directory # of the restore source, and the same directory area is referenced at the restore source and destination.
[0130] In addition, in the resync process of Example 2, the directory table is not copied, and the volume management table (Figure 6) is updated so that the directory # of the resync destination is the same as the directory # of the resync source, and the same directory area is referenced at the restore source / destination.
[0131] Fig. 23 is a flowchart showing the processing steps of restore processing of Example 2. S2100, S2101, S2102, and S2103 in Fig. 23 are the same as S1800, S1801, S1802, and S1803 in Fig. 18, respectively.
[0132] In S2104 following S2103, the restore program 308 updates the directory # of the restore destination PVOL with the directory # of the restore source Snapshot in the volume management table 311. In the example of Figure 6, the directory # 602 of the restore destination VOL#=0 attribute=PVOL is updated with the directory # (1,5,20) of the restore source VOL#=1 attribute=Snapshot. Next, in S2105, the restore program 308 changes the status 1105 of the restore source Snapshot in the Snapshot generation management table 316 to PAIR.
[0133] Fig. 24 is a flowchart showing the processing procedure of the resync process of embodiment 2. S2200, S2201, S2202, and S2203 in Fig. 24 are the same as S1900, S1901, S1902, and S1903 in Fig. 19, respectively.
[0134] In S2204 following S2203, the resync program 309 updates the directory # of the resync destination snapshot with the directory # of the resync source PVOL in the volume management table 311. In the example of Figure 6, the directory # 602 of the resync destination VOL#=1 attribute=Snapshot is updated with the directory # (0, 10, 200) of the PVOL for the resync source VOL#=0. Next, in S2205, the resync program 309 changes the status 1105 of the resync destination snapshot in the Snapshot generation management table 316 to PAIR.
[0135] In this way, in the second embodiment, compared to the restore processing and resync processing of the first embodiment, the directory table is not copied and only the reference destination is changed, which has the advantage of reducing the amount of processing.
[0136] The present invention is not limited to the above-described embodiment, but includes various modifications. For example, the above-described embodiment has been described in detail to clearly explain the present invention, and the present invention is not necessarily limited to those including all of the described configurations. Furthermore, not only can the configurations be deleted, but also replacements and additions of configurations are possible.
[0137] Furthermore, the above-described configurations, functions, processing units, processing means, etc. may be partially or entirely implemented in hardware, for example, by designing them as integrated circuits. The present invention can also be realized by software program code that implements the functions of the embodiments. In this case, a recording medium on which the program code is recorded is provided to a computer, and a processor included in the computer reads the program code stored in the recording medium. In this case, the program code itself read from the recording medium implements the functions of the above-described embodiments, and the program code itself and the recording medium on which it is stored constitute the present invention. Examples of recording media for providing such program code include flexible disks, CD-ROMs, DVD-ROMs, hard disks, solid-state drives (SSDs), optical disks, magneto-optical disks, CD-Rs, magnetic tapes, non-volatile memory cards, and ROMs.
[0138] Furthermore, the program code that realizes the functions described in this embodiment can be implemented in a wide range of program or script languages, such as assembler, C / C++, perl, Shell, PHP, and Java (registered trademark).
[0139] In the above-described embodiment, the control lines and information lines are shown as those considered necessary for the explanation, and not all control lines and information lines are necessarily shown in the product. All components may be interconnected. [Explanation of symbols]
[0140] 100: Computer system, 103, 103-i, 104, 104-i: Directory tables, 105, 105-i: Mapping tables, 106, 106-i: Additional write areas, 201: Storage system, 202: Server system, 203: Management system, 210: Storage controller
Claims
1. A storage system having multiple controllers and capable of replicating logical volumes, The controller includes: The logical volume to be handled is assigned, an additional write area for storing data of the logical volume and a meta information area for storing meta information of the data added to the additional write area are allocated; a data control unit that writes data of the logical volume to an additional write area; a data management unit that stores meta information of the data additionally written to the additional writing area by the data control unit in a meta information area, The meta information is the data storage area includes first-layer meta information and second-layer meta information that associate data location information in the logical volume with data location information in the additional recording area, the first-layer meta information is information that associates data location information in the logical volume with a storage location of the second-layer meta information related to the data, and the second-layer meta information is information that manages data location information in the additional recording area; The data management unit When creating a second logical volume by duplicating the first logical volume, a copy of the meta information of the first hierarchy stored in a plurality of meta information areas allocated to a plurality of controllers is created in the same meta information area as the copy source; The data control unit of the controller related to the meta information area where the copy of the meta information of the first layer was created is accessing data in the additional write area from the first logical volume based on meta information of the second layer referenced based on meta information of the first layer; The data in the additional write area is accessed from the second logical volume based on the meta information of the second layer referenced based on the copy of the meta information of the first layer. A storage system comprising:
2. A storage system having multiple controllers and capable of replicating logical volumes, The controller includes: The logical volume to be handled is assigned, an additional write area for storing data of the logical volume and a meta information area for storing meta information of the data added to the additional write area are allocated; a data control unit that writes data of the logical volume to an additional write area; a data management unit that stores meta information of the data additionally written to the additional writing area by the data control unit in a meta information area, The meta information is the data storage area includes first-layer meta information and second-layer meta information that associate data location information in the logical volume with data location information in the additional recording area, the first-layer meta information is information that associates data location information in the logical volume with a storage location of the second-layer meta information related to the data, and the second-layer meta information is information that manages data location information in the additional recording area; the write area for storing the data of the logical volume and the meta-information area for storing the meta-information of the data of the logical volume are allocated to a plurality of data store volumes, The meta-information of the first layer and the meta-information of the second layer are distributed and allocated to each of the plurality of data store volumes. A storage system comprising:
3. A storage system including a controller that processes data to be stored in a storage device, a write-once area for storing data to be stored in the storage device; The controller provides a volume for a host to perform IO; meta information for referencing data in the additional write area from the volume; The controller When performing a write to update data in the volume, the data before the update is left in the append area, the updated data is stored in a new area, and the meta information is rewritten so as to refer to the updated data; When creating a second logical volume that is a copy of a first logical volume, the second logical volume is created by copying meta-information for the first logical volume; the first logical volume and the second logical volume refer to a mapping table, and the mapping table refers to the additional write area, thereby referring to data in the additional write area using the meta information; The meta-information includes first meta-information that is included in each of the first logical volume and the second logical volume and is used to refer to the mapping table, and second meta-information that is included in the mapping table and is used to refer to the additional write area. A storage system comprising:
4. A data replication method in a storage system having multiple controllers and capable of replicating logical volumes, comprising: The controller includes: The logical volume to be handled is assigned, an additional write area for storing data of the logical volume and a meta information area for storing meta information of the data added to the additional write area are allocated; a data control unit that writes data of the logical volume to an additional write area; a data management unit that stores meta information of the data additionally written to the additional writing area by the data control unit in a meta information area, The meta information is the data storage area includes first-layer meta information and second-layer meta information that associate data location information in the logical volume with data location information in the additional recording area, the first-layer meta information is information that associates data location information in the logical volume with a storage location of the second-layer meta information related to the data, and the second-layer meta information is information that manages data location information in the additional recording area; The data management unit When creating a second logical volume by duplicating the first logical volume, a copy of the meta information of the first hierarchy stored in a plurality of meta information areas allocated to a plurality of controllers is created in the same meta information area as the copy source; a data control unit of the controller for the meta information area where the copy of the meta information of the first layer has been created, accessing data in the additional write area from the first logical volume based on meta information of the second layer referenced based on meta information of the first layer; The data in the additional write area is accessed from the second logical volume based on the meta information of the second layer referenced based on the copy of the meta information of the first layer. A data replication method comprising:
5. A data replication method in a storage system having multiple controllers and capable of replicating logical volumes, comprising: The controller includes: The logical volume to be handled is assigned, an additional write area for storing data of the logical volume and a meta information area for storing meta information of the data added to the additional write area are allocated; a data control unit that writes data of the logical volume to an additional write area; a data management unit that stores meta information of the data additionally written to the additional writing area by the data control unit in a meta information area, The meta information is the data storage area includes first-layer meta information and second-layer meta information that associate data location information in the logical volume with data location information in the additional recording area, the first-layer meta information is information that associates data location information in the logical volume with a storage location of the second-layer meta information related to the data, and the second-layer meta information is information that manages data location information in the additional recording area; the write area for storing the data of the logical volume and the meta-information area for storing the meta-information of the data of the logical volume are allocated to a plurality of data store volumes, The meta-information of the first layer and the meta-information of the second layer are distributed and allocated to each of the plurality of data store volumes. A data replication method comprising:
6. A data replication method in a storage system having a controller that processes data to be stored in a storage device, comprising: the storage system has a write-once area for storing data to be stored in the storage device, The controller provides a volume for a host to perform IO; meta information for referencing data in the additional write area from the volume; The controller: When performing a write to update data in the volume, the data before the update is left in the append area, the updated data is stored in a new area, and the meta information is rewritten so as to refer to the updated data; When creating a second logical volume that is a copy of a first logical volume, the second logical volume is created by copying meta-information for the first logical volume; The first logical volume and the second logical volume refer to a mapping table, and the mapping table refers to the additional write area, thereby referencing the data in the additional write area using the meta information. Each process has The meta-information includes first meta-information that is included in each of the first logical volume and the second logical volume and is used to refer to the mapping table, and second meta-information that is included in the mapping table and is used to refer to the additional write area. A data replication method comprising:
Citation Information
Patent Citations
Method, device, and computer program for providing multiple contexts in redirect on-write file system
JP2012123793A
Storage device and control method therefor
JP2019128906A
Volume management device, volume management method, and volume management program
JP2020080130A
Snapshots in a storage system
US9646039B2