Storage System and Memory Control Method

Abstract

To suppress reduction in performance of a second volume in acquiring data in a first volume through the second volume without copying all data in the first volume in a first node to the second volume in a second node.SOLUTION: A first node generates a third virtual volume in the first node by copying (virtually copying) address mapping of a virtual volume and a pool to a first virtual volume. A second node performs mapping from a first pool volume in the second node to the third virtual volume in the first node, associates an address in the first pool volume mapped to the third virtual volume one-on-one with an address in a second virtual volume in the second node, and writes data in the second virtual volume in a log structure to a second pool volume in the second node.SELECTED DRAWING: Figure 26

Description

Technical Field

[0001] The present invention generally relates to memory control.

Background Art

[0002] For example, Patent Document 1 discloses a storage system capable of executing virtual copy by the RoW (Redirect on Write) method. The storage system of Patent Document 1 has a tree structure of first control information associated with a volume on a one-to-one basis and second control information for managing user data, and creates a copy of the volume at high speed by copying only the first control information.

Prior Art Documents

Patent Documents

[0003]

Patent Document 1

Summary of the Invention

Problems to be Solved by the Invention

[0004] By the way, in recent years, storage systems have been required to have a scale-out function that can expand performance and capacity as needed from a small-scale configuration. Specifically, the storage system is composed of a plurality of nodes (appliances), and it is possible to add or remove nodes.

[0005] In recent years, the need for data utilization has increased, and examples of data utilization include using data stored in a first environment in a second environment. Specifically, for example, data utilization includes using data stored in a production environment in work in a development environment or a test environment, or using data stored in a core business environment in a secondary utilization environment such as analysis.

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

[0007] As one method, it is conceivable to copy all the data stored in the first volume from the first node to the second node. However, in this method, the amount of data transferred between nodes is large, and the storage capacity of the second node is consumed significantly.

[0008] As another method, when data is required through the second volume, it is conceivable that the second node acquires the required data from the first node. However, in this method, data transfer between nodes is required every time data is needed, and the performance of the second volume deteriorates.

Means for Solving the Problem

[0009] The storage system has a plurality of nodes including a first node and a second node. Each node has a virtual volume, a pool composed of one or more pool volumes in which data is logically stored at an address to which the data is mapped from the address of the virtual volume, one or more physical drives in which the physical entities of the data logically stored in the pool are stored, a memory that stores management information regarding the data and includes information on the mapping between the address of the virtual volume and the address of the pool, and a processor connected to the memory. The processor of the first node creates a third virtual volume within the first node by performing, for a first virtual volume in the first node, a virtual copy that is a copy of the mapping between the address of the virtual volume and the address of the pool. The processor of the second node maps from a first pool volume in the second node to the third virtual volume created in the first node, associates one-to-one the address of the first pool volume mapped to the third virtual volume with the address of a second virtual volume in the second node, and when the address of the data to be written is the address in the second virtual volume, performs a log-structured write of the data to a second pool volume in the second node. The log-structured write includes storing updated data in the pool while leaving the pre-updated data in the pool, and changing the mapped address of the address in the virtual volume from the address of the pre-updated data to the address of the updated data.

Advantages of the Invention

[0010] According to the present invention, with respect to obtaining the data of the first volume through the second volume without copying all the data of the first volume in the first node to the second volume in the second node, it is possible to suppress a decrease in the performance of the second volume.

Brief Description of the Drawings

[0011]

Figure 1

Figure 2

Figure 3

Figure 4

Figure 5

Figure 6

Figure 7

Figure 8

Figure 9

Figure 10

Figure 11

Figure 12

Figure 13

Figure 14

Figure 15

Figure 16

Figure 17

Figure 18

Figure 19

Figure 20

Figure 21

Figure 22

Figure 23

Figure 24A

Figure 24B

Figure 25

Figure 26

Figure 27

Figure 28

Figure 29A

Figure 29B

Figure 30A

Figure 30B

Figure 31

Figure 32

Figure 33

Figure 34

Figure 35

Mode for Carrying Out 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 for the sake of clarity of explanation, omissions and simplifications are made as appropriate. Also, not all combinations of features described in the embodiments are essential for the solution means of the invention. The present invention is not limited to the embodiments, and all application examples that conform to the idea of the present invention are included in the technical scope of the present invention. Those skilled in the art can make various additions and changes within the scope of the present invention. The present invention can also be implemented in various other forms. Unless otherwise limited, each component may be plural or singular.

[0014] In the following description, various types of information may be described using expressions such as "table", "sheet", "list", "queue", etc. However, the various types of information may also be represented by data structures other than these. In order to indicate that it does not depend 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 with each other.

[0015] Also, in the following description, when describing without distinguishing between elements of the same type, reference signs or common numbers in the reference signs are used. When describing by distinguishing between elements of the same type, the reference signs of those elements may be used or IDs, identification numbers, etc. assigned to those elements may be used instead of the reference signs. For example, when describing "virtual volume 130" without particularly distinguishing it, it is described as "virtual volume 130", whereas when describing each individual virtual volume 130 separately, it may be described as "virtual volume #1", "virtual volume #2", etc.

[0016] Also, in the following description, there may be cases where the processing performed by executing a program is described. However, the program is executed by at least one or more processors (for example, a CPU) to perform the defined processing while appropriately using storage resources (for example, a memory) and / or interface devices (for example, a communication port), etc. Therefore, the main body of the processing may be considered to be the processor. Similarly, the main body of the processing performed by executing the program may be a controller, device, system, computer, node, storage system, storage device, server, management computer, client, or host having a processor. The main body of the processing performed by executing the program (for example, a processor) may include a hardware circuit that performs part or all of the processing. For example, the main body of the processing performed by executing the 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 according to the program. The device and system including the processor are devices and systems including these functional units.

[0017] The program may be installed from a program source into a device such as a computer. 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 non-transitory storage resources, and the storage resources may further store a distribution program and a program to be distributed. Then, by the processor of the program distribution server executing the distribution program, the processor of the program distribution server may distribute the program to be distributed to other computers. Also, in the following description, two or more programs may be implemented as one program, or one program may be implemented 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 the first embodiment of the present invention.

