Storage system and storage control method

Abstract

To suppress the reduction in performance of a second volume when obtaining data in a first volume in a first node via the second volume in a second node without copying all data in the first volume to the second volume.SOLUTION: A method includes: creating, by a first node, a third virtual volume in the first node by (virtually) copying address mapping between a virtual volume and a pool, for a first virtual volume; performing mapping, by a second node, from a first pool volume in the second node to the third virtual volume in the first node; associating addresses in the first pool volume mapped to the third virtual volume with addresses in a second virtual volume in the second node, respectively; and writing data in the second virtual volume in a log-structured format to a second pool volume in the second node.SELECTED DRAWING: Figure 26

Description

[Technical Field]

[0001] The present invention relates generally to storage control. [Background technology]

[0002] For example, Patent Document 1 discloses a storage system capable of executing virtual copies using a RoW (Redirect on Write) method. The storage system in Patent Document 1 has a tree structure of first control information associated one-to-one with volumes and second control information for managing user data, and copies only the first control information to quickly create copies of volumes. [Prior art documents] [Patent documents]

[0003] [Patent Document 1] Japanese Patent Publication No. 2022-26812 Summary of the Invention [Problem to be solved by the invention]

[0004] In recent years, storage systems have been required to have a scale-out function that allows them to expand performance and capacity as needed, starting from a small-scale configuration. Specifically, storage systems are made up of multiple nodes (appliances), and it is possible to add or remove nodes.

[0005] Furthermore, in recent years, there has been an increasing need for data utilization, and examples of data utilization include using data stored in a first environment in a second environment. Specifically, examples of data utilization include using data stored in a production environment for work in a development environment or a test environment, and using data stored in a core business environment in a secondary use environment such as for analysis.

[0006] When this type of data utilization is applied to multiple nodes in a scale-out storage system, it is possible to use data stored in a first volume provided by a first node through a second volume provided by a second node.

[0007] One method would be to copy all data stored in the first volume from the first node to the second node, but this method requires a large amount of data to be transferred between nodes, consuming a large amount of storage capacity on the second node.

[0008] Alternatively, when data is needed through the second volume, the second node can retrieve the needed data from the first node, but this method requires data to be transferred between nodes each time the data is needed, which reduces the performance of the second volume. [Means for solving the problem]

[0009] A storage system has a plurality of nodes including a first and a second node. Each node has a virtual volume, a pool configured with one or more pool volumes and in which data to be addressed in the virtual volume is logically stored at an address mapped to the address, one or more physical drives in which the entities of the data logically stored in the pool are stored, a memory for storing management information related to the data, which is information including mapping between the virtual volume addresses and the pool addresses, and a processor connected to the memory. The processor of the first node creates a third virtual volume in the first node by performing a virtual copy of the first virtual volume in the first node, which is a copy of the mapping between the virtual volume addresses and the pool addresses. A processor of the second node maps the first pool volume in the second node to a third virtual volume created on the first node, associates the address of the first pool volume mapped to the third virtual volume with the address of the second virtual volume in a one-to-one relationship, and, if the address of data to be written is an address in the second virtual volume, writes the data to the second pool volume in the second node using a log structure method. The log structure method write includes storing the updated data in the pool while leaving the pre-update data in the pool, and changing the mapping address of the address in the virtual volume from the address of the pre-update data to the address of the updated data. [Effects of the Invention]

[0010] According to the present invention, data from a first volume on a first node can be obtained through a second volume without copying all of the data from the first volume to a second volume on a second node, thereby suppressing performance degradation of the second volume. [Brief explanation of the drawings]

[0011] [Figure 1]1 is a block diagram showing an example of a logical configuration of a storage system 10 according to a first embodiment of the present invention. [Figure 2] 1 is a block diagram showing an example of the hardware configuration of a storage system 10. FIG. [Figure 3] 2 is a diagram illustrating an example of the configuration of a memory 14 of the storage system 10. FIG. [Figure 4] FIG. 10 is a diagram showing an example of a volume management table 141. [Figure 5] FIG. 10 is a diagram showing an example of a logical-physical conversion table 142. [Figure 6] FIG. 10 is a diagram illustrating an example of a page management table 143. [Figure 7] 10 is a diagram showing an example of a pool management table 144. FIG. [Figure 8] FIG. 10 is a diagram showing an example of an external volume management table 145. [Figure 9] FIG. 10 is a diagram illustrating a process image of a clone creation process. [Figure 10] 10 is a flowchart illustrating an example of a processing procedure for clone creation processing. [Figure 11] 10 is a flowchart illustrating an example of a processing procedure for intra-node virtual copy creation processing. [Figure 12] 10 is a flowchart illustrating an example of a processing procedure for volume external connection processing. [Figure 13] FIG. 10 is a diagram illustrating a processing image of a write process. [Figure 14] 10 is a flowchart illustrating an example of a processing procedure for write processing on the front end side. [Figure 15] 10 is a flowchart illustrating an example of a processing procedure for write processing on the backend side. [Figure 16] FIG. 10 is a diagram illustrating a processing image of a read process. [Figure 17] 10 is a flowchart illustrating an example of a processing procedure for a read process. [Figure 18] FIG. 10 is a diagram illustrating a processing image of a clone deletion process. [Figure 19] 10 is a flowchart illustrating an example of a processing procedure for a clone deletion process. [Figure 20] 10 is a flowchart illustrating an example of a processing procedure for volume external connection release processing. [Figure 21] FIG. 10 is a diagram showing a processing image of performance rebalancing processing in a storage system 10A according to a second embodiment of the present invention. [Figure 22] FIG. 10 is a block diagram showing an example of the hardware configuration of an entire system including a storage system 10B according to a third embodiment of the present invention. [Figure 23] FIG. 10 is a diagram showing a processing image of a clone creation process from storage system 10B to SDS51. [Figure 24A] FIG. 10 is a diagram showing an example (comparison example) in which a core business and unstructured analysis / monthly batch processing are performed in a storage system 10B in an on-premise environment 40. [Figure 24B] This figure shows an example in which core business is performed in a storage system 10B in an on-premise environment 40, and unstructured analysis / monthly batch processing is performed in an SDS 51 in a public cloud environment 50. [Figure 25] 1 is a diagram illustrating an example of the configuration of a memory 14 of a storage system 10 and an SDS 51. FIG. [Figure 26] FIG. 10 is a diagram illustrating a process image of prefetching data from the SDS 51 in the public cloud environment 50 to the storage system 10B in the on-premise environment 40. [Figure 27] 10 is a flowchart illustrating an example of a processing procedure for prefetching data from the SDS 51 in the public cloud environment 50 to the storage system 10B in the on-premise environment 40. [Figure 28] FIG. 10 is a diagram illustrating a processing image of a write process in an SDS 51 in a public cloud environment 50. [Figure 29A] 10 is a flowchart showing an example of a processing procedure for write processing (front end) in the SDS 51 of the public cloud environment 50. [Figure 29B] 10 is a flowchart showing an example of a processing procedure for write processing (backend) in the SDS 51 of the public cloud environment 50. [Figure 30A] FIG. 10 is a diagram illustrating a processing image of a read process in an SDS 51 in a public cloud environment 50. [Figure 30B] FIG. 10 is a diagram illustrating a processing image of a read process in an SDS 51 in a public cloud environment 50. [Figure 31] 10 is a flowchart illustrating an example of a processing procedure for a read process in the SDS 51 of the public cloud environment 50. [Figure 32] 10 is a flowchart illustrating an example of a processing procedure of a snapshot scheduler process in the storage system 10B of the on-premise environment 40. [Figure 33] FIG. 10 is a diagram illustrating a process image of prefetching data from the SDS 51 in the public cloud environment 50 to the storage system 10B in the on-premise environment 40. [Figure 34] 10 is a diagram showing an example of a logical-to-physical conversion table 142 of the SDS 51. FIG. [Figure 35] 10 is a flowchart illustrating an example of a processing procedure for prefetching data from the SDS 51 in the public cloud environment 50 to the storage system 10B in the on-premise environment 40. DETAILED DESCRIPTION OF THE INVENTION

[0012] Hereinafter, embodiments of the present invention will be described in detail with reference to the drawings.

[0013] Note that the following description and drawings are examples for explaining the present invention, and have been omitted or simplified as appropriate for clarity of explanation. Furthermore, not all of the combinations of features described in the embodiments are necessarily essential to the solution of the invention. The present invention is not limited to the embodiments, and all application examples consistent with the concept of the present invention are included in the technical scope of the present invention. Those skilled in the art can make various additions and modifications to the present invention within the scope of the present invention. The present invention can also be implemented in various other forms. Unless otherwise specified, each component may be plural or singular.

[0014] In the following explanation, various types of information may be described using expressions such as "table," "list," "queue," etc., but the various types of information may also be expressed using data structures other than these. To indicate that it is not dependent on the data structure, "XX table," "XX list," etc. may be referred to as "XX information." When describing the content of each piece of information, expressions such as "identification information," "identifier," "name," "ID," "number," etc. are used, but these are interchangeable.

[0015] Furthermore, in the following description, when describing elements of the same type without distinguishing between them, reference signs or common numbers in the reference signs will be used, and when describing elements of the same type while distinguishing between them, the reference signs of those elements will be used, or an ID or identification number assigned to that element will be used instead of the reference sign. For example, when describing a "virtual volume" without any particular distinction, it will be written as "virtual volume 130," whereas when describing individual virtual volumes 130 while distinguishing between them, it will be written as "virtual volume #1," "virtual volume #2," etc.

[0016] Furthermore, although the following description may describe processing performed by executing a program, the program is executed by at least one processor (e.g., a CPU) to perform a predetermined process using storage resources (e.g., memory) and / or interface devices (e.g., communication ports) as appropriate, and therefore the processor may be the subject of the processing. Similarly, the subject of the processing performed by executing a program may be a controller, device, system, computer, node, storage system, storage device, server, management computer, client, or host having a processor. The subject of the processing performed by executing a program (e.g., a processor) may include a hardware circuit that performs part or all of the processing. For example, the subject of the processing performed by executing a program may include a hardware circuit that performs encryption and decryption or compression and decompression. The processor operates as a functional unit that realizes a predetermined function by operating in accordance with the program. Apparatuses and systems including a processor are apparatuses and systems that include these functional units.

[0017] A program may be installed on a device such as a computer from a program source. The program source may be, for example, a program distribution server or a non-transitory storage medium readable by a computer. When the program source is a program distribution server, the program distribution server includes a processor (e.g., a CPU) and a non-transitory storage resource, and the storage resource may further store a distribution program and a program to be distributed. Then, the processor of the program distribution server may execute the distribution program, thereby distributing the program to be distributed to other computers. Also, in the following description, two or more programs may be realized as one program, and one program may be realized as two or more programs. (1) First embodiment (1-1) System configuration

[0018] FIG. 1 is a block diagram showing an example of the logical configuration of a storage system 10 according to a first embodiment of the present invention.