[0019] The storage system 10 (Storage System) is a storage system adopting a scale-out architecture of loose coupling, and includes a plurality of nodes 100 (e.g., Node#1, Node#2). As shown in FIG. 1, each node 100 has, as a logical configuration, a pool 110 (Pool), a pool volume 120 (Pool VOL), and a virtual volume 130 (Virtual VOL). A storage adopting a scale-out architecture of loose coupling has a scale-out function capable of expanding performance or capacity as needed from a small-scale configuration. A loose-coupling scale-out method in which a plurality of appliances (nodes 100) are clustered is mainstream, and it is assumed that the storage system 10 shown in FIG. 1 also adopts this scale-out method, but it is not limited thereto.

[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. Also, the virtual volume 130 is a virtual volume created from the pool 110, and the data of the virtual volume 130 is managed in units of pages 131 (Pages).

[0021] The virtual volume 130 is associated with the belonging pool (the source pool 110) by the volume management table 141 described later. Also, the page 131 has its allocated address managed by the page management table 143 described later. For example, in the case of FIG. 1, virtual volume #1 is associated with pool #1 that includes pool volume #11, and the "A" page 131 of virtual volume #1 is allocated to the "A" page 121 (Page) of pool volume #11.

[0022] FIG. 2 is a block diagram showing an example of the hardware configuration of the storage system 10. As also described in FIG. 1, the storage system 10 includes a plurality of nodes 100. The storage system 10 is connected to the production server 21 (Production Server) and the development / test server 22 (Dev / Test Server) via the storage network 31, and is connected to the management server 23 (Management Server) via the 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. The production server 21 and the development / test server 22, as hosts, send an I / O request (write request or read request) specifying 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 and control of the storage system 10 by the management server 23 is performed via the 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. Note that 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 (SSDs). 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 in FIG. 2, an SSD (Solid State Drive) is shown as an example of the physical drive 12, but the present invention is not limited thereto, and any device that physically stores data, such as an HDD (Hard Disk Drive), may be used.

[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 a program read from the memory 14. In the present embodiment, the processor 13 performs controls related to writing and reading of data, in addition to creating and deleting clones. The processor 13 is, for example, a CPU (Central Processing Unit), but the present invention is not limited thereto.

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

[0030] The front - end IF15 is a communication interface device that mediates the 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 via the storage network 31 from the front - end IF15.

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

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

[0033] Figure 3 is a diagram showing a configuration example of the memory 14 of the storage system 10, and shows an example of the 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] As shown in Figure 3, the memory 14 includes a control information section 140 that holds control data, a program section 150 that holds programs executed by the processor 13, and a memory area of a cache section 160 that serves as a cache. The program section 150 is a local memory used by the processor 13 (see Figure 2) belonging to the same set as the memory 14. On the other hand, the control information section 140 may be a shared memory that can be used not only by the processor 13 belonging to the same set as the memory 14 but also by the processor 13 belonging to other sets. At least one of the above - described memory areas may be an independent memory.

[0035] The control information unit 140 stores a volume management table 141, an object conversion table 142, a page management table 143, a pool management table 144, and an external volume management table 145. Configuration examples of each table are shown in FIGS. 4 to 8 described later.

[0036] The program unit 150 stores a clone creation program 151, a clone deletion program 152, a volume external connection program 153, a volume external connection release program 154, an in-node virtual copy creation program 155, a write program 156, and a read program 157. These programs are provided for each of the plurality of controllers 11 and cooperate with each other to perform the target processing. Details of the processing by each program will be described later.

[0037] The cache unit 160 temporarily stores data sets that are written to or read from the physical drive 12.

[0038] FIG. 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 a pool volume 120 and a virtual volume 130. The volume management table 141 has items of a volume ID 1411, a capacity 1412, a usage amount 1413, a volume type 1414, an affiliated pool 1415, a direct map 1416, and a corresponding pool volume ID 1417.

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

[0040] The volume type 1414 indicates the type of the volume. If the volume is a clone that is a virtual copy of a certain volume, "(Clone)" is indicated in its type. If the volume is an externally connected (externally attached) volume connected from a node different from its own node, "(External VOL)" is indicated in its type.

[0041] In addition, the "external connection (external attachment)" in this description means mapping from the virtual volume 130 of its own node to the data of another node. For this purpose, it also includes mapping the pool volume 120 to which the virtual volume 130 of the above-mentioned own node is associated and the virtual volume 130 that holds the data of the above-mentioned other node. More specifically, when trying 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 (the data of pool volume #11), the pool volume #22 to which the virtual volume #2 is associated and the virtual volume (in this example, not the virtual volume #1 that is the original of the virtual copy but the virtual volume #3 that is the in-node virtual copy of the virtual volume #1) that holds the data of pool volume #11 in node #1 are mapped. In this case, the pool volume #22 plays a role of relaying the mapping between the virtual volume 130 (virtual volume #2) of its own node and the virtual volume 130 (virtual volume #3) that holds the data of another node, and this pool volume #22 is referred to as an externally attached volume. The reason why the pool volume #22 is externally connected to the virtual volume #3 instead of the virtual volume #1 is to prevent data changes in the clone source node (node #1) after clone creation from affecting the virtual volume #2 at 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 it was created.

[0043] The 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 different from its own node (for example, in the case of an external connection described later), it is directly mapped and the direct map 1416 becomes "ON". Note that in the case of a virtual volume (virtual clone) generated by virtual-copying the virtual volume 130 within the same node, direct mapping is not performed and the direct map 1416 becomes "OFF".

[0044] The corresponding pool volume ID 1417 indicates the volume ID of the corresponding pool volume 120 when the volume is direct mapped "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 the logical address 1421 where the data is stored and the physical address 1422. In the present embodiment, since the data is processed in page units, the physical address 1422 in FIG. 5 is indicated by a page number. Note that when the value of the physical address 1422 is a valid value such as "0" or "2", it means that the data is stored within the own node that holds this logical-physical conversion table 142. On the other hand, when the value of the physical address 1422 is an invalid value (Invalid) such as "FFFFFFFF", the data is stored at the logical address 1421 of the straight-mapped pool volume 120 within the own node (the same address as the logical address 1421 of the accessed virtual volume). For example, when the accessed virtual volume is a clone, and it is straight-mapped to a pool volume, and the pool volume externally connects the virtual volume of the clone source node, it means that the entity of the data is stored in the clone source.

[0046] FIG. 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 items of page number 1431, pool volume ID 1432, start address 1433, status 1434, assigned volume ID 1435, and assigned 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 120 that stores the actual data of the page identified by the page number 1431 (hereinafter, the page). The start address 1433 indicates the start address of the actual data of the page stored in the pool volume ID 1432.

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

[0049] FIG. 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 items of pool ID 1441, capacity 1442, usage amount 1443, volume ID 1444, attribute 1445, and external volume ID 1446.

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

[0051] Volume ID 1444 indicates the volume ID of pool volume 120 belonging to the pool. Attribute 1445 indicates whether the physical data of the volume identified by volume ID 1444 exists in the pool (own node) (Internal), or whether the physical data of the volume exists in another pool (another node) (External). Specifically, when the volume is an "External VOL (External Volume)" that externally connects to the virtual volume 130 of another node, its attribute 1445 becomes "External". And external volume ID 1446 indicates the identifier of the external volume when attribute 1445 is "External".

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

[0053] External volume ID 1451 indicates the identifier assigned to the external volume in the own node. The external volume ID 1446 in the pool management table 144 shown in Figure 8 corresponds to the external volume ID 1451.

[0054] Connection node ID 1452 indicates the node ID of the source node to which the external volume (hereinafter, the external volume) identified by external volume ID 1451 is connected. The node ID is an identifier that can uniquely identify each of the plurality of nodes 100 constituting the storage system 10. Port ID 1453 indicates the identifier of the port of the own node to which the external volume is connected, and target device ID 1454 indicates the identifier of the target device that holds the physical data of the external volume in the source node. (1-3) Processing

[0055] Hereinafter, as processes executed by the storage system 10 according to the present embodiment, a "clone creation process" for creating a clone of a volume (virtual volume 130), a "write process" executed in response to a write request to the clone, a "read process" executed in response to a read request to the clone, and a "clone deletion process" for deleting the clone will be described in detail. (1-3-1) Clone creation process

[0056] FIG. 9 is a diagram showing a processing image of the clone creation process. On the upper side of FIG. 9, a processing image when a clone creation of a volume is instructed from a host with a different node as a creation destination is shown, and on the lower side of FIG. 9, a processing image during the subsequent clone creation process is shown. FIG. 10 is a flowchart showing an example of the processing procedure of the clone creation process. Hereinafter, the processing procedure of the clone creation process will be described along the flowchart of FIG. 10 while appropriately indicating the corresponding parts in FIG. 9.

[0057] The clone creation process starts when a "clone instruction" to create a clone of the virtual volume 130 accessible from its own server at a predetermined node 100 is transmitted from a host (for example, the production server 21, but it may also be the management server 23, etc.) to the storage system 10 and the node 100 of the clone source receives this.

[0058] As described in the problems to be solved by the invention, in the prior art, in a storage system adopting a loosely coupled scale-out architecture in which a plurality of nodes are clustered, the destination for creating a clone of a volume was limited to the same node as the volume. In contrast, the storage system 10 according to the present embodiment can also specify a node different from the volume as the destination for creating a clone of the volume. Although details will be described later, when the latter clone instruction is given, a virtual clone of the volume (virtual volume 130) is created across the node 100 by executing the clone creation process. Also, the clone instruction can be requested by the development / test server 22, but the processing procedure of the clone creation process in that case is the same as when the production server 21 requests the clone instruction, so the description thereof is omitted.

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

[0060] At this time, in the controller 11 of the node #1, which is the source of the clone instruction and has received the instruction, the processor 13 starts the clone creation program 151 and executes the clone creation process. Hereinafter, the started program will be described as the processing subject. The same applies to other processes described later.

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

[0062] Next, the clone creation program 151 calls the in-node virtual copy creation program 155 to execute the in-node virtual copy creation process, thereby creating a virtual copy of the volume of the clone source within the same node as the clone source (step S102). This process corresponds to the " (2) In-node virtual copy creation " shown in FIG. 9. Inside node #1, a virtual volume #3, which is a clone of the virtual volume #1, is created.

[0063] FIG. 11 is a flowchart showing an example of the processing procedure of the in-node virtual copy creation process. The in-node virtual copy creation process shown in FIG. 11 corresponds to the process of step S102 in FIG. 10 and is executed by the in-node virtual copy creation program 155 of the clone source node (for example, node #1). In this description, the creation of a virtual copy within the same node is referred to as a copy.

[0064] According to FIG. 11, first, the in-node virtual copy creation program 155 checks whether there is dirty data in the volume of the copy source (virtual volume #1) (step S201). Dirty data is a 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 is omitted. If dirty data exists (YES in step S201), the process proceeds to step S202. If dirty data does not exist (NO in step S201), the process proceeds to step S205.

[0065] In step S202, the in-node virtual copy creation program 155 takes data consistency between the control information unit 140 and the cache unit 160 based on the dirty data, allocates a page for storing the dirty data of the copy source virtual volume, and updates the page management table 143.

[0066] Next, the in-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 physical object conversion table 142 regarding the destaging (step S204).

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

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

[0069] Returning to the description of FIG. 10. After the end of the in-node virtual copy creation process, the clone creation program 151 checks whether the source node 100 of the clone and the destination node 100 of the clone match based on the node ID received in step S101 (step S103).

[0070] If the nodes match between the source of the clone and the destination of the clone in step S103 (YES in step S103), it means that the destination of the clone specified by 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 attributes of the in-node virtual copy in the volume management table 141, and ends the clone creation process.

[0071] On the other hand, if the nodes do not match between the clone source and the clone destination in step S103 (NO in step S103), it means that the clone destination specified by 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 sends a request for external volume connection to the controller 11 of the clone destination node. At the clone destination node, the controller 11 that has received the request starts the external volume connection program 153 from its own memory 14 to execute the external volume connection process, thereby externally connecting the in-node virtual copy created in the in-node virtual copy creation process of step S102 to the pool volume 120 of the clone destination node. This process corresponds to the “(3) External VOL connection (import into Pool VOL)” shown in FIG. 9, and the virtual volume #3 created at node #1 is externally connected to the 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 of the external volume connection process. The external volume connection process shown in FIG. 12 corresponds to the process of step S104 in FIG. 10 and is executed by the external volume connection program 153 of the clone destination node (for example, node #2).

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

[0075] Next, the external volume 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 creates and updates a record for any pool volume (e.g., pool volume #22) created in pool #2 identified in step S302 in the external volume management table 145, thereby adding the externally connected external volume (pool volume #22) from the clone source node to its own node (step S303).

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

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

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

[0080] Returning to the description of FIG. 10. After the volume external connection process ends, 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 process 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 external volume to the corresponding pool volume ID 1417 of the record.

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

[0082] The processes of steps S105 to S106 described above correspond to "(4) Associating Virtual VOL and Pool VOL" shown in FIG. 9. In the clone destination node (node #2), the pages in the clone destination volume (virtual volume #2) mapped to the data of the in-node virtual copy (virtual volume #3) and the pages in the externally connected volume (pool volume #22) to which the in-node virtual copy (virtual volume #3) is externally connected are associated one-to-one.

[0083] Next, the clone creation program 151 initializes the 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 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 creation program 151 updates the attributes in the volume management table 141 (step S109) and ends the clone creation process.

[0085] By performing the clone creation process as described above, the storage system 10 according to the present embodiment can create a virtual clone of a volume in a form that spans nodes (between different nodes 100) even under the constraint in the architecture of loosely coupled scale-out that the copy destination and the copy source of the virtual copy must be the same node. (1-3-2) Write process

[0086] FIG. 13 is a diagram showing a processing image of the write process. Above FIG. 13, a processing image when write data is transferred by a write request from a host to a virtual clone (the virtual volume 130 at the clone destination) is shown, and below FIG. 9, a processing image during the subsequent write process is shown. FIG. 14 is a flowchart showing an example of the processing procedure of the write process on the front-end side, and FIG. 15 is a flowchart showing an example of the processing procedure of the write process 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 process shown in FIG. 14 and the write process shown in FIG. 15 in parallel. Hereinafter, the processing procedure of the write process will be described along the flowcharts of FIGS. 14 and 15 while appropriately indicating the corresponding parts in FIG. 13.

[0087] When a write request for writing data to a volume of the storage system 10 is made from a host (the production server 21, the development / test server 22, or the management server 23), in the controller 11 of the node 100 that has the volume to be written to, the processor 13 starts 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] In FIG. 13, in the “(1) Write Data transfer”, a write request for virtual volume #2 is made from the development / test server 22, and write data 132 called “C” is being transferred. Here, virtual volume #2 is a virtual clone created on node #2 different from the clone source node by the clone creation process as described above with reference to FIGS. 9 to 12.

[0089] When receiving the write request, in the front end, as shown in FIG. 14, the write program 156 first checks (step S401) whether a cache area for the write destination address is 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 a cache hit occurs). 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] Then, the write program 156 returns a normal response (Good response) to the host for the write request (step S404) and ends the write process in the front end.

[0091] When receiving the write request, in the back end, as shown in FIG. 15, the write program 156 first checks (step S501) whether there is dirty data in the write destination volume (virtual volume #2). If there is dirty data (YES in step S501), it proceeds to step S502, and if there is no dirty data (NO in step S501), the process ends.

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

[0093] Here, as one of the features of the storage system 10, for a write request to 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 same node (node #2) performs write of write data in a log-structured manner (so-called "append write") within the node itself. Note that even when there is a write request to a virtual volume 130 other than the virtual clone, the write program 156 may perform append write in the same manner.

[0094] In the write (append write) in the log-structured manner, the pool 110 (pool volume 120) holds the historical data (pre-update data) updated by the write data 132. Specifically, when a write request is made for the existing data of the virtual volume 130, the write program 156 writes the write data (post-update data) separately to the pool volume 120 that is not an external volume while keeping the existing data (pre-update data) in the pool volume 120, and then updates 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 update in the virtual volume 130 is performed, and the historical pre-update data is held in the pool 110 (pool volume 120). Also, when a write request for new data is made to the virtual volume 130, since there is no pre-update data in the pool volume 120 associated with the virtual volume 130, the write program 156 writes the write data to the pool volume 120 that is not an external volume and performs mapping from the virtual volume 130 to the pool volume 120 for the write data.

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

[0096] Such appending is shown as "(2) Log Structured Write" in FIG. 13, and it can be seen that pool volume #21 is the storage destination of the above-mentioned write data (page "C"), and page "C" of pool volume #21 is assigned to page "C" of virtual volume #2. In addition, if the write request for write data 132 is to update page "A" of virtual volume #2, on the lower side 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, so that page "A" of virtual volume #2 is updated to page "C".

[0097] After that, the write program 156 destages the dirty data (step S503), updates the parity conversion table 142 regarding destaging (step S504), and ends the process.

[0098] As described above, by executing the write process, in the storage system 10, when writing data to the clone destination volume (virtual volume #2) across node 100, the write data is appended within the clone destination node (node #2). As a result, a write operation on the virtual clone can be performed without imposing a load or impact on the clone source node (node #1). (1-3-3) Read Process

[0099] FIG. 16 is a diagram showing a processing image of read processing. Above FIG. 16, when a read request for data stored in the clone destination node is made from the host to the virtual clone (virtual volume 130 at the clone destination) (that is, when the destination volume of the read request and the storage destination of the actual entity of the read data are the same node), the processing image of the read processing is shown. Below FIG. 16, when a read request for data stored in the clone source node is made from the host to the virtual clone (virtual volume 130 at the clone destination) (that is, when the destination volume of the read request and the storage destination of the actual entity of the read data are different nodes), the processing image of the read processing is shown. Also, FIG. 17 is a flowchart showing an example of the processing procedure of the read processing. Hereinafter, the processing procedure of the read processing will be described along the flowchart of FIG. 17 while appropriately indicating the corresponding parts in FIG. 16.

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

[0101] According to FIG. 17, first, the read program 157 receives the read request (step S601). In the case of the upper side of FIG. 16, in the "(1) Read request", a read request for page "C" is made to the virtual volume #2 which is the virtual clone at the clone destination. Also, in the case of the lower side of FIG. 16, in the "(1) Read request", a read request for page "A" is made to the virtual volume #2 which is the virtual clone at 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 results in a cache hit (Hit in step S602), the cached data is transferred to the host (step S608), and the read process ends. On the other hand, if the read data results in 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 of the object conversion table 142. Then, the read program 157 checks whether 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. 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] Here, as described above with reference to FIG. 5, in the object conversion table 142, when data is not stored within the own node (specifically, for example, when data is stored in another node that is the clone source), 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 upper case in FIG. 16), since page "C" is stored in node #2 which is the own node, 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 lower case in FIG. 16), since page "A" is stored in node #1 which is the clone source node, an invalid value is indicated in the physical address 1422.

[0105] That is, when the entity of the read data is stored in the own node (the upper case in FIG. 16), the process proceeds from step S604 to step S607. When the entity of the read data is not stored in the own node (the lower case in FIG. 16), the process proceeds from step S604 to step S605.

[0106] First, when explaining the case of 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) in 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 shown as "(2) Transfer from another node" on the lower side of FIG. 16. Specifically, as shown by the thick arrow on the lower side of FIG. 16, the page "A" in the pool volume #11 of node #1, which is the clone source node, is requested to be read as the data at the same address via the virtual volume #3 of the clone externally connected to the pool volume #22 identified in step S605. The actual data of the page "A" is read from the physical drive 12 storing the actual data of the page "A" and transferred to the cache unit 160 of node #2.

[0108] After the process 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 process.

[0109] On the other hand, when proceeding 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 shown as "(2) Transfer from own node" in the upper part of FIG. 16. Specifically, as shown 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 the pool volume #21, and the actual data of this page "C" is read from the physical drive 12 storing the actual data of page "C" and transferred to the cache unit 160.

[0110] After the process 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 process.

[0111] As described above, when the read process is executed, if a valid value is set in the mapping information (logical-physical conversion table 142), the storage system 10 reads and responds to read data from its own node. On the other hand, if an invalid value is set in the mapping information (logical-physical conversion table 142), it is determined that there is read data in another node (clone source node), and the data can be read from the clone source node via the external volume and responded to. (1-3-4) Clone deletion process

[0112] FIG. 18 is a diagram showing the processing image of the clone deletion process. In the upper part of FIG. 18, the processing image when clone deletion is instructed from the host to the virtual clone (the virtual volume 130 at the clone destination) is shown, and in the lower part of FIG. 18, the processing image during the subsequent clone deletion process is shown. FIG. 19 is a flowchart showing an example of the processing procedure of the clone deletion process. Hereinafter, the processing procedure of the clone deletion process will be described along the flowchart of FIG. 19 while appropriately indicating the corresponding parts in FIG. 18.

[0113] The clone deletion process starts when a "clone deletion instruction" is sent from a host (e.g., development / test server 22, but it could also be a management server 23, etc.) to request the deletion of a virtual clone, and the target node 100 of the clone receives this instruction.

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

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

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

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

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

[0119] FIG. 20 is a flowchart showing an example of the processing procedure of the external volume connection release process. The external volume connection process shown in FIG. 12 corresponds to the process of step S702 in FIG. 19 and is executed by the external volume connection release program 154.

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

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

[0122] Note that the process of step S802 corresponds to the " (2) External VOL release" shown in FIG. 18.

[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 external volume connection release program 154 deletes the record associating the volume to be deleted (virtual volume #2) and the external volume (pool volume #22) in the pool management table 144, thereby deleting 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 ends the external volume connection release process.

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

[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 description of FIG. 19. After the external volume connection release process ends, the clone deletion program 152 updates the volume management table 141 according to the processing results (deletion of the external volume and release of the external connection association) performed in step S702 (step S703). Specifically, the clone deletion program 152 deletes the record of the external volume (Pool Volume #22) in 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 external volume (Pool Volume #22) set in the corresponding pool volume ID 1417 of the record.

[0127] Next, the clone deletion program 152 requests the controller 11 of the clone source node (Node #1) to delete the in-node virtual copy (Virtual Volume #3) (step S704). In the clone source node, the in-node virtual copy creation program 155 is called to delete the requested in-node virtual copy. The process of deleting the in-node virtual copy can be easily implemented by referring to the example of the processing procedure of the in-node virtual copy creation process shown in FIG. 11, so a detailed description is omitted. This process corresponds to "(4) Delete the in-node virtual copy" shown in FIG. 18.

[0128] When the processing up to step S704 ends or it is determined as 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 allocated logical address 1436 of the page in the page management table 143 for the page of "old data" in the volume to be deleted (virtual volume #2) to unallocated "-".

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

[0131] The processing of steps S705 to S707 described above corresponds to "(5) Virtual VOL deletion" shown in FIG. 18.

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

[0133] Also, as a modification of the clone deletion process, after deleting the virtual clone, the clone deletion program 152 may perform a process of deleting the data of the clone destination node (node #2) appended after the generation of the virtual clone, asynchronously with the series of processes for deleting the virtual clone. According to such a modification, since the appended data that has become useless data with no chance of being used due to the deletion of the virtual clone can be deleted, the capacity can be increased.

[0134] As described above, even under the constraint that "the copy destination and the copy source of the virtual copy are limited to the same node" in the loosely coupled scale-out architecture in which a plurality of nodes are clustered, the storage system 10 according to the present embodiment can, by executing the clone creation process shown in FIG. 10, externally connect a virtual copy of the clone source volume from the clone destination and associate it with the virtual volume of the clone destination, thereby creating a virtual clone of the volume on a node different from the clone source. As a result, the usability of the storage system 10 is improved. Further, when creating a virtual clone across nodes, since there is no copy of the data body (physical data) between the nodes, the clone creation can be completed instantaneously, so that the user can immediately perform an IO (input / output) operation on the volume of the clone destination, and the effect of improving the agility of the business can be obtained.

[0135] Further, the storage system 10 according to the present embodiment separates the data storage destination before and after the generation of the clone. When a write of data is requested for a virtual clone created on a node different from the clone source node, by executing the write process shown in FIGS. 14 and 15 and storing the write data by appending it to the clone destination node, free data writing can be performed on the virtual clone without affecting the data in the clone source node. Further, for data writing, which has a higher load than data reading, since it is not performed on the clone source node via an external connection across nodes, an increase in the load on the clone source node can be suppressed.

[0136] Further, when reading data from the virtual clone, the storage system 10 according to the present embodiment can, by executing the read process shown in FIG. 17, when the physical data is not stored in the clone destination, read the data from the clone source node via an external connection and respond, thereby realizing data reading equivalent to that of the clone source volume in the virtual clone. (2) Second Embodiment

[0137] In the first embodiment, when creating a virtual clone on a node different from the clone source, it was assumed that there would be no copy of the physical data between the nodes. However, since data transfer from the clone source node can 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 considering 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 the storage system 10A according to the second embodiment of the present invention. The upper part of FIG. 21 shows the processing image of the first half of the rebalancing processing described later, and the lower part of FIG. 21 shows the processing image of the second half of the rebalancing processing. Further, as is clear from comparing FIG. 21 with FIG. 1, since the system configuration of the storage system 10A according to the second embodiment is the same as the system configuration of the storage system 10 according to the first embodiment, the same reference numerals are given and the description is omitted.

[0139] When the load on the clone source node (node #1) exceeds a predetermined threshold due to a read IO to the volume of the clone destination node (node #2), the storage system 10A notifies the host of the clone destination node, i.e., the development / test server 22 (or the management server 23), that it is overloaded. When a "data transfer instruction" described later is issued from the host to the clone destination node in response to this notification, the processor 13 of the controller 11 of the clone destination node starts a rebalancing program (not shown) from the memory 14 and executes rebalancing processing for the purpose of performance rebalancing. Note that the execution program of the rebalancing processing is not limited to the independent rebalancing program as described above, and part or all of it may be executed by other programs stored in the memory 14.

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

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

[0142] In the case of FIG. 21, for example, assume that, due to a data transfer instruction, all the old data of the clone source node externally connected from the external volume (pool volume #22) (i.e., the entire clone source volume) is instructed to be the target of data transfer. Triggered by the reception of this data transfer instruction, the rebalancing program executes rebalancing processing.

[0143] When starting the rebalancing process, the rebalancing program copies all the data held by the external volume (pool volume #22) (for example, including page "A", etc.) to the pool volume 120 (hereinafter referred to as the internal pool volume, specifically, for example, pool volume #21) in its own node that is not externally connected (step (2) in FIG. 21). In the case of FIG. 21, page "A" of pool volume #22 is copied to the area of page "B" of pool volume #21, which is the internal pool volume. Also, in this data copy, the physical data is also copied from the clone source node (node #1) of the external connection destination to its own node (node #2) and stored in the physical drive 12 of node #2.

[0144] Next, based on the data copy, the rebalancing program updates the logical object conversion table 142 and the page management table 143 so that the page (for example, page "A") corresponding to the old data of the virtual clone (virtual volume #2) refers to the corresponding page (for example, page "B") of the internal pool volume (pool volume #21) that is the data copy destination, and makes an assignment (step (3) in FIG. 21).

[0145] When the data instructed to be the target of data transfer is the entire old data, after the copy of the entire old data is completed, the rebalancing program starts the volume external connection release program 154 to perform the external connection release process, thereby releasing the external connection of the external volume (Figure 21(4)), and releasing the association between the virtual clone (virtual volume #2) and the external volume (pool volume #22) (Figure 21(5)). The detailed processing procedures of Figure 21(4)-(5) are the same as the processing procedures shown in Figure 20. Note that when the data instructed to be the target of data transfer is a part of the old data, the external connection is not released.

[0146] When the processing up to Figure 21(5) is completed, the entities of all the data of the clone destination node will be stored in its own node (node #2).

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

[0148] As described above, in the storage system 10A, by executing the rebalancing process according to the IO situation, without stopping the IO to the clone destination node (continuously), the old data read from the clone source node can be copied to its own node for each physical data. As a result, even when 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 that no data transfer occurs from the clone source node, and a performance rebalancing that suppresses the load on the clone source node can be realized.

[0149] In the above description, the entire old data (the entire externally connected volume) is targeted for data copying. However, the target of data copying in the present embodiment is not limited to this, and for example, data copying may be performed in units of predetermined pages. However, in any case, the target area for data copying includes at least the data to be read from the old data. For example, when an excessive load is applied to the entire volume at the clone source node during a read I / O, the entire volume may be targeted for data copying. When an excessive load is applied in page units, the corresponding page may be targeted for data copying.

[0150] Also, for the determination of whether to issue a data transfer instruction, a known method for determining overload may be adopted. For example, the determination of data transfer does not necessarily have to be based on a single read request, and it may be determined by exceeding a load threshold based on the results of multiple read requests. Also, the timing for issuing a data transfer instruction does not have to be a timing associated with a read request as long as it is after at least one or more read requests.

[0151] Also, when the data copied by the data transfer instruction is common data, since the data is notified to both the copy source and the copy destination, that is, both the clone source node and the clone destination node, the consumption capacity of the entire storage system 10A doubles, but the effect of reducing the load during I / O processing can be expected. Also, when the data copied by the data transfer instruction is unique data that is only used at the clone destination, since the data may be deleted at the copy source, that is, the clone source node, it is possible to expect a reduction in the load at the clone source node while maintaining the consumption capacity of the entire storage system 10A. (3) Third Embodiment

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

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

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

[0155] In the public cloud environment 50, the development / test server 22, the management server 23, and the SDS 51 composed of one or more nodes 500 are connected to each other via a network, and are further connected to the on-premises environment 40 side. 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 shown in the first embodiment.

[0156] The SDS 51 composed of one or more nodes 500 that is 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 the same storage function as the controller 11 of the node 100 in the on-premises environment 40, and in the node 500 of the public cloud environment 50, various programs can be called and executed in the same manner as the controller 11 of the on-premises environment 40. And one of the features of the storage system 10B according to the present embodiment is that a virtual copy of a virtual volume created in the node 100 of the storage system 10B can also be created in the node 500 on the public cloud environment 50 side.

[0157] FIG. 23 is a diagram showing a processing image of the clone creation process from the storage system 10B to the SDS 51. On the upper side of FIG. 23, a processing image is shown when clone creation is instructed for a predetermined volume (for example, virtual volume #1) in the node 100 (for example, node #1) in the on-premises environment 40 with the node 500 (for example, node #2) in the public cloud environment 50 as the creation destination, and on the lower side of FIG. 23, a processing image during the subsequent clone creation process is shown.

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

[0159] Referring to FIG. 23 and explaining the overview, first, for a predetermined volume (virtual volume #1) of node #1, a clone instruction is issued to create a clone thereof in node 500 of the public cloud environment 50 (FIG. 23(1)).

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

[0161] Next, the clone creation program 151 of the clone source node sends a request for external volume connection to the SDS 51 of the clone destination node (node #2), and the SDS 51 starts the external volume connection program 153 in its own node to execute the external volume connection process, thereby externally connecting the in-node virtual copy (virtual volume #3) created in the in-node virtual copy creation process to the pool volume (pool volume #22) of the clone destination node (FIG. 23(3)). The process in FIG. 23(3) is different from the process in the first embodiment in that the SDS 51 controls the process at the clone destination node, but the content of the process is the same as that in 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) and the pages in the externally connected volume (pool volume #22) externally connected to the in-node virtual copy (virtual volume #3) one-to-one (FIG. 23(4)).

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

[0164] Also, although detailed description is omitted, the storage system 10B according to the third embodiment can also execute various processes of storage operations (write process, read process, clone deletion process) described in the first embodiment in addition to the above-described clone creation process. Further, as described in the second embodiment, the storage system 10B according to the third embodiment can also copy data with physical data to a clone destination node for part or all of the old data. Therefore, such a storage system 10B can be applied to the storage systems 10 and 10A according to the first or second embodiment for secondary use in the cloud space. (4) Fourth Embodiment

[0165] In the third embodiment, an example of virtually creating a copy of a volume in an environment where the storage system 10B is deployed on-premise and the SDS 51 is deployed in the cloud (for example, a public cloud) was described. In the fourth embodiment, an example of prefetching (reading ahead) data of the storage system 10B from the SDS 51 in an environment combining the storage system 10B in the on-premise environment 40 and the SDS 51 in the public cloud environment 50, similar to the third embodiment, will be described.

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

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

[0168] When the on-premises storage system 10B performs operations other than core business, such as ad-hoc analysis operations and monthly batch processing operations, the load on the storage system 10B increases rapidly, which may impair the stable operation of core business in terms of performance and the like.

[0169] FIG. 24B shows a configuration for improving this problem. The production server 21 is connected to the on-premises storage system 10B of the on-premises 40, and the application server 24 is connected to the SDS 51 in the public cloud environment 50. A system including the storage system 10B and the SDS 51 is an example of a storage system having a plurality of nodes including first and second nodes. Node #1 (node 100) is an example of the first node, virtual volume #1 (virtual volume 130) is an example of the first virtual volume, and the production server 21 is an example of the host of the first node (the 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 the second node, virtual volume #2 (virtual volume 130) is an example of the second virtual volume, and the application server 24 is an example of the host of the second node (the source that sends a read request or a write request specifying the address of the second virtual volume). Also, pool volume #22 (external volume 120) is an example of the first pool volume, and pool volume #21 is an example of the 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 the snapshot 133 created in the storage system 10B of the on-premises environment 40. Similar to the third embodiment, an external connection function is used to access the data of 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) in the same procedure as the flow of FIG. 12. Also, the volume management table 141 is updated so as to perform a straight mapping (1:1 address association) between the virtual volume #2 directly accessible from the application server 24 and the external volume 120. That is, in S305 of 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 described above, it becomes possible to access the data in the storage system 10B in the on-premises environment 40 from the SDS 51 in the public cloud environment 50.

[0171] Before performing the ad hoc analysis and monthly batch processing, the data to be accessed in advance is transferred (prefetched) from the storage system 10B to the SDS 51. Thereby, the storage system 10B in the on-premises environment 40 is not affected by the sudden increase in the load of the ad hoc analysis and monthly batch processing, and stable operation of the core business can be realized. Also, by prefetching to the SDS 51, it becomes unnecessary to access the data from the storage system 10B in the on-premises environment 40 that is physically far from the SDS 51, which contributes to shortening the processing time of the ad hoc analysis and monthly batch processing, that is, suppressing the performance degradation of the virtual volume #2.

[0172] FIG. 25 is a diagram showing a configuration example of the memory 14 of the storage system 10B and the SDS 51, similar to FIG. 3, and is a diagram showing an example of 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 the prefetch processing program 158 and the snapshot scheduler program 159 are stored in the program section 150. Details of the processing by each program will be described later.

[0173] FIG. 26 is a diagram showing a processing image of a process of prefetching data of the snapshot 133 of the storage system 10B from the SDS 51 before the ad hoc analysis and the monthly batch processing. Further, FIG. 27 is a flowchart showing an example of a processing procedure of the prefetch processing. On the upper side of FIG. 26, a processing image when an instruction to prefetch data of a predetermined snapshot 133 (for example, Snasphot#M) in the node 100 (for example, node #1) in the on-premises environment 40 to the node 500 (for example, node #2) in the public cloud environment 50 is shown, and on the lower side of FIG. 26, a processing image during the subsequent prefetch processing is shown. Also, in the following description, "storage system 10B" may be read as "node #1", and "SDS 51" may be read as "node #2".

[0174] Next, while appropriately indicating the corresponding parts in FIG. 26, the processing procedure of the prefetch process will be described along the flowchart of FIG. 27. First, in step S2701 of FIG. 27, the management server 23 issues a prefetch instruction to the SDS 51. Specifically, an instruction is given to prefetch the data of a predetermined snapshot 133 (Snapshot#M) of node #1 to the node 500 in the public cloud environment 50. This is the process corresponding to (S2601) in FIG. 26. In the prefetch instruction, in addition to Snapshot#M (for example, the current generation number) which is the target of the current ad hoc analysis / monthly batch process, Snapshot#N (for example, the previous generation number) which was the target of the previous ad hoc analysis / monthly batch process may be specified. The management server 23 may exist in the on-premises environment 40 instead of the public cloud environment 50, or may exist in an environment different from those environments 40 and 50.

[0175] Next, in step S2702, the SDS 51 executes a connection destination switching process for the external volume 120 (pool volume #22). That is, the prefetch processing program 158 of node #2 switches the external connection destination snapshot. Before the prefetch instruction, the external volume 120 of the SDS 51 was connected to Snapshot#N of the storage system 10B, but by this switching process, the connection destination of the external volume 120 is changed to Snapshot#M. This is the process corresponding to (S2602) in FIG. 26. This external connection destination switching process of the external volume is performed by the same process as step S303 in FIG. 12. That is, in S303 in FIG. 12, the entry of the self-external 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 described above, access from the SDS 51 in the public cloud environment 50 to Snapshot#M in the storage system 10B in the on-premises environment 40 becomes possible.

[0176] Next, in step S2703, the prefetch processing program 158 of the SDS 51 initializes the physical conversion table 142 of the virtual volume 130 accessed by the application server 24. By this initialization process, the data prefetched into the SDS 51 by the previous prefetch process becomes a target for invalidation (a target for garbage collection). For example, when the Snpashot#N before switching was the target of non-standard analysis / monthly batch processing, data A and data B of page 131 (address) of Snapshot#N were prefetched into the SDS 51, but by this processing, data A and data B become targets for invalidation. This is the process corresponding to (S2603) in FIG. 26. Note that the invalidated data is deleted by garbage collection, and the remaining data is packed so that, as a result, the remaining data may exist in a continuous 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 the difference position information (information representing the difference position) between Snpashot#N before external connection switching and Snapshot#M after external connection switching. This is the process corresponding to (S2604) in FIG. 26. Note that the difference position between Snpashot#N and Snapshot#M is the address where there is a difference in data between Snapshot#M and Snpashot#N among Snapshot#M. Snapshot#M is an example of a third virtual volume, and Snpashot#N is an example of a third virtual volume of an older generation (for example, the immediately previous generation) than the third virtual volume.

[0178] Next, in step S2705, the prefetch processing program 158 of the storage system 10B creates the differential position information between Snapshot#N and Snapshot#M in response to the differential position information acquisition instruction from the SDS51, and responds to the SDS51 with the created differential position information. This is the process corresponding to (S2605) in FIG. 26. In the example of FIG. 26, the differential position between Snapshot#N and Snpashot#M is the position of the data C on page 131 of Snapshot#M. Since the position of the data B has not been updated from Snapshot#N, it is not a differential position.

[0179] Next, in step S2706, the prefetch processing program 158 of the SDS51 reads the data C from the position (differential position) of the data C on page 131. That is, the data C is transferred from the storage system (block storage) 10B to the SDS51. This corresponds to the process of (S2606) in FIG. 26. The read process will be described in detail later with reference to FIGS. 30 and 31, but the data is read from the differential position specified for the virtual volume #2. Since the virtual volume #2 is directly mapped to the pool volume #22 (external volume 120), the differential position to be read is also the same position in the pool volume #22 as in the virtual volume #2. Furthermore, the pool volume #22 reads the data C (data C in FIG. 26) on page 131 at the differential position of the external Snapshot#M. As described above, the differential position (address of the position of the differential data) specified for Snapshot#M is the same for the virtual volume #2 and the pool volume #22, and the data is read from Snapshot#M through the pool volume #22 to the virtual volume #2 at this position.

[0180] Next, in step S2707, the prefetch processing program 158 of the SDS51 stores the read data in its own pool #2 of the SDS51. This is the process corresponding to (S2607) in FIG. 26. Specifically, the prefetch processing program 158 stores the data in a pool volume other than the external volume (pool volume #22) within pool #2 (additional writing). According to the example shown in FIG. 26, data C is stored in pool volume #21 other than the external volume, and the physical conversion table 142 is updated so that data C stored in page 121 of pool volume #21 is referenced from virtual volume #2.

[0181] Next, in step S2708, the prefetch processing program 158 of the SDS51 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 process, the updated portion from the data to be processed in the previous ad-hoc analysis / monthly batch, specifically, the data C illustrated in FIG. 26, can be prefetched to the SDS51. After that, in response to a request from the application server 24, the SDS51 performs data I / O processing. However, the application server 24 is highly likely to access data C, which is the updated portion from the previous processed data. Since data C has been transferred to the SDS51 by the prefetch processing, it becomes possible to access it at high speed.

[0183] FIG. 28 is a diagram showing a processing image of a write process to the virtual volume 130 of SDS51. A write request from the application server 24 to the virtual volume 130 transfers write data to SDS51, and then an image in which SDS51 stores it in the pool 110 is shown in FIG. 28. FIG. 29A shows a flowchart showing an example of a processing procedure of a write process on the front-end side, and FIG. 29B shows a flowchart showing an example of a processing procedure of a write process on the back-end side. The write processing procedure on the front-end side performs the same processing as FIG. 14 in SDS51. That is, in the controller 11 of the node 500 that has received the write request, the write program 156 executes the front-end write process shown in FIG. 29A and the back-end write process shown in FIG. 29B in parallel. Hereinafter, the processing procedure of the write process will be described along the flowcharts of FIGS. 29A and 29B while appropriately indicating the corresponding parts in FIG. 28.

[0184] When a write request is made from the host (application server 24) to request writing of data to the virtual volume #2 of SDS51, in the controller 11 of the node #2 having the virtual volume #2 as the write destination, the processor 13 starts the write program 156 to execute 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 for the virtual volume 130 is made from the application server 24 (S2801 in FIG. 28), and write data 132 named "D" is being transferred. Here, although the virtual volume #2 is a virtual volume for accessing data subject to non-standard analysis / monthly batch processing, actually, Snapshot#M in the block storage 10B of the on-premises environment 40 is externally connected to the pool volume #22 that is straight-mapped to the virtual volume #2, and the data of Snapshot#M can be accessed. Also, according to FIGS. 26 and 27, the update difference data for the virtual volume #1 between when Snapshot#N is created and when Snapshot#M is created may be prefetched into the SDS 51 as the data of the virtual volume #2.

[0186] When receiving the write request, in the front end, as shown in FIG. 29A, the write program 156 first checks (step S2901) whether a cache area for the write destination address is 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). 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] Then, the write program 156 returns a normal response (Good response) to the host for the write request (step S1904) and ends the write process in the front end.

[0188] Also, as shown in FIG. 29B, the write program 156 executes back-end 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. If dirty data does not exist (NO in step S2905), the process ends.

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

[0190] Here, as one of the features of SDS51, at least an external volume with a Snapshot of the block storage 10B externally connected serves as the pool volume #22. Further, for a write request to the virtual volume 130 (e.g., virtual volume #2 in FIG. 28) directly mapped to the pool volume 120, the write program 156 of the node (node #2) constituting SDS51 performs write of write data in a log-structured manner (so-called "append write") within its own node. Note that even for a write request to a virtual volume 130 not directly mapped to the pool volume #120, the write program 156 may perform append write in the same way.

[0191] In the write (append) using the log-structured method, the pool 110 (pool volume 120) holds the historical data (data before update) updated by the write data 132. Specifically, when a write request is made for the existing data in the virtual volume 130, the write program 156 writes (appends) the write data (data after update) separately to the pool volume 120 that is not an external volume (for example, pool volume #22) while keeping the existing data (data before update) in the pool volume 120, and then changes the mapping from the virtual volume 130 (write destination address) to the pool volume 120 from the address where the data before update exists (address of the pool volume) to the address where the data after update exists (address of the pool volume). As a result, data update in the virtual volume 130 is performed, and the historical data before update is held in the pool 110 (pool volume 120). However, since the historical data before update is no longer referenced from the virtual volume 130, it may be invalidated asynchronously, for example. Also, when a write request for new data is made to the virtual volume 130, since there is no data before update in the pool volume 120 associated with 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 perform the mapping from the virtual volume 130 to the pool volume 120 for the write data.

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

[0193] Such an additional write corresponds to S2802 in FIG. 28, and it can be seen that the pool volume #21 is the storage destination of the above-described light data (data "D"), and the data "D" in the pool volume #21 is assigned to the data "D" in the virtual volume #2. If the write request of the write data 132 is to update the data "C" in the virtual volume #2, in FIG. 28, the mapping destination of the old data (data "C") in the virtual volume #2 is set to the data "D" in the newly written pool volume #21, whereby the data "C" in the virtual volume #2 is updated to the data "D".

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

[0195] When data is written to the virtual volume #2 that can be accessed via the external volume #22 to the data of the snapshot 130 of the storage system 10B as described above, the write data is additionally written in the node #2 of the SDS51. As a result, a write operation to the virtual volume #2 of the SDS51 can be performed without imposing a load on and affecting the on-premises storage system 10B.

[0196] FIG. 30A and FIG. 30B are diagrams showing examples of read processing flows. In FIG. 30A, when a read request is made from the host to virtual volume #2 of SDS51 for data stored in its own node (that is, when the destination volume of the read request and the storage destination of the actual read data are the same node), the processing image of the read processing is shown. In FIG. 30B, when a read request is made from the host to virtual volume #2 for data stored in another node (that is, when the destination volume of the read request and the storage destination of the actual read data are different nodes, in the example below FIG. 30, when the actual data is in the block storage 10B of the on-premises environment 40), the processing image of the read processing is shown. The example shown in FIG. 30B also partially includes the differential position read processing within the prefetch processing described in FIGS. 26 and 27 above, that is, the read processing corresponding to step S2706 in FIG. 27 (S2606 in FIG. 26).

[0197] Also, FIG. 31 is a flowchart showing an example of the processing procedure of the read processing. Hereinafter, the processing procedure of the read processing will be described along the flowchart of FIG. 31 while appropriately indicating the corresponding parts in FIGS. 30A and 30B.

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

[0199] According to FIG. 31, first, the read program 157 receives the 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 results in 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 process. If it is not a prefetch instruction (No in step S3109), the read program 157 transfers the cached data to the host (step S3110) and ends the read process. On the other hand, if the read data results in a cache miss (Miss in step S3102), the process proceeds to step S3103.

[0201] In step S3103, the read program 157 refers to the read target area of the argument conversion table 142. Then, the read program 157 checks whether the value of the physical address 1422 of the read target area referred to 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. 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] Here, as described above with reference to FIG. 5, in the argument conversion table 142, when data is not stored in the own node (specifically, for example, data is stored in a node different from the node where the virtual volume to be read exists), the value of the physical address 1422 is set to an invalid value such as "FFFFFFFF". In FIG. 30A, when the read data is data "C", since the data "C" is stored in node #2 which is the own node, the physical address 1422 indicates the physical address of the storage destination. On the other hand, in FIG. 30B, when the read data is data "B", since the data "B" is stored in node #1 of the storage system 10B in the on-premises environment 40, an invalid value is indicated in the physical address 1422.

[0203] That is, when the entity of the read data is stored in the own node (FIG. 30A), the process proceeds from step S3104 to step S3107, and when the entity of the read data is not stored in the own node (FIG. 30B), the process proceeds from step S3104 to step S3105.

[0204] First, when the process proceeds from step S3104 to step S3105, the read program 157 refers to the volume management table 141 to identify the pool volume 120 (pool volume #22) in which the data of the volume to be read (virtual volume #2) 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 shown by the thick arrow in FIG. 30B, the data "B" in the pool volume #11 of node #1 in the on-premises environment 40 to which the pool volume #22 identified in step S3105 is externally connected via Snasphot#M is requested to be read as the data at the same address, and the actual data of the data "B" is read from the physical drive 12 storing the actual data of the data "B" and transferred to the cache unit 160 of node #2.

[0206] Then, after the process of step S3106, the read program 157 dirties the data on the cache transferred in step S3106 (step S3108). By dirtying, the data read from the storage system 10B in the on-premises environment 40 becomes a target to be destaged to the local node (node #500) of the SDS51 (S3003B in FIG. 30B). By storing the data read from the on-premises environment 40 in the local node (prefetching) in this way, it becomes possible to access the data at high speed when the application server 24 reads the data again. Overwriting may also be performed in this prefetching. Next, the read program 157 determines whether it is a prefetch instruction in step S3109 (step S3109). If it is a prefetch instruction (Yes in step S3109), the read process ends. If it is not a prefetch instruction (No in step S3109), the read program 157 transfers the data read into the cache to the host (step S3110) and ends the read process.

[0207] On the other hand, when 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 indicated by the thick arrow in FIG. 30A, the data in the page indicated by the logical address of the read target area is the data "C" in the pool volume #21, and the physical drive 12 storing the actual data of this data "C" reads the actual data of the data "C" and transfers it to the cache unit 160.

[0208] After the process 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 process.

[0209] As described above, when the read process is executed, if a valid value is set in the mapping information (logical-physical conversion table 142), the SDS51 reads and responds to read data from its own node. On the other hand, if an invalid value is set in the mapping information (logical-physical conversion table 142), it is determined that there is read data in another node, and the data can be read from the other node via the external volume and responded to.

[0210] FIG. 32 is a flowchart showing the processing procedure for periodically creating a snapshot of the virtual volume #1 accessed from the production server 21 in the storage system 10B in the on-premises environment 40. Snapshots that can instantaneously and virtually replicate the data of the virtual volume #1 are often used for the purpose of logical data protection and are often created periodically. Also, a Retention period (protection period) is set for the snapshot, and by making it impossible to delete or rewrite the snapshot until the Retention period has elapsed since the snapshot was created, the snapshot can be maintained as a backup.

[0211] The snapshot scheduler program 159 of the storage system 10B starts asynchronously, for example. After startup, the snapshot scheduler program 159 determines whether it has reached the timing for snapshot deletion / snapshot creation from the information on the snapshot creation cycle and Retention period (not shown) set by the user in advance 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 transitions to step S3202. If the remaining Retention period remains (NO in step S3201), the process transitions 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 has reached the time to create a new snapshot. If it has reached the time to create a new snapshot (YES in step S3203), the process transitions to processing step S3204. If it has not reached the 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 in-node virtual copy creation process described in FIG. 11. (5) Fifth Embodiment

[0215] Next, a method different from the prefetch processing described with reference to FIGS. 26 and 27 in the fourth embodiment will be described. In the fourth embodiment, before the prefetch processing, the data prefetched in the previous prefetch processing has been invalidated. Specifically, in FIG. 26, at the time of the previous processing, the data "A" and "B" that were referenced from the external volume Snapshot#N and prefetched to SDS51 were invalid data in SDS51 before the current prefetch processing, and the 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 "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 in terms of the physical entity of the data. If the data "B" is accessed in SDS51, it is necessary to transfer the data from the on-premises environment to the public cloud environment 50 again, which affects the agility of the ad-hoc analysis / monthly batch processing.

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

[0217] Also, the upper side of FIG. 33 shows an example where data "E" is written to virtual volume #2 during the period when Snapshot#N is externally connected to external volume 120. However, according to the lower side of FIG. 33, the data "E" written from the host (application server 24) in the public cloud environment 50 becomes a target for invalidation after the external connection destination is switched to Snapshot#M.

[0218] FIG. 33 is a diagram showing a processing image of a process for prefetching data of snapshot 133 of storage system 10B from SDS51 before non-standard analysis and monthly batch processing. FIG. 34 shows an example in which a host-side data flag 1423 is added to the object conversion table 142 of FIG. 5. The host-side data flag 1423 is used to determine whether the data is a target for invalidation because it is host-side data after the external connection destination Snpashot is switched, or whether the data is not a target for invalidation because it is data read from the on-premises environment 40 in the prefetch process.

[0219] FIG. 35 is a flowchart showing an example of a processing procedure of the prefetch process. The difference from FIG. 26 is whether to retain the previous prefetch data. The upper side of FIG. 33 shows a processing image when an instruction to prefetch data of a predetermined snapshot 133 (for example, Snasphot#M) in node 100 (for example, node #1) in the on-premises environment 40 to node 500 (for example, node #2) in the public cloud environment 50 is given. The lower side of FIG. 33 shows a processing image during the subsequent prefetch process.

[0220] Hereinafter, while appropriately indicating the corresponding parts in FIG. 33, the processing procedure of the prefetch process will be described along the flowchart of FIG. 35. First, in step S3501 of FIG. 35, a prefetch instruction is issued from the management server 23 to the SDS 51. Specifically, an instruction is given to prefetch the data of a predetermined snapshot 133 (Snapshot#M) of node #1 to the node 500 in the public cloud environment 50. This is the process corresponding to (S3301) in FIG. 33.

[0221] Next, in step S3502, the SDS 51 executes a process of switching 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. The external volume 120 of the SDS 51 before the prefetch instruction, which was connected to Snapshot#N of the storage system 10B, has its connection destination changed to Snapshot#M. This is the process corresponding to (S3302) in FIG. 33. This process of switching the external connection destination of the external volume is carried out by the same process as step S303 in FIG. 12. That is, in FIG. 12, in S303, the entry of the self-external 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 described above, access from the SDS 51 in the public cloud environment 50 to Snapshot#M in the storage system 10B in the on-premises environment 40 becomes possible.

[0222] Next, in step S3503, the prefetch processing program 158 of the SDS 51 invalidates the data host-written during the external connection of Snapshot#N by initializing the entry indicating the host write data of the logical volume conversion table 142 of the virtual volume 130 accessed by the application server 24. By this invalidation process, the upper host write data "E" in FIG. 33 is invalidated. Also, the prefetch data "B" of Snapshot#N before the Snapshot switch is not subject to invalidation. This is the process corresponding to (S3303) in FIG. 33. The prefetch processing program 158 refers to the host write data flag 1423 in FIG. 34 to determine whether it is host write data or prefetch data in step S3503.

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

[0224] Next, in step S3505, the prefetch processing program 158 of the storage system 10B creates the differential position information between Snapshot#N and Snapshot#M in response to the differential position information acquisition instruction from the SDS 51, and responds with the created differential position information to the SDS 51. This is the process corresponding to (S3305) in FIG. 33. In the example of FIG. 35, the differential position between Snapshot#N and Snapshot#M is the position of the data C on page 131 of Snapshot#M. Since the position of the data "B" has not been updated from Snapshot#N, it does not become the differential position.

[0225] Next, in step S3506, the prefetch processing program 158 of the SDS51 reads data C. For this reason, the data "C" is transferred from the block storage 10B to the SDS51. This corresponds to the process of (S3306) in FIG. 33. The read process is the same as that in FIGS. 30 and 31 described above, and the data at the differential position specified for the virtual volume #2 is read.

[0226] Next, in step S3507, the prefetch processing program 158 of the SDS51 stores the read data in its own pool #2 of the SDS51. This is the process corresponding to (S3307) in FIG. 33. According to FIG. 33, the data "C" is stored in the pool volume #21 other than the external volume, and the object conversion table 142 is updated so as to refer to the data "C" stored in page 121 of the pool volume #21 from the virtual volume #2.

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

[0228] As described above, before the non-standard analysis / monthly batch process is performed, the updated part from the data to be processed in the previous non-standard analysis / monthly batch, the data "C" in the example of FIG. 33, can be prefetched to the SDS51. After that, in response to the request of the application server 24, the SDS51 performs the IO process of the data. However, the application server 24 is highly likely to access the data "C" which is the updated part from the previous processed data. Since the data "C" has been transferred to the SDS51 by the prefetch process, it is possible to access it at high speed. Also, in the fifth embodiment, the prefetch data "B" when the Snapshot#N was externally connected also remains in the own node (node 500) of the SDS51, and the access to the data "B" can also be performed at high speed.

[0229] Although several embodiments have been described above, these are merely examples for the purpose of explaining the present invention, and are not intended to limit the scope of the present invention only 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 drive 12.

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

[0231] The storage system has a plurality of nodes including a first and a second node. Each node has a virtual volume, a pool (which is composed of one or more pool volumes and logically stores data at an address where the data is mapped to the address of the virtual volume), one or more physical drives (where the physical entities of the data logically stored in the pool are stored), a memory (which stores information including the mapping between the address of the virtual volume and the address of the pool (e.g., logical transformation table 142) and stores management information regarding the data), and a processor connected to the memory. The processor of the first node (e.g., Node #1) creates a third virtual volume (e.g., Virtual Volume #3 or Snapshot #N) within the first node by making a virtual copy, which is a copy of the mapping between the address of the virtual volume and the address of the pool, for the first virtual volume (e.g., Virtual Volume #1) in the first node. The processor of the second node (e.g., Node #2) performs a mapping (external connection) from the first pool volume (e.g., Pool Volume #22) in the second node to the 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 one-to-one with the address of the second virtual volume (e.g., Virtual Volume #2) in the second node (performs a straight mapping between the first pool volume and the second virtual volume). When the address of the data to be written (specifically, for example, the data written to the second virtual volume in response to a write request to the second node, or the 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 a log-structured write of the data to the second pool volume (an example of a pool volume other than the first pool volume in the pool of the second node) in the second node.The write operation in the log-structured method includes storing the updated data in the pool while leaving the pre-update data in the pool, and changing the mapping destination 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 as a snapshot of the first virtual volume (e.g., Snapshot#M). The processor of the second node may perform a prefetch process in response to a prefetch instruction. The prefetch process may include prefetching the data through the address in the first pool volume mapped to the address where the data in the third virtual volume is located in the second virtual volume, and performing a log-structured write operation on the prefetched data for the second pool volume.

[0233] The mapping from the first pool volume to the third virtual volume may be changed by changing the mapping destination of the first pool volume from a third virtual volume of a generation older 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 difference position that is an address having a difference in data from a third virtual volume of a generation older than the third virtual volume among the third virtual volumes. The prefetched data may be data obtained from the difference position.

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

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

[0236] When the processor of the second node receives a read request specifying the second virtual volume after the prefetch process, based on the management information in the memory of the second node, it may be determined which node the data at the address specified in the read request is in. If the determined node is the second node, the processor of the second node may read 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 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 data from the first node in response to a read request, a log-structured write of the data may be performed on any of the above pool volumes (for example, the second pool volume).

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

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

[0239] When a write request for write data is made to the second virtual volume created as a virtual clone of the first virtual volume, the processor of the second node stores the write data in a second pool volume different from the first pool volume by write in a log-structured manner, stores the entity of the write data in the physical drive of the second node, and may update the mapping so that the destination associated with the write data in the second virtual volume becomes the write data stored in the second pool volume.

[0240] The management information possessed by each node may include logical-physical conversion data that manages the correspondence between the logical storage destination of the data in its own node 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 by the second virtual volume associated with the first pool volume to a null value in the logical-physical conversion data.

[0241] When a request is made to read read data for a second virtual volume created as a virtual clone, the processor of the second node may determine the node from which to read the read data based on whether the physical storage location of the read data is the invalid value by referring to the object conversion data of its own node.

[0242] When a request is made to read read data for a second virtual volume created as a virtual clone, when the physical storage location of the read data is an invalid value in the object conversion data of the second node, the processor of the second node requests the processor of the first node to read the read data from a third virtual volume mapped from the first pool volume. The processor of the first node may obtain the entity of the read data requested to be read from the processor of the second node from the physical drive of the first node based on the object 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 releases the mapping from the first pool volume to the third virtual volume and releases the association between the second virtual volume and the first pool volume. After the processor of the first node releases the mapping in the second node, the third virtual volume may be deleted. 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 the write data stored in its own physical drive in response to a request to write write data to the second virtual volume.

[0244] After the second virtual volume is created as a virtual clone of the first virtual volume, when the load on the first node exceeds a predetermined threshold due to an input / output request for data to the second node, the processor of the second node may, for at least a part of the data of the first pool volume associated with the second virtual volume, obtain the physical entity of the data from the first node, store it in the physical drive of the second node, then copy it to a third pool volume different from the first pool volume, and update the management information so as to associate the second virtual volume with 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 the physical entity of all the data of the first pool volume associated with the second virtual volume from the first node and stores it in the physical drive of the second node, the mapping from the first pool volume to the third virtual volume may be released, and the association between the second virtual volume and the first pool volume may be released.

[0245] When the storage system is configured to be connected to a cloud environment, the processor of the first node and the processor of the third node provided in the cloud environment may cooperate to execute a process of replacing the second virtual volume with a fourth virtual volume in the third node, so that a virtual clone of the first virtual volume can also be created in the third node under the cloud environment.

Explanation of Signs

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

Claims

1. A storage system having a plurality of nodes including a first node and a second node, each of said nodes having, a virtual volume, a pool composed of one or more pool volumes, wherein data to the address of said virtual volume is logically stored at an address mapped to said address, one or more physical drives in which the entity of the data logically stored in said pool is stored, a memory storing management information regarding data, which is information including the mapping between the address of said virtual volume and the address of said pool, and a processor connected to said memory, wherein, the processor of said first node creates a third virtual volume within said first node by performing, for a first virtual volume in said first node, a virtual copy which is a copy of the mapping between the address of the virtual volume and the address of the pool, the processor of said second node, performs mapping from a first pool volume in said second node to said third virtual volume created in said first node, ​ ​ ​ ​ ​ ​ ​ ​ ​ ​ 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 exists among the second virtual volumes, and performing a log-structured write of the prefetch data to the second pool volume including The storage system according to claim 1, characterized in that.

3. The mapping from the first pool volume to the third virtual volume is to change the mapping destination of the first pool volume from a third virtual volume of a generation older than the third virtual volume to the third virtual volume, The prefetching process includes identifying a difference position, which is an address where there is a difference in data between the third virtual volume and a third virtual volume of a generation older than the third virtual volume, from the first node among the third virtual volumes, The prefetch data is data obtained from the difference position The storage system according to claim 2, characterized in that.

4. The processor of the second node invalidates the data prefetched in the previous prefetch process and written to the second pool volume in order to subject the data to garbage collection, The previous prefetch process includes prefetching data from an address where there is a difference in data between a third virtual volume of a generation older than the third virtual volume of the old generation and a third virtual volume of a generation even older than the third virtual volume of the old generation among the third virtual volumes of the old generation, and performing a log-structured write of the prefetch data to the second pool volume The storage system according to claim 3, characterized in that.

5. When the processor of the second node receives a write request specifying the second virtual volume after the prefetch process, perform a log-structured write of the write data associated with the write request to any pool volume other than the first pool volume in the pool of the second node The storage system according to claim 2, characterized in that.

6. When the processor of the second node receives a read request specifying the second virtual volume after the prefetch process, Based on the management information in the memory of the second node, determine which node has the data at the address specified in the read request. If the determined node is the second node, read data from the address of the second pool volume mapped to the specified address. If the determined node is the first node, obtain data from the third virtual volume of the first node through the address of the first pool volume mapped to the specified address. The storage system according to claim 2, characterized in that.

7. When the processor of the second node obtains data from the first node in response to the read request, perform a write of the log-structured format of the data to the second pool volume. The storage system according to claim 6, characterized in that.

8. The processor of the second node does not invalidate the data prefetched and written to the second pool volume in the previous prefetch process for the purpose of garbage collection of the data. The previous prefetch process includes prefetching data from an address where there is a difference in data between a third virtual volume of an older generation and a third virtual volume of an older generation than the third virtual volume of the older generation among the third virtual volumes of the older generation, and performing a write of the log-structured format of the prefetched data to any of the pool volumes. The storage system according to claim 3, characterized in that.

9. In the prefetch process, the processor of the second node invalidates the write data written to the second pool volume in response to a write request before the prefetch process for the purpose of garbage collection of the write data. The storage system according to claim 2, characterized in that.

10. The management information in the memory of the second node includes information indicating whether the data written to the second pool volume is data prefetched and written in the prefetch process in response to a prefetch instruction or write data written in response to a write request for each piece of data. Based on the management information, the processor of the second node identifies the write data written to the second pool volume in response to a write request before the prefetch process, and invalidates the identified write data. The storage system according to claim 9, characterized in that.

11. When a write request for write data is made to the second virtual volume created as a virtual clone of the first virtual volume, The processor of the second node, Stores the write data in a second pool volume different from the first pool volume by writing in the log-structured method, stores the entity of the write data in the physical drive of the second node, Updates the mapping so that the associated destination of the write data in the second virtual volume becomes the write data stored in the second pool volume. The storage system according to claim 1, characterized in that.

12. The management information possessed by each of the nodes includes logical conversion data for managing the correspondence between the logical storage destination of data in its own node 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 sets the physical storage destination of the data virtually held by the second virtual volume associated with the first pool volume to a null value in the logical conversion data. The storage system according to claim 1, characterized in that.

13. When deletion of the second virtual volume created as a virtual clone of the first virtual volume is requested, The processor of the second node releases the mapping from the first pool volume to the third virtual volume and releases the association between the second virtual volume and the first pool volume. After the release of the mapping in the second node, the processor of the first node deletes the third virtual volume. The storage system according to claim 1, characterized in that.

14. After the second virtual volume is created as a virtual clone of the first virtual volume, when the load in the first node exceeds a predetermined threshold due to an input / output request for data to the second node, The processor of the second node, For at least a part of the data of the first pool volume associated with the second virtual volume, after obtaining the entity of the data from the first node and storing it in the physical drive of the second node, copy it to a third pool volume different from the first pool volume, For the data copied from the first pool volume to the third pool volume, update the management information so as to associate the second virtual volume with the third pool volume The storage system according to claim 1, characterized in that.

15. A first node among a plurality of nodes constituting a storage system creates a third virtual volume in the first node by performing, for a first virtual volume in the first node, a virtual copy that is a copy of the mapping between the address of the virtual volume and the address of the pool, A second node among a plurality of nodes constituting the storage system performs mapping from a first pool volume in the second node to the third virtual volume created in the first node, and one-to-one associates the address of the first pool volume mapped to the third virtual volume with the address of a second virtual volume of the second node. When the address of the data to be written is the address in the second virtual volume, perform a write in a log-structured manner for the data to a second pool volume in the second node, The write in the log-structured manner includes storing updated data in the pool while leaving pre-update data in the pool, and changing the mapped address of the address in the virtual volume from the address of the pre-update data to the address of the updated data A storage control method characterized by that.

Images