[0019] The storage system 10 is a storage system that employs a loosely coupled scale-out architecture and includes multiple nodes 100 (e.g., Node #1, Node #2). As shown in FIG. 1, each node 100 has a pool 110, a pool volume 120, and a virtual volume 130 as its logical configuration. Storage that employs a loosely coupled scale-out architecture has a scale-out function that can expand performance or capacity as needed from a small-scale configuration. A loosely coupled scale-out method in which multiple appliances (nodes 100) are clustered is mainstream, and the storage system 10 shown in FIG. 1 also employs this scale-out method, but is not limited to this.

[0020] The pool volume 120 is a logical storage device (logical volume) managed by the storage system 10, and the pool 110 is created by integrating one or more pool volumes 120. The virtual volume 130 is a virtual volume created from the pool 110, and the data in the virtual volume 130 is managed in units of pages 131.

[0021] A virtual volume 130 is associated with its associated pool (creation source pool 110) by a volume management table 141, which will be described later. Also, the address of the allocation destination of a page 131 is managed by a page management table 143, which will be described later. For example, in the case of FIG. 1, virtual volume #1 is associated with pool #1 which includes pool volume #11, and page 131 of "A" of virtual volume #1 is allocated to page 121 of "A" of pool volume #11.

[0022] 2 is a block diagram showing an example of the hardware configuration of a storage system 10. As explained in FIG. 1, the storage system 10 includes a plurality of nodes 100. The storage system 10 is connected to a production server 21 and a development / test server 22 via a storage network 31, and is connected to a management server 23 via a management network 32.

[0023] The production server 21 is a server that operates in a production environment that handles business data. The development / test server 22 is a server that operates in a development environment or a test environment. As hosts, the production server 21 and the development / test server 22 send I / O requests (write requests or read requests) that specify an I / O destination to the controller 11 of the storage system 10.

[0024] The management server 23 is a server that manages the storage system 10. The management server 23 manages and controls the storage system 10 via a management network 32.

[0025] The storage network 31 is, for example, an FC (Fiber Channel) network, and the management network 32 is, for example, an IP (Internet Protocol) network. The storage network 31 and the management network 32 may be the same communication network.

[0026] The node 100 includes one or more controllers 11 and one or more physical drives 12 (SSD). A physical drive 12 is connected to each controller 11, and one or more physical drives 12 are assigned to each controller 11. Note that, although an SSD (Solid State Drive) is shown in FIG. 2 as an example of the physical drive 12, the physical drive is not limited to this and may be any device that physically stores data, such as an HDD (Hard Disk Drive).

[0027] The controller 11 includes one or more processors 13 , one or more memories 14 , a front-end IF 15 , a back-end IF 16 , and a management IF 17 .

[0028] The processor 13 is a processor that realizes various controls by executing programs read from the memory 14. In this embodiment, the processor 13 performs controls related to creating and deleting clones, writing and reading data, etc. The processor 13 is, for example, a CPU (Central Processing Unit), but is not limited to this.

[0029] The memory 14 is a storage unit that stores programs executed by the processor 13 and data used by the processor 13. In this embodiment, for example, as shown in FIG. 2, the memory 14 is duplicated by a pair of the processor 13 and the memory 14.

[0030] The front-end IF 15 is a communication interface device that mediates data exchange between the production server 21 or the development / test server 22 and the controller 11. The controller 11 is connected to the production server 21 and the development / test server 22 from the front-end IF 15 via a storage network 31.

[0031] The back-end IF 16 is a communication interface device that mediates data exchange between the physical drives 12 and the controller 11. A plurality of physical drives 12 are connected to the back-end IF 16.

[0032] The management IF 17 is a communication interface device that mediates data exchange between the management server 23 and the controller 11. The controller 11 is connected to the management server 23 from the management IF 17 via a management network 32. (1-2) Memory configuration

[0033] 3 is a diagram showing an example of the configuration of the memory 14 of the storage system 10, and is a diagram showing an example of programs and control data in the memory 14 used by the storage system 10. The programs and control data used by the storage system 10 (mainly the controller 11) are read into the memory 14 and executed or used by the processor 13.

[0034] 3, the memory 14 includes memory areas for a control information unit 140 that stores control data, a program unit 150 that stores programs executed by the processor 13, and a cache unit 160 that functions as a cache. The program unit 150 is a local memory used by the processor 13 (see FIG. 2) that belongs to the same group as the memory 14. On the other hand, the control information unit 140 may be a shared memory that can be used not only by the processor 13 that belongs to the same group as the memory 14, but also by processors 13 that belong to other groups. At least one of the above memory areas may be an independent memory.

[0035] The control information unit 140 stores a volume management table 141, a logical-physical conversion table 142, a page management table 143, a pool management table 144, and an external volume management table 145. Examples of the configuration of each table are shown in Figs. 4 to 8, which will be described later.

[0036] The program section 150 stores a clone creation program 151, a clone deletion program 152, a volume external connection program 153, a volume external connection disconnection program 154, an intra-node virtual copy creation program 155, a write program 156, and a read program 157. These programs are provided for each of the multiple controllers 11, and work together to perform the intended processing. The processing performed by each program will be described in detail below.

[0037] The cache unit 160 temporarily stores a data set to be written to or read from the physical drive 12 .

[0038] 4 is a diagram showing an example of the volume management table 141. The volume management table 141 is control data for managing volumes such as the pool volume 120 and virtual volume 130. The volume management table 141 has the following items: volume ID 1411, capacity 1412, usage amount 1413, volume type 1414, belonging pool 1415, direct map 1416, and corresponding pool volume ID 1417.

[0039] The volume ID 1411 indicates the identifier of the volume (volume ID). The capacity 1412 indicates the capacity allocated to the volume identified by the volume ID 1411 (hereinafter referred to as the volume), and the usage amount 1413 indicates the current usage amount of the volume.

[0040] The volume type 1414 indicates the type of the volume. If the volume is a clone created by virtually copying a certain volume, the type is displayed as "(Clone)", and if the volume is an externally connected (external) volume from a node different from the own node, the type is displayed as "(External VOL)".

[0041] In this description, "external connection (external connection)" refers to mapping from the virtual volume 130 of the own node to data of another node, and therefore also includes mapping between the pool volume 120 to which the virtual volume 130 of the own node is linked and the virtual volume 130 that holds the data of the other node. More specifically, when attempting to realize an external connection from the virtual volume #2 of node #2, which is the virtual clone destination node, to the data of node #1, which is the virtual clone source node (data of pool volume #11), mapping is performed between the pool volume #22 to which the virtual volume #2 is linked and the virtual volume that holds the data of pool volume #11 in node #1 (in this example, not the virtual copy source virtual volume #1, but virtual volume #3, which is the intra-node virtual copy of virtual volume #1). In this case, pool volume #22 serves as a relay for mapping between the virtual volume 130 of the own node (virtual volume #2) and the virtual volume 130 that holds the data of the other node (virtual volume #3), and this pool volume #22 is referred to as an external volume. The reason why pool volume #22 is externally connected to virtual volume #3 rather than virtual volume #1 is to prevent data changes in the clone source node (node ​​#1) after cloning from affecting virtual volume #2, which is the clone destination.

[0042] The belonging pool 1415 indicates the identifier (pool ID) of the pool 110 to which the volume belongs. If the volume is a virtual volume (Virtual VOL), the belonging pool 1415 indicates the pool ID of the pool 110 from which the volume was created.

[0043] Direct Map 1416 indicates whether the data of the volume is directly mapped. In the storage system 10, when the main body of the data of the virtual volume 130 is stored in a node 100 other than the local node (for example, in the case of an external connection, which will be described later), direct mapping is performed and Direct Map 1416 is set to "ON." Note that in the case of a virtual volume (virtual clone) generated by virtually copying the virtual volume 130 within the same node, direct mapping is not performed and Direct Map 1416 is set to "OFF."

[0044] The corresponding pool volume ID 1417 indicates the volume ID of the corresponding pool volume 120 when the direct mapping of the volume is "ON".

[0045] FIG. 5 is a diagram showing an example of the logical-physical conversion table 142. The logical-physical conversion table 142 is data that manages the correspondence between a logical address 1421 and a physical address 1422 at which data is stored. In this embodiment, data is processed in page units, so the physical address 1422 in FIG. 5 is indicated by a page number. Note that if the value of the physical address 1422 is a valid value such as "0" or "2," this means that the data is stored in the local node that holds this logical-physical conversion table 142. On the other hand, if the value of the physical address 1422 is an invalid value such as "FFFFFFFF," this means that the data is stored in the logical address 1421 of the straight-mapped pool volume 120 in the local node (the same address as the logical address 1421 of the accessed virtual volume). For example, if the accessed virtual volume is a clone, is straight-mapped to a pool volume, and the pool volume is externally connected to a virtual volume of a clone-source node, this means that the data entity is stored in the clone-source node.

[0046] 6 is a diagram showing an example of the page management table 143. The page management table 143 is control data for managing pages. The page management table 143 has the following items: page number 1431, pool volume ID 1432, start address 1433, status 1434, allocation destination volume ID 1435, and allocation destination logical address 1436.

[0047] The page number 1431 indicates an identifier (page number) assigned to each page. The pool volume ID 1432 indicates the volume ID of the pool volume 120 that stores the entity data of the page (hereinafter, the page) identified by the page number 1431. The start address 1433 indicates the start address of the entity data of the page stored in the pool volume ID 1432.

[0048] The status 1434 indicates whether or not the page is allocated to page 131 of the virtual volume 130. The allocation destination volume ID 1435 indicates the volume ID of the virtual volume 130 to which the page is allocated, and the allocation destination logical address 1436 indicates the logical address (start address) of the page allocated to the virtual volume 130.

[0049] 7 is a diagram showing an example of the pool management table 144. The pool management table 144 is control data for managing the pool 110. The pool management table 144 has the following items: pool ID 1441, capacity 1442, usage amount 1443, volume ID 1444, attribute 1445, and external volume ID 1446.

[0050] The pool ID 1441 indicates the identifier of the pool (pool ID). The capacity 1442 indicates the capacity allocated to the pool identified by the pool ID 1441 (hereinafter referred to as the pool), and the usage amount 1443 indicates the current usage amount of the pool.

[0051] The volume ID 1444 indicates the volume ID of the pool volume 120 belonging to the pool. The attribute 1445 indicates, as an attribute of the volume identified by the volume ID 1444, whether the entity data of the volume exists in the pool (own node) (Internal) or whether the entity data of the volume exists in another pool (another node) (External). Specifically, if the volume is an "external volume (External VOL)" that externally connects a virtual volume 130 of another node, the attribute 1445 is "External". Then, the external volume ID 1446 indicates the identifier of the externally connected volume when the attribute 1445 is "External".

[0052] 8 is a diagram showing an example of the external connection volume management table 145. The external connection volume management table 145 is control data for managing volumes (external connection volumes) externally connected from another node. The external connection volume management table 145 has the following items: external connection volume ID 1451, connection node ID 1452, port ID 1453, and target device ID 1454.

[0053] The externally connected volume ID 1451 indicates an identifier assigned to an externally connected volume in the own node. The externally connected volume ID 1446 in the pool management table 144 shown in FIG.

[0054] The connection node ID 1452 indicates the node ID of the connection source node of the externally connected volume (hereinafter referred to as the externally connected volume) identified by the externally connected volume ID 1451. The node ID is an identifier that can uniquely identify each of the multiple nodes 100 that make up the storage system 10. The port ID 1453 indicates the identifier of the port of the node to which the externally connected volume is connected, and the target device ID 1454 indicates the identifier of the target device that holds the entity data of the externally connected volume in the connection source node. (1-3) Processing

[0055] Below, we will explain in detail the processes executed by the storage system 10 of this embodiment, namely, a "clone creation process" that creates a clone of a volume (virtual volume 130), a "write process" that is executed in response to a write request to the clone, a "read process" that is executed in response to a read request to the clone, and a "clone deletion process" that deletes the clone. (1-3-1) Clone creation process

[0056] Fig. 9 is a diagram showing a processing image of the clone creation process. The upper part of Fig. 9 shows a processing image when a host issues an instruction to create a clone of a volume with a different node as the creation destination, and the lower part of Fig. 9 shows a processing image during the subsequent clone creation process. Fig. 10 is a flowchart showing an example of the processing procedure of the clone creation process. Below, the processing procedure of the clone creation process will be explained according to the flowchart of Fig. 10, while appropriately indicating corresponding parts in Fig. 9.

[0057] The clone creation process begins when a "clone instruction" is sent from the host (for example, the production server 21, but it could also be the management server 23, etc.) to the storage system 10 to create a clone of a virtual volume 130 accessible from the host server on a specified node 100, and is received by the clone source node 100.

[0058] As described in the section on the problem to be solved by the invention, in conventional storage systems employing a loosely coupled scale-out architecture in which multiple nodes are clustered, the destination for creating a clone of a volume is limited to the same node as the volume itself. In contrast, the storage system 10 according to this embodiment can also specify a node other than the volume itself as the destination for creating a clone of a volume. As will be described in detail later, when a clone instruction is issued in the latter case, a virtual clone of the volume (virtual volume 130) is created across the nodes 100 by executing a clone creation process. A clone instruction can also be requested by the development / test server 22. However, the clone creation process in this case is similar to that when a clone instruction is requested by the production server 21, and therefore will not be described here.

[0059] In FIG. 9, in "(1) Clone instruction", production server 21 requests node #1 to create a clone of virtual volume #1 of node #1 in virtual volume #2 of another node, node #2.

[0060] At this time, in the controller 11 of the clone source node #1 that received the clone instruction, the processor 13 starts the clone creation program 151 and executes the clone creation process. In the following, the started program will be described as the processing subject. This also applies to other processes described later.

[0061] According to Figure 10, first, the clone creation program 151 receives, as information included in the clone instruction, the identifier of the clone source volume (in the case of Figure 9, the volume ID of virtual volume #1), the identifier of the node 100 where the clone source volume exists (in the same case, the node ID of node #1), the identifier of the clone destination volume (in the same case, the volume ID of virtual volume #2), and the identifier of the node 100 where the clone destination volume exists (in the same case, the node ID of node #2) (step S101).

[0062] Next, the clone creation program 151 calls the intra-node virtual copy creation program 155 to execute intra-node virtual copy creation processing, thereby creating a virtual copy of the clone-source volume in the same node as the clone source (step S102). This processing corresponds to "(2) Intra-node virtual copy creation" shown in Fig. 9, and creates virtual volume #3, which is a clone of virtual volume #1, inside node #1.

[0063] Fig. 11 is a flowchart showing an example of the processing procedure for intra-node virtual copy creation processing. The intra-node virtual copy creation processing shown in Fig. 11 corresponds to the processing of step S102 in Fig. 10, and is executed by the intra-node virtual copy creation program 155 of the clone source node (e.g., node #1). In this explanation, creation of a virtual copy within the same node is called "copy."

[0064] 11, first, the intra-node virtual copy creation program 155 checks whether dirty data exists in the copy source volume (virtual volume #1) (step S201). Dirty data is a well-known flag for managing the consistency of data held in the memory (control information unit 140) and the cache (cache unit 160), and a detailed description thereof will be omitted. If dirty data exists (YES in step S201), the process proceeds to step S202, and if dirty data does not exist (NO in step S201), the process proceeds to step S205.

[0065] In step S202, the intra-node virtual copy creation program 155 ensures data consistency between the control information unit 140 and the cache unit 160 based on the dirty data, allocates pages to store the dirty data in the source virtual volume, and updates the page management table 143.

[0066] Next, the intra-node virtual copy creation program 155 destages the dirty data (writes the data in the cache unit 160 to the physical drive 12) (step S203), and updates the logical-physical conversion table 142 regarding the destage (step S204).

[0067] Then, after processing step S204, or if the result is NO in step S201, the intra-node virtual copy creation program 155 copies the logical-physical conversion table 142 of the source volume (virtual volume #1) to the logical-physical conversion table 142 of the destination volume (virtual volume #3) (step S205), and terminates the intra-node virtual copy creation process.

[0068] By executing the intra-node virtual copy creation process as described above, virtual volume #3, which is a virtual copy of virtual volume #1, is created, as shown in (2) of Figure 9, and page 121 of pool volume #11, which was assigned to page 131 of virtual volume #1, is also assigned to page 131 of virtual volume #3.

[0069] Returning to the explanation of Fig. 10, after the intra-node virtual copy creation process is completed, the clone creation program 151 checks whether the clone source node 100 and the clone destination node 100 match based on the node ID received in step S101 (step S103).

[0070] If the clone source and clone destination nodes match in step S103 (YES in step S103), this means that the clone destination specified in the clone instruction is within the same node. In this case, since a clone has already been created within the same node in step S102, the clone creation program 151 proceeds to step S109, updates the attribute of the intra-node virtual copy in the volume management table 141, and terminates the clone creation process.

[0071] On the other hand, if the clone source and clone destination nodes do not match in step S103 (NO in step S103), this means that the clone destination specified in the clone instruction is a different node, and in this case the process proceeds to step S104.

[0072] In step S104, the clone creation program 151 of the clone source node transmits a volume external connection request to the controller 11 of the clone destination node, and in the clone destination node, the controller 11 that receives the request starts the volume external connection program 153 from its own memory 14 to execute volume external connection processing, thereby externally connecting the intra-node virtual copy created in the intra-node virtual copy creation processing of step S102 to the pool volume 120 of the clone destination node. This processing corresponds to "(3) External VOL connection (import to Pool VOL)" shown in Fig. 9, and virtual volume #3 created in node #1 is externally connected to pool volume #22 of node #2, which is the clone destination node.

[0073] Fig. 12 is a flowchart showing an example of the processing procedure for volume external connection processing. The volume external connection processing shown in Fig. 12 corresponds to the processing of step S104 in Fig. 10, and is executed by the volume external connection program 153 of the clone destination node (for example, node #2).

[0074] According to FIG. 12, first, the volume external connection program 153 receives information regarding the intra-node virtual copy (virtual volume #3) of the clone source volume (e.g., virtual volume #1) and information regarding the clone destination volume (virtual volume #2) included in the volume external connection request (step S301).

[0075] Next, the volume external connection program 153 refers to the volume management table 141 of its own node (node ​​#2) to identify the pool (for example, pool #2) to which the clone destination volume (virtual volume #2) belongs (step S302).

[0076] Next, the volume external connection program 153 adds the externally connected volume (pool volume #22) that is externally connected from the clone source node to its own node by creating and updating a record in the external volume management table 145 for any pool volume (e.g., pool volume #22) created in pool #2 identified in step S302 (step S303).

[0077] Next, the volume external connection program 153 updates the pool management table 144 and adds the externally connected volume added to its own node in step S303 to the pool identified in step S302 (step S304).

[0078] Finally, the volume external connection program 153 updates the volume management table 141 for the intra-node virtual copy (virtual volume #3) and the externally connected volume (pool volume #22) according to the processing results of steps S303 to S304 (step S305), and terminates the volume external connection processing.

[0079] By executing the volume external connection process as described above, the virtual volume #3 created on the clone source node, node #1, is externally connected to the external volume (pool volume #22) on the clone destination node, node #2, as shown in (3) of Figure 9.

[0080] Returning to the explanation of Figure 10, after the volume external connection processing is completed, the clone creation program 151 of the clone destination node (node ​​#2) updates the volume management table 141 according to the processing result of the volume external connection processing in its own node (step S105). Specifically, the clone creation program 151 sets the value of the direct map 1416 of the clone destination volume (virtual volume #2) to "ON" in the volume management table 141, and adds the volume ID of the externally connected volume to the corresponding pool volume ID 1417 of the same record.

[0081] Next, the clone creation program 151 sets the assigned logical address 1436 of the page in the page management table 143 corresponding to the data held in the externally connected intra-node virtual copy (virtual volume #3) to "unassigned" "-" (step S106). Note that the data held in the externally connected intra-node virtual copy (virtual volume #3) is the same as the data held in the clone source volume (virtual volume #1), and will hereinafter also be referred to as "old data." On the other hand, data newly written by a write process in a clone destination volume created across nodes will be referred to as "new data."

[0082] The processing of steps S105 to S106 above corresponds to "(4) Linking Virtual VOL and Pool VOL" shown in Figure 9, and in the clone destination node (node ​​#2), a page in the clone destination volume (virtual volume #2) mapped to the data of the intra-node virtual copy (virtual volume #3) is linked one-to-one with a page in the external volume (pool volume #22) to which the intra-node virtual copy (virtual volume #3) is externally connected.

[0083] Next, the clone creation program 151 initializes the logical-physical conversion table 142 of the clone destination volume (virtual volume #2) (step S107), and purges the cache area of ​​the volume (step S108). In the initialization of the logical-physical conversion table 142, the value of the physical address 1422 corresponding to the relevant logical address 1421 is set to an invalid value (Invalid).

[0084] Finally, the clone creating program 151 updates the attributes in the volume management table 141 (step S109), and ends the clone creating process.

[0085] By performing the clone creation process as described above, the storage system 10 of this embodiment can create virtual clones of volumes across nodes (between different nodes 100) even under the constraints of the loosely coupled scale-out architecture, which requires that the destination and source of a virtual copy must be the same node. (1-3-2) Write processing

[0086] FIG. 13 is a diagram showing a processing image of write processing. The upper part of FIG. 13 shows a processing image when write data is transferred in response to a write request from the host to the virtual clone (the clone-destination virtual volume 130), and the lower part of FIG. 9 shows a processing image during the subsequent write processing. Furthermore, FIG. 14 is a flowchart showing an example of the processing procedure for write processing on the front-end side, and FIG. 15 is a flowchart showing an example of the processing procedure for write processing on the back-end side. In the controller 11 of the node 100 that has received the write request, the write program 156 executes the write processing shown in FIG. 14 and the write processing shown in FIG. 15 in parallel. Below, the processing procedure for write processing will be explained according to the flowcharts of FIGS. 14 and 15, while appropriately indicating corresponding parts in FIG. 13.

[0087] When a write request is made from a host (production server 21, development / test server 22, or management server 23) to write data to a volume in the storage system 10, the processor 13 in the controller 11 of the node 100 having the write-destination volume starts up the write program 156 and executes the write process. The write request includes the data to be written (write data) and the write-destination address in the target virtual volume 130.

[0088] 13, in "(1) Write Data Transfer", a write request to virtual volume #2 is made from development / test server 22, and write data 132 called "C" is transferred. Here, virtual volume #2 is a virtual clone created in node #2, which is different from the clone-source node, by the clone creation process described above with reference to FIGS. 9 to 12.

[0089] 14, at the front end, upon receiving a write request, the write program 156 first checks whether a cache area for the write destination address has been secured in the cache unit 160, in other words, whether the data at the write destination address is stored in the cache unit 160 (whether there is a cache hit) (step S401). If there is no cache hit (NO in step S401), the write program 156 secures a cache area for the write data (step S402) and transfers the write data to that cache area (step S403). On the other hand, if there is a cache hit (YES in step S401), the write program 156 skips step S402 and transfers the write data to the corresponding cache area (step S403).

[0090] The write program 156 then returns a normal response (Good response) to the write request to the host (step S404), and ends the write processing at the front end.

[0091] When a write request is received, in the backend, as shown in Fig. 15, the write program 156 first checks whether dirty data exists in the write destination volume (virtual volume #2) (step S501). If dirty data exists (YES in step S501), the process proceeds to step S502, and if dirty data does not exist (NO in step S501), the process ends.

[0092] In step S502, the write program 156 ensures data consistency between the control information unit 140 and the cache unit 160 based on the dirty data, then allocates pages of the write data in the destination volume (virtual volume #2) and updates the page management table 143.

[0093] Here, one of the features of the storage system 10 is that, in response to a write request for at least a virtual volume 130 created as a virtual clone (for example, virtual volume #2 in FIG. 13), the write program 156 of the node (node ​​#2) writes write data (so-called "append") using the log structure method within the node itself. Note that, in response to a write request for a virtual volume 130 other than a virtual clone, the write program 156 may also perform an append in the same manner.

[0094] In writing (appending) using the log structure method, the pool 110 (pool volume 120) holds historical data (pre-update data) updated by the write data 132. More specifically, when a write request is made to existing data in the virtual volume 130, the write program 156 holds the existing data (pre-update data) in the pool volume 120 and writes separate write data (post-update data) to a pool volume 120 that is not an externally bounded volume, and then changes the mapping from the virtual volume 130 to the pool volume 120 from the pre-update data to the post-update data. As a result, data is updated in the virtual volume 130, and historical pre-update data is held in the pool 110 (pool volume 120). Furthermore, when a write request for new data is made to the virtual volume 130, since pre-update data does not exist in the pool volume 120 linked to the virtual volume 130, the write program 156 writes the write data to a pool volume 120 that is not an externally bounded volume, and maps the write data from the virtual volume 130 to the pool volume 120.

[0095] Figure 13 shows an example of writing using the log structure method, illustrating a processing image when a write request is made to write data 132 (page "C") to virtual volume #2, which is a virtual clone. Specifically, the write program 156 of node #2 writes write data (page "C") to pool volume #21, which is not an external volume, without performing any processing such as deletion or movement on existing data in pool #2 (page "A" of pool volume #22 or page "B" of pool volume #21), and maps this page "C" from virtual volume #2 to pool volume #21.

[0096] Such an append is shown as "(2) Log Structured Write" in Fig. 13, and it can be seen that pool volume #21 is set as the storage destination of the above-mentioned write data (page "C"), and page "C" of pool volume #21 is allocated to page "C" of virtual volume #2. If the write request for write data 132 is to update page "A" of virtual volume #2, then, as shown in the lower part of Fig. 13, the mapping destination of the old page (page "A") in virtual volume #2 is set to page "C" of newly written pool volume #21, and page "A" of virtual volume #2 is updated to page "C".

[0097] Thereafter, the write program 156 destages the dirty data (step S503), updates the logical-physical conversion table 142 regarding the destage (step S504), and ends the processing.

[0098] By executing the write process as described above, in the storage system 10, when data is written to a clone destination volume (virtual volume #2) across nodes 100, the write data is appended within the clone destination node (node ​​#2). As a result, a write operation to the virtual clone can be performed without imposing a load or affecting the clone source node (node ​​#1). (1-3-3) Lead processing

[0099] FIG. 16 is a diagram showing a processing image of read processing. The upper part of FIG. 16 shows a processing image of read processing when a read request is made from the host to the virtual clone (clone-destination virtual volume 130) for data stored in the clone-destination node (i.e., when the destination volume of the read request and the storage destination of the actual read data are the same node). The lower part of FIG. 16 shows a processing image of read processing when a read request is made from the host to the virtual clone (clone-destination virtual volume 130) for data stored in the clone-source node (i.e., when the destination volume of the read request and the storage destination of the actual read data are different nodes). Also, FIG. 17 is a flowchart showing an example of the processing procedure of read processing. Below, the processing procedure of read processing will be explained according to the flowchart of FIG. 17, while appropriately indicating corresponding parts in FIG. 16.

[0100] When a read request is made from a host (production server 21, development / test server 22, or management server 23) to read data from a volume of storage system 10, in controller 11 of node 100 that received the read request, processor 13 starts read program 157 and executes read processing. The read request includes the storage range of the read data in the target volume (read target area).

[0101] According to Fig. 17, first, the read program 157 receives a read request (step S601). In the upper part of Fig. 16, in "(1) Read request", a read request for page "C" is made to virtual volume #2, which is the virtual clone of the clone destination. In the lower part of Fig. 16, in "(1) Read request", a read request for page "A" is made to virtual volume #2, which is the virtual clone of the clone destination.

[0102] Next, the read program 157 performs a cache hit / miss determination to determine whether the read data is stored in the cache unit 160 (step S602). If the read data is a cache hit (Hit in step S602), the cache hit data is transferred to the host (step S608), and the read process ends. On the other hand, if the read data is a cache miss (Miss in step S602), the process proceeds to step S603.

[0103] In step S603, the read program 157 refers to the read target area in the logical-physical conversion table 142. Then, the read program 157 checks whether or not the value of the physical address 1422 of the read target area referred to in step S603 is an invalid value (step S604). If the value of the physical address 1422 of the read target area is an invalid value in step S604 (YES in step S604), the process proceeds to step S605, and if the value of the physical address 1422 of the read target area is not an invalid value (NO in step S604), the process proceeds to step S607.

[0104] 5, in the logical-physical conversion table 142, when data is not stored in the own node (specifically, for example, when data is stored in another clone-source node), the value of the physical address 1422 is set to an invalid value such as "FFFFFFFF". In the specific example of FIG. 16, when the read data is page "C" (the case in the upper part of FIG. 16), page "C" is stored in node #2, which is the own node, so the physical address of the storage destination is indicated in the physical address 1422. On the other hand, when the read data is page "A" (the case in the lower part of FIG. 16), page "A" is stored in node #1, which is the clone-source node, so the physical address 1422 indicates an invalid value.

[0105] In other words, if the entity of the read data is stored in the own node (as in the upper part of Figure 16), proceed from step S604 to step S607, and if the entity of the read data is not stored in the own node (as in the lower part of Figure 16), proceed from step S604 to step S605.

[0106] First, when proceeding from step S604 to step S605, the read program 157 refers to the volume management table 141 and identifies the pool volume 120 (pool volume #22) to which the data of the target volume (virtual volume #2) of the read request is directly mapped from the corresponding pool volume ID 1417 (step S605).

[0107] Next, the read program 157 stages the data at the same address as the read target area from the pool volume 120 identified in step S605 (step S606). This process corresponds to the process indicated as "(2) Transfer from another node" at the bottom of Fig. 16. Specifically, as indicated by the thick arrow at the bottom of Fig. 16, a read request is made to read page "A" in pool volume #11 of node #1, the clone source node, as the data at the same address via the clone virtual volume #3 externally connected to the pool volume #22 identified in step S605, and the entity data of page "A" is read from the physical drive 12 storing the entity data of this page "A" and transferred to the cache unit 160 of node #2.

[0108] After the processing of step S606, the read program 157 transfers the data on the cache transferred in step S606 to the host (step S608), and ends the read processing.

[0109] On the other hand, if the process proceeds from step S604 to step S607, the read program 157 refers to the logical-physical conversion table 142, and stages data from the page indicated by the physical address 1422 corresponding to the logical address of the read target area (step S607). This process corresponds to the process indicated as "(2) Transfer from own node" in the upper part of Fig. 16. Specifically, as indicated by the thick arrow in the upper part of Fig. 16, the page indicated by the logical address of the read target area is page "C" of pool volume #21, and the entity data of page "C" is read from the physical drive 12 that stores the entity data of this page "C" and transferred to the cache unit 160.

[0110] After the processing of step S607, the read program 157 transfers the data on the cache transferred in step S607 to the host (step S608), and ends the read processing.

[0111] By executing the read process as described above, if a valid value is set in the mapping information (logical-physical conversion table 142), the storage system 10 reads the read data from its own node and responds, whereas if an invalid value is set in the mapping information (logical-physical conversion table 142), it determines that the read data is located in another node (clone-source node) and responds by reading the data from the clone-source node via the external volume. (1-3-4) Clone deletion process

[0112] Fig. 18 is a diagram showing a processing image of clone deletion processing. The upper part of Fig. 18 shows a processing image when a clone deletion command is issued from the host to the virtual clone (clone destination virtual volume 130), and the lower part of Fig. 18 shows a processing image during the subsequent clone deletion processing. Fig. 19 is a flowchart showing an example of the processing procedure for clone deletion processing. Below, the processing procedure for clone deletion processing will be explained according to the flowchart of Fig. 19, while appropriately indicating corresponding parts in Fig. 18.

[0113] The clone deletion process begins when a "clone deletion instruction" is sent from a host (for example, the development / test server 22, but it could also be the management server 23, etc.) requesting the deletion of a virtual clone, and is received by the clone destination node 100.

[0114] In FIG. 18, in "(1) Clone deletion instruction", development / test server 22 requests node #2 to delete virtual volume #2, which is a virtual clone.

[0115] At this time, in the controller 11 of the clone destination node #2 that has received the clone deletion instruction, the processor 13 starts the clone deletion program 152 and executes the clone deletion process.

[0116] According to Figure 19, first, the clone deletion program 152 checks whether the direct map 1416 in the volume management table 141 is "ON" for the deletion target volume included in the clone deletion instruction (virtual volume #2 in the case of Figure 18) (step S701).

[0117] If the direct map 1416 is "OFF" in step S701 (NO in step S701), this means that the data of the volume to be deleted is contained within the own node, and in this case the process proceeds to step S705 described below.

[0118] On the other hand, if the direct map 1416 is "ON" in step S701 (YES in step S701), this means that the volume to be deleted is externally connected to another node via an externally connected volume. In this case, the clone deletion program 152 starts the volume external connection release program 154, and executes volume external connection release processing to release the external connection (step S702).

[0119] 19. The volume external connection processing shown in FIG 20 corresponds to the processing of step S702 in FIG 19, and is executed by the volume external connection cancellation program 154.

[0120] 20, first, the volume external connection release program 154 receives the volume ID of the externally connected volume (pool volume #22 in the case of FIG. 18) that is to be the target for external connection release (step S801). The volume ID of the externally connected volume is the value of the corresponding pool volume ID 1417 in the record whose direct map 1416 was "ON" in step S701 of FIG. 19, and is notified to the volume external connection release program 154 by the clone deletion program 152.

[0121] Next, the volume external connection removal program 154 deletes and updates the record of the external volume (pool volume #22) identified in step S802 in the external volume management table 145 based on the volume ID received in step S801, thereby removing the external volume (pool volume #22) identified in step S802 from its own node (step S802).

[0122] The process in step S802 corresponds to "(2) External VOL release" shown in FIG.

[0123] Then, based on the external volume ID 1446 of the external volume (pool volume #22) deleted from its own node in step S803, the volume external connection removal program 154 deletes the record linking the volume to be deleted (virtual volume #2) and the external volume (pool volume #22) in the pool management table 144, thereby removing the external volume (pool volume #22) deleted from its own node in step S802 from the pool 110 (pool #2) to which it belonged (step S803), and terminates the external volume connection removal process.

[0124] The process in step S803 corresponds to "(3) Release of association between Virtual VOL and Pool VOL" shown in FIG.

[0125] By executing the above external volume connection release process, the external volume (pool volume #22) that relayed the external connection of the volume to be deleted is deleted.

[0126] Returning to the explanation of Figure 19. After the external volume connection release process is completed, the clone deletion program 152 updates the volume management table 141 in accordance with the results of the process performed in step S702 (deletion of the external volume and release of the external connection association) (step S703). Specifically, the clone deletion program 152 deletes the record of the externally connected volume (pool volume #22) from the volume management table 141, sets the value of the direct map 1416 in the record of the virtual clone (virtual volume #2) to "OFF", and deletes the volume ID of the externally connected volume (pool volume #22) that was set in the corresponding pool volume ID 1417 of that record.

[0127] Next, the clone deletion program 152 requests the controller 11 of the clone-source node (node ​​#1) to delete the intra-node virtual copy (virtual volume #3) (step S704). In the clone-source node, the intra-node virtual copy creation program 155 is called and the requested intra-node virtual copy is deleted. The process of deleting the intra-node virtual copy can be easily performed by referring to the example processing procedure for the intra-node virtual copy creation process shown in FIG. 11, so a detailed explanation will be omitted. This process corresponds to "(4) Intra-node virtual copy deletion" shown in FIG. 18.

[0128] When the processing up to step S704 is completed, or when the determination is NO in step S701 (when the direct map 1416 of the volume to be deleted is "OFF"), the clone deletion program 152 performs the processing of step S705.

[0129] In step S705, the clone deletion program 152 sets the allocation destination logical address 1436 of the page in the page management table 143 for the "old data" page in the deletion target volume (virtual volume #2) to "-", meaning unallocated.

[0130] Finally, the clone deletion program 152 initializes information regarding the clone destination volume (virtual volume #2) in the logical-physical conversion table 142 (step S706), initializes information regarding the volume to be deleted (virtual volume #2) in the volume management table 141 (step S707), and terminates the clone deletion process.

[0131] The processing in steps S705 to S707 above corresponds to "(5) Deleting virtual volume" shown in FIG.

[0132] By performing the clone deletion process in this manner, the storage system 10 can delete the virtual clone that was created across the nodes 100 in the clone creation process.

[0133] Furthermore, as a modified example of the clone deletion process, the clone deletion program 152 may delete the virtual clone and then, asynchronously with the series of processes for deleting the virtual clone, delete the data in the clone destination node (node ​​#2) that was added after the virtual clone was created. According to this modified example, it is possible to delete the added data that has become useless data that will never be used due to the deletion of the virtual clone, thereby increasing the capacity.

[0134] As described above, even under the constraint that "the virtual copy destination and copy source are limited to the same node" in a loosely coupled scale-out architecture in which multiple nodes are clustered, the storage system 10 according to this embodiment can create a virtual clone of a volume on a node different from the clone source by executing the clone creation process shown in FIG. 10 and externally connecting a virtual copy of the clone source volume from the clone destination and linking it to the clone destination virtual volume. This improves the usability of the storage system 10. Furthermore, when creating a virtual clone across nodes, since the data body (entity data) is not copied between nodes, clone creation can be completed instantly. This allows the user to immediately perform IO (input / output) operations on the clone destination volume, resulting in improved business agility.

[0135] Furthermore, the storage system 10 according to this embodiment separates the data storage destination before and after the creation of a clone, and when a request is made to write data to a virtual clone created in a node different from the clone-source node, the write process shown in Figures 14 and 15 is executed to store the write data by appending it to the clone-destination node, thereby enabling free data writing to the virtual clone without affecting the data in the clone-source node. Furthermore, data writes, which impose a higher load than data reads, are not performed to the clone-source node via an external connection across nodes, thereby preventing the load on the clone-source node from increasing.

[0136] Furthermore, when reading data from a virtual clone, the storage system 10 of this embodiment executes the read process shown in Figure 17, and if the actual data is not stored in the clone destination, it reads the data from the clone source node via an external connection and responds, thereby enabling data reading in the virtual clone equivalent to that from the clone source volume. (2) Second embodiment

[0137] In the first embodiment, when a virtual clone is created in a node different from the clone source, no copying of actual data is involved between nodes, but since data transfer from the clone source node may occur during IO (especially read) for the created virtual clone, the load on the clone source node may increase. Therefore, in the second embodiment, a storage system that enables performance rebalancing taking into account the load on the clone source node will be described.

[0138] Fig. 21 is a diagram showing a processing image of performance rebalancing processing in a storage system 10A according to the second embodiment of the present invention. The upper part of Fig. 21 shows a processing image of the first half of the rebalancing processing, which will be described later, and the lower part of Fig. 21 shows a processing image of the second half of the rebalancing processing. Furthermore, as is clear from a comparison of Fig. 21 with Fig. 1, the system configuration of the storage system 10A according to the second embodiment is similar to the system configuration of the storage system 10 according to the first embodiment, and therefore the same reference numerals are used and their explanations will be omitted.

[0139] When the load on the clone-source node (node ​​#1) exceeds a predetermined threshold due to read IO to a volume of the clone-destination node (node ​​#2), storage system 10A notifies the development / test server 22 (which may be management server 23), which is the host of the clone-destination node, of the overload. When this notification is received and a "data migration instruction" (described later) is sent from the host to the clone-destination node, processor 13 of controller 11 of the clone-destination node starts a rebalancing program (not shown) from memory 14 and executes rebalancing processing aimed at performance rebalancing. Note that the execution program for the rebalancing processing is not limited to the independent rebalancing program described above, and may be executed in part or in whole by another program stored in memory 14.

[0140] The rebalancing process in the storage system 10A will be described with reference to FIG.

[0141] First, a data migration instruction is sent from the development / test server 22, which is the host, to the virtual clone (virtual volume #2) of storage system 10A ((1) in FIG. 21). The data migration instruction may be determined by the host user, or may be executed by a program based on the load status of the read process.

[0142] In the case of Fig. 21, for example, suppose that a data migration instruction specifies that all of the old data on the clone-source node externally connected from the external volume (pool volume #22) (i.e., the entire clone-source volume) is to be the target of data migration. Receipt of this data migration instruction triggers the rebalancing program to execute rebalancing processing.

[0143] When the rebalancing program starts the rebalancing process, it copies all of the data (including, for example, page "A") held by the externally connected volume (pool volume #22) to a pool volume 120 (hereinafter referred to as an internal pool volume, specifically, for example, pool volume #21) within its own node that is not externally connected ((2) in Figure 21). In the case of Figure 21, page "A" of pool volume #22 is copied to the area of ​​page "B" of pool volume #21, which is an internal pool volume. Furthermore, in this data copy, the actual data is also copied from the externally connected clone-source node (node ​​#1) to its own node (node ​​#2) and stored in the physical drive 12 of node #2.

[0144] Next, the rebalancing program updates the logical-physical conversion table 142 and the page management table 143 based on the data copy, and assigns the page (e.g., page "A") corresponding to the old data in the virtual clone (virtual volume #2) to reference the corresponding page (e.g., page "B") in the internal pool volume (pool volume #21) to which the data is copied ((3) in Figure 21).

[0145] Then, if the data specified as the target of data migration is the entire old data, once copying of this entire old data is complete, the rebalancing program starts the volume external connection release program 154 to perform external connection release processing, thereby releasing the external connection of the externally connected volume ((4) in FIG. 21) and releasing the link between the virtual clone (virtual volume #2) and the externally connected volume (pool volume #22) ((5) in FIG. 21). The detailed processing procedure of (4) to (5) in FIG. 21 is the same as the processing procedure shown in FIG. 20. Note that if the data specified as the target of data migration is only a part of the old data, the external connection is not released.

[0146] When the process is completed up to (5) in FIG. 21, all data entities of the clone destination node will be stored in the node itself (node ​​#2).

[0147] Thereafter, the intra-node virtual copy is deleted in the clone source node (node ​​#1) in the same procedure as steps S704 to S707 of the clone deletion process shown in FIG. 19 ((6) in FIG. 21).

[0148] As described above, in storage system 10A, by executing rebalancing processing according to the IO status, it is possible to copy the old data that was read from the clone-source node to its own node together with the actual data without stopping (continuing) the IO to the clone-destination node. As a result, even if a read request for old data is made to the virtual clone, the IO to the clone-destination node can be completed within its own node, so data transfer from the clone-source node does not occur, and it is possible to achieve performance rebalancing that suppresses the load on the clone-source node.

[0149] In the above explanation, the entire old data (the entire externally connected volume) is the target of data copying, but the target of data copying in this embodiment is not limited to this, and data may be copied in units of a specified page, for example. However, in either case, the target area for data copying includes at least the read-target data of the old data. For example, during read IO, if an excessive load is placed on the entire volume in the clone-source node, the entire volume can be the target of data copying, and if an excessive load is placed on a page-by-page basis, the relevant page can be the target of data copying.

[0150] Furthermore, a known method for determining whether to issue a data migration instruction can be used. For example, the decision to migrate data does not have to be based on a single read request, but rather the result of multiple read requests can be taken into account to determine whether the load threshold has been exceeded. Furthermore, the timing of issuing a data migration instruction does not have to be related to the read request, as long as it is issued after at least one read request.

[0151] Furthermore, if the data copied by a data migration instruction is common data, the data is transmitted to both the copy source and copy destination, i.e., the clone-source node and the clone-destination node, so the capacity consumed by the entire storage system 10A doubles, but the effect of reducing the load during IO processing can be expected. Furthermore, if the data copied by a data migration instruction is single data that is used only at the clone destination, the data can be deleted at the copy source, i.e., the clone-source node, so the capacity consumed by the entire storage system 10A can be maintained, while the load on the clone-source node can be reduced. (3) Third embodiment

[0152] In the first and second embodiments, the storage system 10 (10A) and the hosts (production server 21, development / test server 22, management server 23) are all described as being constructed on-premise. However, the storage system according to the present invention can also be applied to an environment that combines on-premise and a cloud (for example, a public cloud). Therefore, in the third embodiment, a storage system 10B applied to an environment that combines on-premise and a public cloud will be described. Note that the type of cloud to which this embodiment can be applied is not limited to a public cloud.

[0153] 22 is a block diagram showing an example of the hardware configuration of an overall system including a storage system 10B according to a third embodiment of the present invention. As shown in Fig. 22, the overall system including the storage system 10B and the host according to the third embodiment is constructed in an on-premise environment 40 and a public cloud environment 50 connected by networks (a storage network 31 and a management network 32).

[0154] In the on-premises environment 40, a storage system 10B and a production server 21 are connected via a storage network 31. The storage system 10B is also connected via the storage network 31 to a development / test server 22 in a public cloud environment 50 and a software-defined storage (SDS) 51 consisting of one or more nodes 500. The storage system 10B is also connected to a management server 23 in the public cloud environment 50 via a management network 32. The hardware configuration of the storage system 10B is similar to the hardware configuration of the storage system 10 according to the first embodiment shown in FIG. 2, and therefore a detailed description thereof will be omitted. The production server 21 has similar functions to those of the production server 21 according to the first embodiment.

[0155] In the public cloud environment 50, a development / test server 22, a management server 23, and an SDS 51 consisting of one or more nodes 500 are connected to each other via a network, and are also connected to the on-premise environment 40. The development / test server 22 and the management server 23 have the same functions as the development / test server 22 and the management server 23 described in the first embodiment.

[0156] The SDS 51, which is configured from one or more nodes 500 not present in the first embodiment, is a storage area provided in the public cloud environment 50. The SDS is a computer program that provides storage functions similar to those of the controller 11 of the node 100 in the on-premises environment 40, and can call and execute various programs in the node 500 in the public cloud environment 50, just like the controller 11 in the on-premises environment 40. One of the features of the storage system 10B according to this embodiment is that it is possible to create a virtual copy of a virtual volume created in the node 100 of the storage system 10B in the node 500 on the public cloud environment 50 side.

[0157] Fig. 23 is a diagram showing a processing image of a clone creation process from storage system 10B to SDS 51. The upper part of Fig. 23 shows a processing image when an instruction is given to create a clone of a predetermined volume (e.g., virtual volume #1) in node 100 (e.g., node #1) in on-premise environment 40, with node 500 (e.g., node #2) in public cloud environment 50 as the creation destination, and the lower part of Fig. 23 shows a processing image during the subsequent clone creation process.

[0158] In the third embodiment, the clone creation process in which the public cloud environment 50 is used as the creation destination is basically executed in the same procedure as the clone creation process described in the first embodiment.

[0159] To give an overview with reference to Figure 23, first, a clone instruction is issued requesting that a clone of a specified volume (virtual volume #1) of node #1 be created on node 500 in the public cloud environment 50 (Figure 23(1)).

[0160] Next, the clone creation program 151 of the clone source node (node ​​#1) calls the intra-node virtual copy creation program 155 and executes the intra-node virtual copy creation process shown in Figure 11, thereby creating an intra-node virtual copy (virtual volume #3) of the clone source volume (Figure 23 (2)).

[0161] Next, the clone creation program 151 of the clone source node sends a volume external connection request to the SDS 51 of the clone destination node (node ​​#2), and the SDS 51 starts the volume external connection program 153 in its own node to execute volume external connection processing, thereby externally connecting the intra-node virtual copy (virtual volume #3) created in the intra-node virtual copy creation processing to the pool volume (pool volume #22) of the clone destination node (FIG. 23(3)). The processing of FIG. 23(3) differs from the processing in the first embodiment in that the SDS 51 in the clone destination node controls the processing, but the processing content is similar to that of the first embodiment.

[0162] Next, the clone creation program 151 of the clone destination node updates the volume management table 141 and the page management table 143 to associate the pages in the clone destination volume (virtual volume #2) with the pages in the external volume (pool volume #22) to which the intra-node virtual copy (virtual volume #3) is externally connected on a one-to-one basis (Figure 23 (4)).

[0163] As described above, by performing the clone creation process in the same manner as in the first embodiment, the storage system 10B according to the third embodiment can also create a virtual clone of a volume in the public cloud environment 50 across nodes (between different nodes), even under the constraint of the loosely coupled scale-out architecture that the destination and source of the virtual copy must be the same node.

[0164] Furthermore, although detailed description will be omitted, the storage system 10B according to the third embodiment can also execute the various storage operation processes (write process, read process, clone deletion process) described in the first embodiment in addition to the clone creation process described above. Furthermore, as described in the second embodiment, the storage system 10B according to the third embodiment can also copy part or all of the old data to a clone destination node together with the actual data. Therefore, such a storage system 10B can apply the storage systems 10 and 10A according to the first and second embodiments to secondary use in cloud space. (4) Fourth embodiment

[0165] In the third embodiment, an example was described in which a volume copy was virtually created in an environment in which a storage system 10B was deployed on-premise and an SDS 51 was deployed in a cloud (for example, a public cloud). In the fourth embodiment, similar to the third embodiment, an example will be described in which data in the storage system 10B is prefetched from the SDS 51 in an environment in which a storage system 10B in an on-premise environment 40 and an SDS 51 in a public cloud environment 50 are combined.

[0166] FIG. 24A shows a comparative example, and FIG. 24B shows a use case of the fourth embodiment.

[0167] 24A, a production server 21 and an application server 24 are connected to an on-premise storage system 10B. The production server 21 performs, for example, a core business, and the application server 24 performs, for example, an unstructured analysis task or a monthly batch processing task. The unstructured analysis and monthly batch processing are performed on data in a snapshot 133 that stores the state of data at any point in time in a virtual volume 130 in which data for the core business is stored.

[0168] If the on-premise storage system 10B performs non-core business operations such as non-routine analysis operations and monthly batch processing operations, the load on the storage system 10B will increase sharply, which may impair the stable operation of the core business operations in terms of performance, etc.

[0169] FIG. 24B shows a configuration that improves this problem. A production server 21 is connected to a storage system 10B on-premises 40, and an application server 24 is connected to an SDS 51 in a public cloud environment 50. A system including the storage system 10B and the SDS 51 is an example of a storage system having multiple nodes including first and second nodes. Node #1 (node ​​100) is an example of a first node, virtual volume #1 (virtual volume 130) is an example of a first virtual volume, and the production server 21 is an example of a host of the first node (a request source that sends a read request or a write request specifying the address of the first virtual volume). Node #2 (node ​​500) is an example of a second node, virtual volume #2 (virtual volume 130) is an example of a second virtual volume, and the application server 24 is an example of a host of the second node (a request source that sends a read request or a write request specifying the address of the second virtual volume). Furthermore, pool volume #22 (external volume 120) is an example of a first pool volume, and pool volume #21 is an example of a second pool volume.

[0170] The access target for the ad hoc analysis and monthly batch processing executed by the application server 24 in the public cloud environment 50 is a snapshot 133 created in the storage system 10B in the on-premises environment 40. As in the third embodiment, an external connection function is used to access data in the storage system 10B in the on-premises environment 40 from the SDS 51 in the public cloud environment 50. The external volume 120 of the SDS 51 and the snapshot 133 of the storage system 10B are connected (mapped) using a procedure similar to that of the flow in FIG. 12 . In addition, the volume management table 141 is updated so that the virtual volume #2 directly accessed from the application server 24 and the external volume 120 are directly mapped (1:1 address association). That is, in S305 in FIG. 12 , the ID of the external volume 120 is recorded as the corresponding pool volume ID 1417 in the volume management table 141. As a result, it becomes possible to access data in the storage system 10B in the on-premises environment 40 from the SDS 51 in the public cloud environment 50.

[0171] Before ad hoc analysis and monthly batch processing are performed, the data to be accessed is transferred (prefetched) from storage system 10B to SDS 51 in advance. This allows storage system 10B in the on-premises environment 40 to achieve stable operation of mission-critical business without being affected by sudden increases in load due to ad hoc analysis and monthly batch processing. Furthermore, prefetching data to SDS 51 eliminates the need to access data from storage system 10B in the on-premises environment 40, which is physically far from SDS 51, thereby shortening the processing time for ad hoc analysis and monthly batch processing, which in turn contributes to suppressing performance degradation of virtual volume #2.

[0172] 25, like Fig. 3, is a diagram showing an example of the configuration of the memory 14 of the storage system 10B and the SDS 51, and is a diagram showing an example of the programs and control data in the memory 14 used by the storage system 10B and the SDS 51. The difference from Fig. 3 is that a prefetch processing program 158 and a snapshot scheduler program 159 are stored in the program section 150. The details of the processing by each program will be described later.

[0173] FIG. 26 is a diagram illustrating a process of prefetching data of a snapshot 133 of storage system 10B from SDS 51 before ad hoc analysis and monthly batch processing. FIG. 27 is a flowchart illustrating an example of the prefetch process procedure. The upper part of FIG. 26 illustrates a process performed when an instruction is issued to prefetch data of a predetermined snapshot 133 (e.g., Snapshot #M) in a node 100 (e.g., node #1) in the on-premises environment 40 to a node 500 (e.g., node #2) in the public cloud environment 50. The lower part of FIG. 26 illustrates a process performed during the subsequent prefetch process. In the following description, "storage system 10B" may be read as "node #1," and "SDS 51" may be read as "node #2."

[0174] The following describes the prefetch processing procedure according to the flowchart in FIG. 27, while appropriately indicating corresponding parts in FIG. 26. First, in step S2701 in FIG. 27, the management server 23 issues a prefetch instruction to the SDS 51. Specifically, an instruction is issued to prefetch data of a predetermined snapshot 133 (Snapshot #M) of node #1 to node 500 in the public cloud environment 50. This corresponds to (S2601) in FIG. 26. The prefetch instruction may specify Snapshot #M (e.g., the current generation number) as the target of the current ad-hoc analysis / monthly batch processing, as well as Snapshot #N (e.g., the previous generation number) as the target of the previous ad-hoc analysis / monthly batch processing. The management server 23 may be located in the on-premises environment 40 instead of the public cloud environment 50, or may be located in an environment separate from these environments 40 and 50.

[0175] Next, in step S2702, the SDS 51 executes processing to switch the connection destination of the externally connected volume 120 (pool volume #22). That is, the prefetch processing program 158 of node #2 switches the snapshot of the external connection destination. Before the prefetch command, the externally connected volume 120 of the SDS 51 was connected to Snapshot #N of the storage system 10B, but this switching processing changes the connection destination of the externally connected volume 120 to Snapshot #M. This processing corresponds to (S2602) in FIG. 26. This processing to switch the external connection destination of the externally connected volume is performed by processing similar to step S303 in FIG. 12. That is, in S303 in FIG. 12, the entry for its own externally connected volume ID in the external volume management table is updated. Specifically, the target device ID 1454 is rewritten from the ID representing Snapshot #N to the ID representing Snapshot #M, which is the switching destination Snapshot. As a result of the above, Snapshot #M in the storage system 10B in the on-premise environment 40 can be accessed from the SDS 51 in the public cloud environment 50.

[0176] Next, in step S2703, the prefetch processing program 158 of the SDS 51 initializes the logical-physical conversion table 142 of the virtual volume 130 accessed by the application server 24. This initialization processing causes data that was prefetched to the SDS 51 by the previous prefetch processing to become invalid (subject to garbage collection). For example, if Snapshot #N before the switch was the target of ad hoc analysis / monthly batch processing, data A and data B of page 131 (address) of Snapshot #N were prefetched to the SDS 51, but this initialization processing causes data A and data B to become invalid. This corresponds to (S2603) in FIG. 26. Note that the invalidated data may be deleted by garbage collection, and the remaining data may be packed up, resulting in the remaining data being present in a contiguous address range.

[0177] Next, in step S2704, the prefetch processing program 158 instructs the storage system 10B in the on-premises environment 40 to acquire differential position information (information indicating the differential position) between Snapshot #N before switching the external connection and Snapshot #M after switching the external connection. This is processing equivalent to (S2604) in FIG. 26. Note that the differential position between Snapshot #N and Snapshot #M is the address of Snapshot #M where there is a difference in data between Snapshot #M and Snapshot #N. Snapshot #M is an example of a third virtual volume, and Snapshot #N is an example of a third virtual volume of an older generation than the third virtual volume (for example, the immediately previous generation).

[0178] Next, in step S2705, the prefetch processing program 158 of the storage system 10B creates differential location information between Snapshot #N and Snapshot #M in response to the differential location information acquisition instruction from the SDS 51, and returns the created differential location information to the SDS 51. This is the process equivalent to (S2605) in Fig. 26. In the example of Fig. 26, the differential location between Snapshot #N and Snapshot #M is the location of data C on page 131 of Snapshot #M. Because the location of data B has not been updated since Snapshot #N, it is not a differential location.

[0179] Next, in step S2706, the prefetch processing program 158 of the SDS 51 reads data C from the position (differential position) of data C on page 131. In other words, data C is transferred from the storage system (block storage) 10B to the SDS 51. This corresponds to the processing of (S2606) in FIG. 26. The read processing will be explained in detail later with reference to FIGS. 30 and 31, and data is read from the differential position identified for virtual volume #2. Because virtual volume #2 is directly mapped to pool volume #22 (external volume 120), the differential position to be read is the same position in pool volume #22 as in virtual volume #2. Furthermore, pool volume #22 reads data C (data C in FIG. 26) on page 131 of the differential position of externally connected Snapshot #M. As described above, the differential position (address of the differential data position) identified for Snapshot #M is the same for virtual volume #2 and pool volume #22, and data is read from Snapshot #M to virtual volume #2 via pool volume #22 at this position.

[0180] Next, in step S2707, the prefetch processing program 158 of the SDS 51 stores the read data in its own pool #2. This is the process corresponding to (S2607) in Fig. 26. Specifically, the prefetch processing program 158 stores (appends) the data in a pool volume other than the externally connected volume (pool volume #22) in pool #2. According to the example shown in Fig. 26, data C is stored in pool volume #21 other than the externally connected volume, and the logical-physical conversion table 142 is updated so that virtual volume #2 references data C stored in page 121 of pool volume #21.

[0181] Next, in step S2708, the prefetch processing program 158 of the SDS 51 responds to the management server 23 that the prefetch processing has been completed.

[0182] As described above, before the execution of the ad hoc analysis / monthly batch processing, the updated data from the data to be processed in the previous ad hoc analysis / monthly batch, specifically, data C shown in Fig. 26, can be prefetched to the SDS 51. After this, in response to a request from the application server 24, the SDS 51 performs IO processing of the data, and there is a high probability that the application server 24 will access data C, which is the updated portion from the data processed previously, and because data C has already been transferred to the SDS 51 by the prefetch processing, high-speed access is possible.

[0183] FIG. 28 is a diagram showing a processing image of a write process of the SDS 51 to the virtual volume 130. FIG. 28 shows an image in which write data is transferred to the SDS 51 in response to a write request from the application server 24 to the virtual volume 130, and then the SDS 51 stores the data in the pool 110. FIG. 29A shows a flowchart showing an example of the processing procedure for write processing on the front-end side, and FIG. 29B shows a flowchart showing an example of the processing procedure for write processing on the back-end side. The write processing procedure on the front-end side is performed by the SDS 51 in the same manner as in FIG. 14. That is, in the controller 11 of the node 500 that received the write request, the write program 156 executes the front-end write processing shown in FIG. 29A and the back-end write processing shown in FIG. 29B in parallel. Below, the processing procedure for write processing will be explained according to the flowcharts of FIGS. 29A and 29B, while appropriately indicating corresponding parts in FIG. 28.

[0184] When a write request is made from the host (application server 24) to write data to virtual volume #2 of SDS 51, the processor 13 in the controller 11 of node #2 having the write destination virtual volume #2 starts up the write program 156 and executes the write process. The write request includes the data to be written (write data) and the write destination address in the target virtual volume 130.

[0185] A write request to the virtual volume 130 is made from the application server 24 (S2801 in FIG. 28), and write data 132 designated "D" is transferred. Here, virtual volume #2 is a virtual volume for accessing target data for ad hoc analysis / monthly batch processing, but in reality, Snapshot #M in the block storage 10B of the on-premises environment 40 is externally connected to pool volume #22 that is straight-mapped to virtual volume #2, making it possible to access the data in Snapshot #M. Also, as shown in FIGS. 26 and 27, update differential data for virtual volume #1 between the creation of Snapshot #N and the creation of Snapshot #M may be prefetched to the SDS 51 as data for virtual volume #2.

[0186] 29A, at the front end, upon receiving a write request, the write program 156 first checks whether a cache area for the write destination address has been secured in the cache unit 160, in other words, whether the data at the write destination address is stored in the cache unit 160 (whether there is a cache hit) (step S2901). If there is no cache hit (Miss in step S2901), the write program 156 secures a cache area for the write data (step S2902) and transfers the write data to that cache area (step S2903). On the other hand, if there is a cache hit (Hit in step S2901), the write program 156 skips step S1902 and transfers the write data to the corresponding cache area (step S1903).

[0187] The write program 156 then returns a normal response (Good response) to the write request to the host (step S1904), and ends the write processing at the front end.

[0188] Furthermore, as shown in Fig. 29B, the write program 156 executes backend write processing asynchronously, for example. First, it checks whether dirty data exists in the write destination volume (virtual volume #2) (step S2905). If dirty data exists (YES in step S2905), it proceeds to step S2906, and if dirty data does not exist (NO in step S2905), it ends the processing.

[0189] In step S2906, the write program 156 ensures data consistency between the control information unit 140 and the cache unit 160 based on the dirty data, then allocates pages of the write data in the destination volume (virtual volume #2) and updates the page management table 143.

[0190] One of the features of the SDS 51 is that the external volume to which at least a snapshot of the block storage 10B is externally connected is pool volume #22, and furthermore, in response to a write request to a virtual volume 130 (for example, virtual volume #2 in FIG. 28) that is directly mapped to the pool volume 120, the write program 156 of the node (node ​​#2) that constitutes the SDS 51 writes write data using the log structure method within the node itself (so-called "append"). Note that the write program 156 may also perform an append in the same way in response to a write request to a virtual volume 130 that is not directly mapped to the pool volume #120.

[0191] In writing (appending) using the log structure method, the pool 110 (pool volume 120) holds historical data (pre-update data) updated by the write data 132. Specifically, when a write request is made for existing data in the virtual volume 130, the write program 156 retains the existing data (pre-update data) in the pool volume 120 and writes (appends) separate write data (post-update data) to a pool volume 120 (e.g., pool volume #22) that is not an externally bounded volume. The write program then changes the mapping from the virtual volume 130 (write destination address) to the pool volume 120 from the address where the pre-update data is located (pool volume address) to the address where the post-update data is located (pool volume address). As a result, data is updated in the virtual volume 130, and the historical pre-update data is held in the pool 110 (pool volume 120). However, because the historical pre-update data is no longer referenced by the virtual volume 130, it may be invalidated asynchronously, for example. Furthermore, when a request to write new data is made to the virtual volume 130, since there is no pre-update data in the pool volume 120 linked to the virtual volume 130, the write program 156 may write the write data to the pool volume 120 that is not an external volume, and map the write data from the virtual volume 130 to the pool volume 120.

[0192] Figure 28 shows an example of writing using the log structure method, illustrating a processing image when a write request is made to virtual volume #2 for write data 132 (data "D"). Specifically, the write program 156 of node #2 writes write data (data "D") to pool volume #21, which is not an external volume, without performing any processing such as deletion or movement on existing data in pool #2 (data "C" and "B" in pool volume #22 and data "A", "B", and "C" in pool volume #21), and maps this data "D" from virtual volume #2 to pool volume #21.

[0193] Such an append corresponds to S2802 in Fig. 28, and it can be seen that pool volume #21 is set as the storage destination of the above-mentioned write data (data "D"), and data "D" in pool volume #21 is allocated to data "D" in virtual volume #2. Note that if the write request for the write data 132 is to update data "C" in virtual volume #2, in Fig. 28, the mapping destination of the old data (data "C") in virtual volume #2 is set to the newly written data "D" in pool volume #21, and data "C" in virtual volume #2 is updated to data "D".

[0194] Thereafter, the write program 156 destages the dirty data (step S2907), updates the logical-physical conversion table 142 regarding the destage (step S2908), and ends the process.

[0195] By executing the write process as described above, when data is written to the virtual volume #2 accessible via the external volume #22 in the data of the snapshot 130 of the storage system 10B, the write data is appended within the node #2 of the SDS 51. As a result, a write operation to the virtual volume #2 of the SDS 51 can be performed without imposing a load on or affecting the on-premise storage system 10B.

[0196] 30A and 30B are diagrams illustrating an example of a read processing flow. FIG. 30A illustrates a process image of the read processing when a host issues a read request to virtual volume #2 of SDS 51 for data stored in its own node (i.e., when the destination volume of the read request and the storage destination of the actual read data are the same node). FIG. 30B illustrates a process image of the read processing when a host issues a read request to virtual volume #2 for data stored in another node (i.e., when the destination volume of the read request and the storage destination of the actual read data are different nodes; in the example at the bottom of FIG. 30, when the actual data is stored in block storage 10B of on-premises environment 40). The example illustrated in FIG. 30B also partially includes the differential position read processing within the prefetch processing described above in FIGS. 26 and 27, i.e., step S2706 of FIG. 27 (the read processing corresponding to S2606 of FIG. 26).

[0197] 31 is a flowchart showing an example of the processing procedure for read processing. The processing procedure for read processing will be explained below with reference to the flowchart in FIG. 31, while appropriately indicating corresponding parts in FIG. 30A and FIG. 30B.

[0198] When a read request is made from a host (production server 21, application server 24, or management server 23) to read data from a virtual volume of SDS 51, the processor 13 in the controller 11 of the node 500 that received the read request starts the read program 157 and executes the read process. The read request includes the storage range of the read data in the target volume (read target area).

[0199] According to Fig. 31, first, the read program 157 receives a read request (step S3101). In Fig. 30A, in S3001A, a read request for data "C" is made to virtual volume #2. Also, in Fig. 30B, in S3001B, a read request for data "B" is made to virtual volume #2.

[0200] Next, the read program 157 performs a cache hit / miss determination to determine whether the read data is stored in the cache unit 160 (step S3102). If the read data is a cache hit (Hit in step S3102), it is determined whether it is a prefetch instruction (step S3109). If it is a prefetch instruction (YES in step S3109), the read program 157 ends the read processing. If it is not a prefetch instruction (No in step S3109), the read program 157 transfers the cache-hit data to the host (step S3110) and ends the read processing. On the other hand, if the read data is a cache miss (Miss in step S3102), the processing proceeds to step S3103.

[0201] In step S3103, the read program 157 references the read target area in the logical-physical conversion table 142. Then, the read program 157 checks whether the value of the physical address 1422 of the read target area referenced in step S3103 is an invalid value (step S3104). If the value of the physical address 1422 of the read target area is an invalid value in step S3104 (YES in step S3104), the process proceeds to step S3105, and if the value of the physical address 1422 of the read target area is not an invalid value (NO in step S3104), the process proceeds to step S3107.

[0202] 5, in the logical-physical conversion table 142, if the data is not stored in the own node (specifically, for example, if the data is stored in a node other than the node where the read-target virtual volume exists), the value of the physical address 1422 is an invalid value such as "FFFFFFFF." In FIG. 30A, when the read data is data "C," data "C" is stored in node #2, which is the own node, and therefore the physical address of the storage destination is indicated in the physical address 1422. On the other hand, in FIG. 30B, when the read data is data "B," data "B" is stored in node #1 of storage system 10B in the on-premises environment 40, and therefore the physical address 1422 indicates an invalid value.

[0203] That is, if the entity of the read data is stored in the local node (Figure 30A), processing proceeds from step S3104 to step S3107, and if the entity of the read data is not stored in the local node (Figure 30B), processing proceeds from step S3104 to step S3105.

[0204] First, when processing proceeds from step S3104 to step S3105, the read program 157 refers to the volume management table 141 and identifies the pool volume 120 (pool volume #22) to which the data of the target volume (virtual volume #2) of the read request is directly mapped (straight mapped) from the corresponding pool volume ID 1417 (step S3105).

[0205] Next, the read program 157 stages the data at the same address as the read target area from the pool volume 120 identified in step S3105 (step S3106). This process corresponds to S3002B in FIG. 30B. Specifically, as indicated by the thick arrow in FIG. 30B, a read request is made to read data "B" in pool volume #11 of node #1 in the on-premises environment 40 as the data at the same address via Snapshot #M to which the pool volume #22 identified in step S3105 is externally connected, and the actual data of data "B" is read from the physical drive 12 that stores the actual data of this data "B" and transferred to the cache unit 160 of node #2.

[0206] After processing step S3106, the read program 157 then dirties the data in the cache transferred in step S3106 (step S3108). As a result of dirtiness, the data read from the storage system 10B in the on-premise environment 40 becomes a target for destaging to the local node (node ​​#500) of the SDS 51 (S3003B in FIG. 30B). By storing (prefetching) the data read from the on-premise environment 40 in the local node in this way, high-speed access becomes possible when the data is read again from the application server 24. Appends may also be written during this prefetch. Next, the read program 157 determines in step S3109 whether a prefetch instruction is issued (step S3109). If a prefetch instruction is issued (Yes in step S3109), the read process ends. If the command was not a prefetch command (No in step S3109), the read program 157 transfers the data that has been read into the cache to the host (step S3110) and ends the read process.

[0207] On the other hand, if the process proceeds from step S3104 to step S3107, the read program 157 refers to the logical-physical conversion table 142, and stages data from the page indicated by the physical address 1422 corresponding to the logical address of the read target area (step S3107). This process corresponds to S3002A in FIG. 30A. Specifically, as shown by the thick arrow in FIG. 30A, the data in the page indicated by the logical address of the read target area is data "C" in pool volume #21, and the entity data of this data "C" is read from the physical drive 12 that stores the entity data of this data "C" and transferred to the cache unit 160.

[0208] After the processing of step S3107, the read program 157 transfers the data on the cache transferred in step S3107 to the host (step S3110), and ends the read processing.

[0209] By executing the read process as described above, if a valid value is set in the mapping information (logical-to-physical conversion table 142), SDS51 will read the read data from its own node and respond, whereas if an invalid value is set in the mapping information (logical-to-physical conversion table 142), it will determine that the read data is located in another node and will read the data from the other node via the external volume and respond.

[0210] 32 is a flowchart showing the processing steps for periodically creating snapshots of virtual volume #1 accessed from production server 21 in storage system 10B of on-premises environment 40. Snapshots, which can instantly virtually replicate data from virtual volume #1, are often used for the purpose of logical data protection and are often created periodically. A retention period (protection period) can be set for the snapshot, and the snapshot cannot be deleted or rewritten for the time from when it was created until the retention period has elapsed, thereby maintaining the snapshot as a backup.

[0211] The snapshot scheduler program 159 of the storage system 10B is started asynchronously, for example. After starting, the snapshot scheduler program 159 determines whether the timing for deleting / creating a snapshot has arrived based on information (not shown) about the snapshot creation cycle and retention period set in advance by the user via the management server 23. In step S3201, the snapshot scheduler program 159 checks the retention period of the oldest snapshot and checks whether the remaining retention period has reached 0. If the remaining retention period is 0 (YES in step S3201), the process proceeds to step S3202. If there is any remaining retention period (NO in step S3201), the process proceeds to step S3203.

[0212] In step S3202, since the remaining Retention period of the oldest snapshot has reached 0, the snapshot scheduler program 159 deletes the oldest Snapshotto.

[0213] In step S3203, the snapshot scheduler program 159 determines whether it is time to create a new snapshot. If it is time to create a new snapshot (YES in step S3203), the process proceeds to processing step S3204. If it is not time to create a new snapshot (NO in step S3203), the snapshot scheduler program 159 ends.

[0214] In step S3204, the snapshot scheduler program 159 creates a snapshot. Specifically, for example, the snapshot scheduler program 159 executes the intra-node virtual copy creation process described with reference to FIG. (5) Fifth embodiment

[0215] Next, a method different from the prefetch processing described in the fourth embodiment using FIGS. 26 and 27 will be described. In the fourth embodiment, the data prefetched in the previous prefetch processing was invalidated before the prefetch processing. Specifically, in FIG. 26, data "A" and "B" that were prefetched to the SDS 51 by referencing Snapshot #N from an external volume at the time of the previous processing were invalidated in the SDS 51 before the current prefetch processing. Data "C" at the differential position between the currently externally connected Snapshot #M and the previously externally connected Snapshot #N was prefetched. In this method, the data entity of data "B" that has not been updated between the creation of Snapshot #N and the creation of Snapshot #M exists only in the storage system 10B of the on-premises environment 40. Therefore, if data "B" is accessed in the SDS 51, the data must be transferred again from the on-premises environment to the public cloud environment 50, which affects the agility of ad hoc analysis / monthly batch processing.

[0216] The fifth embodiment solves this problem. Specifically, in the lower part of FIG. 33 , even after switching the external connection destination from Snapshot #N to Snapshot #M, the previously prefetched data “B” is not treated as data to be invalidated in the SDS 51, and high-speed access can be provided even when the data “B” is accessed from the application server 24. Note that the fifth embodiment (in which the previously prefetched data is not treated as data to be invalidated in the SDS 51) is preferably applied to a case where data overlaps between Snapshot #N, the previous analysis target, and Snapshot #M, the current analysis target (for example, the case of an application such as “data analysis”). On the other hand, the fourth embodiment (in which the previously prefetched data is treated as data to be invalidated in the SDS 51) is preferably applied to a case where only data updated within a certain period (for example, the period from Snapshot #N to Snapshot #M) is treated as data to be handled (utilized) (for example, the case of “monthly batch processing”).

[0217] Furthermore, the upper part of Figure 33 shows an example in which data "E" is written to virtual volume #2 during the period when Snapshot #N has an external connection to external volume 120. However, according to the lower part of Figure 33, data "E" written from the host (application server 24) in the public cloud environment 50 is subject to invalidation after the external connection destination is switched to Snapshot #M.

[0218] Fig. 33 is a diagram showing a processing image of the process of prefetching data of the snapshot 133 of the storage system 10B from the SDS 51 before the ad hoc analysis and monthly batch processing. Fig. 34 shows an example in which a host write data flag 1423 has been added to the logical-physical conversion table 142 of Fig. 5. The host write data flag 1423 is used to determine whether the data is to be invalidated because it is host write data after the Snapshot of the external connection destination is switched, or whether the data is not to be invalidated because it is data read from the on-premises environment 40 in the prefetch processing.

[0219] Fig. 35 is a flowchart showing an example of the processing procedure for prefetch processing, and differs from Fig. 26 in whether or not the previously prefetched data is retained. The upper part of Fig. 33 shows a processing image when an instruction is given to prefetch data of a predetermined snapshot 133 (e.g., Snapshot #M) in a node 100 (e.g., node #1) in the on-premise environment 40 to a node 500 (e.g., node #2) in the public cloud environment 50, and the lower part of Fig. 33 shows a processing image during the subsequent prefetch processing.

[0220] The following describes the processing steps of the prefetch process according to the flowchart in Fig. 35, while appropriately indicating corresponding parts in Fig. 33. First, in step S3501 in Fig. 35, the management server 23 issues a prefetch instruction to the SDS 51. Specifically, an instruction is issued to prefetch data of a predetermined snapshot 133 (Snapshot #M) of node #1 to node 500 in the public cloud environment 50. This is processing equivalent to (S3301) in Fig. 33.

[0221] Next, in step S3502, the SDS 51 executes processing to switch the connection destination of the external volume. That is, the prefetch processing program 158 of the node 500 (node ​​#2) switches the snapshot of the external connection destination. Before the prefetch command, the external volume 120 of the SDS 51 was connected to Snapshot #N of the storage system 10B, but the connection destination is changed to Snapshot #M. This processing corresponds to (S3302) in FIG. 33. This processing to switch the external connection destination of the external volume is performed by processing similar to step S303 in FIG. 12. That is, in S303 in FIG. 12, the entry for the local externally connected volume ID in the external volume management table is updated. Specifically, the target device ID 1454 is changed from the ID representing Snapshot #N to the ID representing Snapshot #M, which is the switching destination Snapshot. As a result, it becomes possible to access Snapshot #M in the storage system 10B in the on-premises environment 40 from the SDS 51 in the public cloud environment 50.

[0222] Next, in step S3503, the prefetch processing program 158 of the SDS 51 initializes the entry indicating the host write data in the logical-physical conversion table 142 of the virtual volume 130 accessed by the application server 24, thereby invalidating the data written to the host while Snapshot #N was externally connected. This invalidation processing invalidates the host write data "E" in the upper part of Figure 33. Furthermore, the prefetch data "B" of Snapshot #N before the snapshot switch is not subject to invalidation. This is the processing equivalent to (S3303) in Figure 33. To determine whether the data is host write data or prefetch data in step S3503, the prefetch processing program 158 references the host write data flag 1423 in Figure 34.

[0223] Next, in step S3504, the prefetch processing program 158 instructs the storage system 10B in the on-premises environment 40 to acquire differential location information between Snapshot #N before switching the external connection and Snapshot #M after switching the external connection. This is processing equivalent to (S3304) in FIG. 33.

[0224] Next, in step S3505, the prefetch processing program 158 of the storage system 10B creates differential location information between Snapshot #N and Snapshot #M in response to the differential location information acquisition instruction from the SDS 51, and returns the created differential location information to the SDS 51. This is the process equivalent to (S3305) in Fig. 33. In the example of Fig. 35, the differential location between Snapshot #N and Snapshot #M is the location of data C on page 131 of Snapshot #M. Because the location of data "B" has not been updated since Snapshot #N, it is not a differential location.

[0225] Next, in step S3506, the prefetch processing program 158 of the SDS 51 reads data C. As a result, data "C" is transferred from the block storage 10B to the SDS 51. This corresponds to the processing of (S3306) in Fig. 33. The read processing is similar to that of Figs. 30 and 31 described above, and data is read from the differential position identified for virtual volume #2.

[0226] Next, in step S3507, the prefetch processing program 158 of the SDS 51 stores the read data in its own pool #2. This is the process corresponding to (S3307) in Figure 33. According to Figure 33, data "C" is stored in pool volume #21 other than the external volume, and the logical-physical conversion table 142 is updated so that virtual volume #2 references data "C" stored in page 121 of pool volume #21.

[0227] Next, in step S3508, the prefetch processing program 158 of the SDS 51 responds to the management server 23 that the prefetch processing has been completed.

[0228] As described above, before the execution of the ad hoc analysis / monthly batch processing, the data "C" in the example of FIG. 33, which is an update from the data to be processed in the previous ad hoc analysis / monthly batch, can be prefetched to the SDS 51. Thereafter, in response to a request from the application server 24, the SDS 51 performs data I / O processing. There is a high probability that the application server 24 will access data "C," which is an update from the data processed previously, and because data "C" has already been transferred to the SDS 51 by the prefetch processing, high-speed access is possible. Furthermore, in the fifth embodiment, the prefetched data "B" when Snapshot #N was externally connected also remains in the SDS 51's own node (node ​​500), and access to data "B" can also be performed high-speed.

[0229] Although several embodiments have been described above, these are merely examples for explaining the present invention, and the scope of the present invention is not limited to these embodiments. The present invention can be implemented in various other forms. For example, one or more physical drives 12 may exist outside the node, and the node may not necessarily include the physical drives 12.

[0230] The above description can be summarized as follows, for example. The following summary may include supplementary explanations and explanations of modifications of the above.

[0231] A storage system has a plurality of nodes including a first node and a second node. Each node has a virtual volume, a pool (a pool consisting of one or more pool volumes, in which data addressed to a virtual volume address is logically stored at an address mapped to the address), one or more physical drives (one or more physical drives in which the entities of the data logically stored in the pool are stored), a memory (memory for storing management information related to data, including information including a mapping between virtual volume addresses and pool addresses (e.g., a logical-physical conversion table 142)), and a processor connected to the memory. A processor of a first node (e.g., node #1) creates a third virtual volume (e.g., virtual volume #3 or Snapshot #N) in the first node by performing a virtual copy, which is a copy of the mapping between the virtual volume address and the pool address, on a first virtual volume (e.g., virtual volume #1) in the first node. A processor of a second node (e.g., node #2) performs mapping (external connection) from a first pool volume (e.g., pool volume #22) in the second node to a third virtual volume created in the first node. The processor of the second node associates the address of the first pool volume mapped (externally connected) to the third virtual volume with the address of the second virtual volume (e.g., virtual volume #2) in the second node on a one-to-one basis (performing straight mapping between the first pool volume and the second virtual volume). If the address of data to be written (specifically, for example, data written to the second virtual volume in response to a write request to the second node, or data read from the first node and written to the second virtual volume) is an address in the second virtual volume, the processor of the second node performs log structure writing of the data to the second pool volume in the second node (an example of a pool volume other than the first pool volume in the pool of the second node).Writing using the log structure method involves storing the updated data in a pool while leaving the pre-update data in the pool, and changing the mapping address of the address in the virtual volume from the address of the pre-update data to the address of the updated data.

[0232] The first node may be a node in the on-premises environment 40, and the second node may be a node in the public cloud environment 50. The third virtual volume may be a volume (e.g., Snapshot #M) that is a snapshot of the first virtual volume. A processor of the second node may perform a prefetch process in response to the prefetch instruction. The prefetch process may include prefetching data from the second virtual volume through an address in the first pool volume that is mapped to an address where the data in the third virtual volume is located, and writing the prefetched data to the second pool volume in a log structure manner.

[0233] The mapping from the first pool volume to the third virtual volume may be performed by changing the mapping destination of the first pool volume from a third virtual volume of an older generation than the third virtual volume (e.g., Snapshot #N) to the third virtual volume. The prefetch process may include identifying, from the first node, a differential location, which is an address of the third virtual volume where there is a difference in data between the third virtual volume of an older generation than the third virtual volume and the third virtual volume of an older generation. The prefetched data may be data obtained from the differential location.

[0234] The processor of the second node may invalidate data that was prefetched and written to the second pool volume in a previous prefetch process to make the data subject to garbage collection. The previous prefetch process may include prefetching data from an address in the older-generation third virtual volume where there is a data difference between the address and a third virtual volume (not shown) whose generation is older than the older-generation third virtual volume, and writing the prefetched data to the second pool volume using a log structure method.

[0235] When the processor of the second node receives a write request specifying a second virtual volume after the prefetch process, the processor may write the write data associated with the write request in a log structure manner to any pool volume other than the first pool volume (for example, the second pool volume) in the pool of the second node.

[0236] When the processor of the second node receives a read request specifying the second virtual volume after the prefetch process, it may determine, based on management information in the memory of the second node, in which node the data at the address specified in the read request is located. If the determined node is the second node, the processor of the second node may read the data from the address of the second pool volume mapped to the specified address. If the determined node is the first node, the processor of the second node may obtain the data from the third virtual volume of the first node through the address of the first pool volume mapped to the specified address. When the processor of the second node obtains the data from the first node in response to the read request, it may write the data in a log structure format to one of the pool volumes (e.g., the second pool volume).

[0237] The processor of the second node does not need to invalidate the data that was prefetched and written to the second pool volume in the previous prefetch process in order to subject the data to garbage collection.

[0238] In the prefetch process, the processor of the second node may invalidate the write data written to the second pool volume in response to a write request before the prefetch process in order to subject the write data to garbage collection. The management information in the memory of the second node may include, for each piece of data written to the second pool volume, information indicating whether the data is prefetched and written in the prefetch process in response to a prefetch instruction or write data written in response to a write request (e.g., host write data flag 1423). The processor of the second node may identify the write data written to the second pool volume in response to a write request before the prefetch process based on the management information, and invalidate the identified write data.

[0239] When a request is made to write write data to a second virtual volume created as a virtual clone of a first virtual volume, a processor of the second node may store the write data in a second pool volume separate from the first pool volume by writing using a log structure method, store the entity of the write data in a physical drive of the second node, and update the mapping so that the write data in the second virtual volume is linked to the write data stored in the second pool volume.

[0240] The management information held by each node may include logical-physical conversion data that manages the correspondence between the logical storage destination of data in the node itself and the physical storage destination of the data. When a virtual clone of the first virtual volume is created, the processor of the second node may set the physical storage destination of the data virtually held in the second virtual volume linked to the first pool volume to an invalid value in the logical-physical conversion data.

[0241] When a request is made to read read data from a second virtual volume created as a virtual clone, the processor of the second node may refer to the logical-physical conversion data of its own node and determine the node from which to read the read data based on whether the physical storage destination of the read data is the invalid value.

[0242] When a request is made to read read data from a second virtual volume created as a virtual clone, if the physical storage destination of the read data is an invalid value in the logical-physical conversion data of its own node, the processor of the second node may request the processor of the first node to read the read data from the third virtual volume mapped from the first pool volume, and the processor of the first node may obtain the entity of the read data requested to be read by the processor of the second node from the physical drive of the first node based on the logical-physical conversion data of its own node, and transfer it to the second node.

[0243] When a request is made to delete a second virtual volume created as a virtual clone of a first virtual volume, the processor of the second node may cancel the mapping from the first pool volume to the third virtual volume and cancel the association between the second virtual volume and the first pool volume, and the processor of the first node may delete the third virtual volume after canceling the mapping in the second node. When a request is made to delete a second virtual volume created as a virtual clone, the processor of the second node may further delete write data stored in a physical drive of its own node in response to a request to write write data to the second virtual volume.

[0244] After a second virtual volume is created as a virtual clone of the first virtual volume, if the load on the first node due to a data input / output request to the second node exceeds a predetermined threshold, the processor of the second node may obtain from the first node the entity of at least a portion of the data of the first pool volume linked to the second virtual volume, store the data in a physical drive of the second node, and then copy the data to a third pool volume different from the first pool volume, and update the management information so as to link the second virtual volume to the third pool volume for the data copied from the first pool volume to the third pool volume. When the processor of the second node obtains from the first node the entity of all of the data of the first pool volume linked to the second virtual volume and stores it in a physical drive of the second node, the processor may cancel the mapping from the first pool volume to the third virtual volume and cancel the link between the second virtual volume and the first pool volume.

[0245] When the storage system is configured to be connected to a cloud environment, the processor of the first node and a processor of a third node provided in the cloud environment may work together to execute a process that replaces the second virtual volume with a fourth virtual volume in the third node, thereby making it possible to create a virtual clone of the first virtual volume in the third node in the cloud environment. [Explanation of symbols]

[0246] 10, 10A, 10B Storage Systems

Claims

1. 1. A storage system having a plurality of nodes including a first node and a second node, Each of the nodes A virtual volume; a pool configured from one or more pool volumes, in which data addressed to an address of the virtual volume is logically stored at an address mapped to the address; one or more physical drives on which the entities of the data logically stored in the pool are stored; a memory for storing management information relating to data, the management information including mapping between addresses of the virtual volume and addresses of the pool; Processor and and a processor of the first node creates a third virtual volume in the first node by performing a virtual copy of the first virtual volume in the first node, the virtual copy being a copy of a mapping between a virtual volume address and a pool address; a processor of the second node, mapping a first pool volume in the second node to the third virtual volume created on the first node; Associating the address of the first pool volume mapped to the third virtual volume with the address of the second virtual volume in the second node. A storage system comprising:

2. When the first node has a first virtual volume and receives an instruction to create the second virtual volume, the first node creates a mapping from the second virtual volume, the third virtual volume, and the first pool volume to the third virtual volume.

2. The storage system according to claim 1.

3. If the address of the data to be written is an address in the second virtual volume, writing the data in a log structure format to a second pool volume in the second node; The log structure method write includes storing post-update data in a pool while leaving pre-update data in the pool, and changing a mapping destination address of an address in a virtual volume from the address of the pre-update data to the address of the post-update data.

2. The storage system according to claim 1.

4. the first node is a node in an on-premises environment; the second node is a node in a public cloud environment; The third virtual volume is a volume that is a snapshot of the first virtual volume.

2. The storage system according to claim 1.

5. a processor of the second node performs a prefetch process in response to the prefetch instruction; The prefetch process includes: Prefetching the data through an address in the first pool volume that is mapped to an address where the data in the third virtual volume is located in the second virtual volume; and Writing the prefetched data to the second pool volume Contains 2. The storage system according to claim 1.

6. the first node has a plurality of third virtual volumes that are virtual copies of the first virtual volume and each of the third virtual volumes has different data; when the third virtual volume at the mapping destination is changed among a plurality of third virtual volumes, the prefetch process includes identifying, from the first node, a difference position that is an address at which there is a difference in data between the third virtual volume at the mapping destination before the change and the third virtual volume at the mapping destination after the change; The prefetched data is data obtained from the differential location.

6. The storage system according to claim 5.

7. The processor of the second node invalidates the data before the prefetch that is located at the position where the data is prefetched based on the differential position, in order to subject the data to garbage collection.

4. The storage system according to claim 3.

8. The plurality of third virtual volumes are a plurality of snapshots of different generations.

7. The storage system according to claim 6.

9. a first node among a plurality of nodes constituting a storage system and including a first and second node performs a virtual copy of a first virtual volume in the first node, the virtual copy being a copy of a mapping between an address of the virtual volume and an address of a pool that is composed of one or more pool volumes and in which data to the address of the virtual volume is logically stored at an address mapped to the address, thereby creating a third virtual volume within the first node; the second node performs mapping from the first pool volume in the second node to the third virtual volume created in the first node; The second node associates the address of the first pool volume mapped to the third virtual volume with the address of the second virtual volume in the second node. A storage control method comprising:

Images