Storage systems and distributed deduplication methods

Abstract

Under the constraint of not changing the chunk size in order to maintain the reduction effect of distributed deduplication, the processing time for data redistribution associated with load redistribution across nodes is reduced. [Solution] A storage system in which multiple nodes are connected to each other, each node comprising a pool, a volume associated with the storage area of ​​the pool, and a processor that processes data input and output to the volume and pool, wherein a processor that receives a write request creates identification information from the data related to the write request, determines the node to store the data based on the range to which the value of the created identification information belongs, and the processor of the node that has decided to store the data retrieves the data related to the write request, performs deduplication using the identification information, and stores it in the node's pool.

Description

Technical Field

[0001] The present invention relates to deduplication in a storage system, and is suitable for application to a storage system adopting a loosely coupled scale-out architecture and a method of deduplication in such a storage system.

Background Art

[0002] The need for utilization of big data, such as data analysis by AI (Artificial Intelligence), is increasing, and it is required to efficiently store and manage huge amounts of data. As the amount of data to be analyzed increases, the IO performance required to meet the processing time requirements becomes higher, so it is necessary to flexibly expand computing resources such as host computers and storage systems according to the amount of data. Scale-out storage can expand computing resources in addition to increasing storage capacity by adding appliances (nodes), and thus is widely used. Specifically, a storage system using a loosely coupled scale-out method in which nodes are clustered has become mainstream. In the architecture as described above, distributed deduplication is used as a method for efficiently storing data in a small capacity.

[0003] Distributed deduplication is a technology that extends the deduplication technology for eliminating duplicate data within one node to scale-out storage composed of multiple nodes, and can store data more efficiently by reducing duplicate data among multiple nodes. The distributed deduplication technology is disclosed in, for example, Patent Document 1.

Prior Art Documents

Patent Documents

[0004]

Patent Document 1

Summary of the Invention

[0005] Scale-out storage distributes the load of I / O processing across nodes by distributing data across each node in the system. However, when a new node is added, the data must be moved to the added node to redistribute the load. Load redistribution requires moving data to a new location, deleting it from the old location, and updating metadata, which generates a large amount of traffic on the network between nodes.

[0006] Generally, data deduplication involves dividing data into specific blocks, calculating the hash value of each divided data (chunk) using a hash algorithm such as SHA1, and eliminating duplicate data by finding a match in the hash values. In conventional distributed deduplication technology, the original chunks distributed across each node have mapping relationships that reference each other within and between nodes. Therefore, when redistributing the load and rearranging the data, it is necessary to move, delete, or update the mapping of data on a chunk-by-chunk basis, across nodes. Deduplication is more effective when the chunk size is reduced, so chunk sizes are often set to around a few kilobytes. On the other hand, reducing the chunk size increases the number of chunks to process, which increases the time required for data rearrangement and impairs scalability.

[0007] This invention was made in consideration of the above points, and aims to propose a storage system and deduplication method that can improve scalability by achieving efficient data reallocation while maintaining the reduction effect of distributed deduplication. [Means for solving the problem]

[0008] An example of the invention disclosed in this application is as follows: A storage system in which a plurality of nodes are connected to each other, each node comprising a pool, a volume associated with the storage area of ​​the pool, and a processor that processes data input to and output from the volume and the pool, wherein the processor, upon receiving a write request, creates identification information from the data relating to the write request, determines the node to store the data based on the range to which the value of the created identification information belongs, and stores the data. As a node decision So The processor of the node acquires the data relating to the write request, performs deduplication using the identification information, and stores it in the node's pool. [Effects of the Invention]

[0009] According to one aspect of the present invention, data relocation at the volume level is made possible by establishing a one-to-one correspondence between data mappings between nodes. While maintaining the reduction effect of distributed deduplication between nodes, it eliminates the need for chunk-level data movement across nodes, deletion, and mapping updates that were required in conventional technologies during data relocation. By moving data at the volume level, the processing time for data relocation is shortened, and the scalability of scale-out storage can be improved. Issues, configurations, and effects other than those mentioned above will be clarified by the following description of the embodiments. [Brief explanation of the drawing]

[0010] [Figure 1] This is a block diagram showing an example of the logical configuration of a storage system according to the first embodiment of the present invention. [Figure 2] This block diagram shows an example of a storage system hardware configuration. [Figure 3] This figure shows an example of the memory configuration of a storage system. [Figure 4] This figure shows an example of a volume management table. [Figure 5] This figure shows an example of a data distribution destination management table. [Figure 6] It is a diagram showing an example of an empty area management table. [Figure 7] It is a diagram showing an example of a logical address conversion table. [Figure 8] It is a diagram showing an example of a pool management table. [Figure 9] It is a diagram showing an example of a hash value management table. [Figure 10] It is a diagram showing an example of an external volume management table. [Figure 11] It is a diagram showing an example of a volume movement management table. [Figure 12] It shows the processing image of the write process. [Figure 13] It is a diagram showing an example of the procedure for deduplication during writing. [Figure 14] It is a diagram showing an example of the procedure for assigning logical addresses during writing. [Figure 15] It is a diagram showing the processing image of the volume movement process. [Figure 16] It is a flowchart showing an example of the processing procedure of the write process on the front-end side. [Figure 17] It is a flowchart showing an example of the processing procedure of the write process on the back-end side. [Figure 18] It is a flowchart showing an example of the processing procedure of the read process. [Figure 19] It is a flowchart showing an example of the procedure of the volume data copy process in volume movement. [Figure 20] It is a flowchart showing an example of the procedure of the switching process of the external volume performed after the completion of the data copy between volumes in volume movement. [Figure 21] It is a diagram showing an example of the procedure for assigning logical addresses during writing in the storage system according to the second embodiment of the present invention. [Figure 22] It is a diagram showing the processing procedure of the write process in the storage system according to the third embodiment of the present invention.

Modes for Carrying Out the Invention

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

[0012] Note that the following description and the drawings are examples for explaining the present invention, and for the sake of clarity of explanation, appropriate omissions and simplifications are made. 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.

[0013] In the following description, expressions such as "table", "sheet", "list", etc. may be used for explanation, but various information may also be represented by data structures other than these. In order to indicate independence from the data structure, "XX table", "XX list", etc. may be referred to as "XX information". When explaining the content of each information, expressions such as "identification information", "identifier", "name", "ID", "number", etc. are used, but these are mutually replaceable.

[0014] Also, in the following description, when explaining without distinguishing between elements of the same type, reference signs or common numbers in the reference signs are used, and when explaining 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 explaining "storage node" without particularly distinguishing, it is described as "node 100", whereas when explaining each individual node 100 by distinguishing, it may be described as "node #1", "node #2", etc.

[0015] Furthermore, while the following description may include explanations of processes performed by executing a program, the processor may be the primary entity performing the processing, as a program is executed by at least one processor (e.g., a CPU) and performs defined processes using appropriate memory resources (e.g., memory) and / or interface devices (e.g., communication ports). Similarly, the primary entity performing the processing by executing a program may be a controller, device, system, computer, node, storage system, storage device, server, management computer, client, or host having a processor. The primary entity performing the processing by executing a program (e.g., a processor) may include hardware circuits that perform some or all of the processing. For example, the primary entity performing the processing by executing a program may include hardware circuits that perform encryption and decryption, or compression and decompression. The processor operates as a functional unit that realizes predetermined functions by operating according to the program. Devices and systems including a processor are devices and systems including these functional units.

[0016] A program may be installed from its program source into a device such as a computer. The program source may be, for example, a program distribution server or a non-temporary storage medium readable by a computer. If the program source is a program distribution server, the program distribution server includes a processor (e.g., a CPU) and non-temporary storage resources, which may further store the distribution program and the program to be distributed. The processor of the program distribution server may then execute the distribution program, thereby distributing the program to other computers. Furthermore, in the following description, two or more programs may be implemented as a single program, or one program may be implemented as two or more programs.

[0017] (1) First Embodiment (1-1) System Configuration Figure 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.

[0018] The storage system 10 is a storage system employing a loosely coupled scale-out architecture and comprises multiple nodes 100 (e.g., node #1, node #2). As shown in Figure 1, each node 100 has a logical configuration of a pool 110, a pool volume 111, a virtual pool volume 112, a normal volume 113, and a virtual volume 114. Storage employing a loosely coupled scale-out architecture has a scale-out function that allows for expansion of performance or capacity as needed from a small configuration. A loosely coupled scale-out method that clusters multiple appliances (e.g., nodes 100) is the mainstream, and the storage system 10 shown in Figure 1 also employs this scale-out method, but is not limited to this.

[0019] Virtual volumes 114 (for example, virtual volume #1, virtual volume #2) are logical storage areas managed by the storage system 10, and provide virtual capacity to the host computer 20 through thin provisioning. Virtual volumes 114 are associated with pool 110 (pool #1, pool #3), which is formed by integrating one or more pool volumes 111 and one or more virtual pool volumes 112, by the volume management table 141 described later.

[0020] The pool volume 111 is a logical storage device managed by the storage system 10, and is configured to correspond to the storage areas of one or more drives 12, which will be described later.

[0021] The virtual pool volume 112 is a logical storage device managed by the storage system 10 and is mapped to the normal volumes 113 (e.g., volumes #1 to #4) by the external volume management table 147 described later.

[0022] The regular volume 113 is a logical storage area managed by the storage system 10, and provides virtual capacity to the virtual pool volume 112 through thin provisioning. The regular volume 113 is associated with a pool 110 (e.g., pool #2, pool #4) which is formed by integrating one or more pool volumes 111, by the volume management table 141 described later.

[0023] Data written from the host computer 20 to the virtual volume 114 is managed in units of chunks 115. For each chunk 115, the destination virtual pool volume 112 is selected by the data distribution destination management table 142 (described later), the destination logical address is assigned by the free space management table 143 (described later), and the chunk is mapped to the logical address of the virtual pool volume 112 by the logical address translation table 144 (described later).

[0024] Data written to chunk 115, which is associated with the logical address of virtual pool volume 112, is written to normal volume 113, which is mapped to virtual pool volume 112, via the storage network 30. This is the external connection function in this embodiment. The data written from virtual pool volume 112 to normal volume 113 is managed in units of chunk 115 and associated with the logical address of pool volume 111 by the logical address translation table 144, which will be described later.

[0025] For example, in Figure 1, virtual volume #1 is associated with pool #1, which includes pool volume 111 and virtual pool volume 112. Chunk 115 of "A" in virtual volume #1 is assigned a logical address to virtual pool volume 112 and written to normal volume #1 via storage network 30. Normal volume #1 is associated with pool #2, which includes pool volume 111. Chunk 115 of "A" in normal volume #1 is assigned to pool volume 111 in pool #2.

[0026] Figure 2 is a block diagram showing an example of the hardware configuration of the storage system 10.

[0027] As explained in Figure 1, the storage system 10 comprises multiple nodes 100. The storage system 10 is connected to the host computer 20 via the storage network 30.

[0028] The host computer 20 sends an I / O request (write request or read request) specifying the I / O destination to the controller 11 of the storage system 10.

[0029] The storage network 30 is, for example, an FC (Fiber Channel) network.

[0030] Node 100 comprises one or more controllers 11 and multiple 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. In Figure 2, an SSD (Solid State Drive) is shown as an example of a physical drive 12, but it is not limited to this; any device that physically stores data, such as an HDD (Hard Disk Drive), is acceptable.

[0031] The controller 11 includes one or more processors 13, one or more memory 14, a front-end interface 15, and a back-end interface 16.

[0032] The processor 13 is a processor that performs various controls by executing a program read from the memory 14. In this embodiment, the processor 13 performs data writing and reading, as well as control related to the movement of volumes between nodes 100. The processor 13 is, for example, a CPU (Central Processing Unit), but is not limited to this.

[0033] Memory 14 is a storage unit that stores programs executed by the processor 13, as well as data used by the processor 13.

[0034] The front-end IF15 is a communication interface device that mediates data exchange between the controller 11 and the host computer 20. The controller 11 is connected to the host computer 20 via the storage network 30 from the front-end IF15.

[0035] The backend IF16 is a communication interface device that mediates data exchange between the physical drive 12 and the controller 11. Multiple physical drives 12 are connected to the backend IF16.

[0036] (1-2) Memory configuration Figure 3 is a diagram showing an example of the configuration of the memory 14 of the storage system 10, and is a diagram showing an example of the programs and control data in the memory 14 used by the storage system 10.

[0037] The programs and control data used by the storage system 10 (mainly the controller 11) are read into memory 14 and executed or used by the processor 13.

[0038] As shown in Figure 3, the memory 14 includes a control information area 140 for holding control data, a program area 150 for holding programs executed by the processor 13, a cache area 160 which serves as a cache, and a buffer area 170 which temporarily holds data for operations such as sorting data.

[0039] The control information area 140 stores the volume management table 141, the data distribution destination management table 142, the free space management table 143, the logical address translation table 144, the pool management table 145, the hash value management table 146, the bounding volume management table 147, and the volume movement management table 148. Figures 4 to 11, described later, show examples of the configuration of each table.

[0040] The program area 150 stores a write program 151, a read program 152, and a volume transfer program 153. These programs are provided for each of the multiple controllers 11 and cooperate with each other to perform the desired processing. Details of the processing performed by each program will be described later.

[0041] The cache area 160 temporarily stores datasets that are written to or read from the physical drive 12.

[0042] Buffer area 170 temporarily stores the data being operated on when performing operations such as sorting, compression, or encryption.

[0043] Figure 4 shows an example of a volume management table 141.

[0044] The volume management table 141 is control data that manages volume information such as virtual volume 114, normal volume 113, virtual pool volume 112, and pool volume 111. The volume management table 141 has the following entries: volume ID 1411, capacity 1412, usage 1413, volume type 1414, and affiliated pool ID 1415.

[0045] Volume ID 1411 indicates the volume identifier. Capacity 1412 indicates the capacity allocated to the volume identified by Volume ID 1411 (hereinafter referred to as "the volume"), and Usage 1413 indicates the current usage of the volume.

[0046] Volume type 1414 indicates the type of volume in question.

[0047] The pool ID 1415 indicates the identifier of pool 110 to which the volume belongs.

[0048] Figure 5 shows an example of the data distribution destination management table 142.

[0049] The data distribution destination management table 142 is control data that manages the range of hash values ​​for the data to be allocated to the virtual pool volume 112. The data distribution destination management table 142 has entries for data distribution destination volume ID 1421 and hash value range 1422.

[0050] The data distribution destination volume ID 1421 indicates the identifier (volume ID) of the virtual pool volume. The hash value range 1422 indicates the range of hash values ​​for the data to be assigned to the virtual pool volume 112 identified by the data distribution destination volume ID 1421. In this embodiment, since the data is processed in units of chunks 115, a hash value is created for each chunk 115. The hash value range 1422 is identified from the created hash values, and the volume ID of the virtual pool volume 112 indicated by the corresponding data distribution destination volume ID 1421 is obtained.

[0051] As will be explained later, the hash value is just one example of identification information for chunk 115, and other values ​​(e.g., modulo) may also be used as identification information. The same applies to the hash values ​​described later. In any case, a range of identification information values ​​is set for each virtual pool volume 112, chunk 115 is classified according to the range to which its identification information value belongs, and a virtual pool volume with the classified range set is selected as the allocation destination.

[0052] Figure 6 shows an example of the free space management table 143.

[0053] The free space management table 143 is control data for managing the free space of the virtual pool volume 112. The free space management table 143 has entries for volume ID 1431, logical address 1432, and status 1433.

[0054] Volume ID 1431 indicates the identifier of virtual pool volume 112. Logical address 1432 indicates the chunk-level address of the logical address space of virtual pool volume 112. Status 1433 indicates whether data has been allocated to the logical address space of virtual pool volume 112, with "1" indicating allocated data and "0" indicating unallocated (free) data.

[0055] Figure 7 shows an example of a logical address translation table 144.

[0056] The logical address translation table 144 is data that manages the correspondence between the logical address 1442 of virtual volume 114 and the logical address 1445 of virtual pool volume 112, or between the logical address 1442 of normal volume 113 and the logical address 1445 of pool volume 111. The logical address translation table 144 has the following entries: volume ID 1441, logical address 1442, status 1443, assigned volume ID 1444, and assigned logical address 1445.

[0057] Volume ID 1441 indicates the identifiers of virtual volume 114 and normal volume 113. Logical address 1442 indicates the logical addresses of virtual volume 114 and normal volume 113. In this embodiment, data is processed in chunks, so logical address 1442 in Figure 7 is shown as the address for each chunk. Status 1443 indicates whether data has been allocated to the logical address space of virtual volume 114 and normal volume 113, with "1" indicating allocated and "0" indicating unallocated (free). The allocated volume ID 1444 indicates the identifiers of the allocated virtual pool volume 112 and pool volume 111. The allocated logical address 1445 indicates the logical address (start address) of the data storage location for the allocated virtual pool volume 112 and pool volume 111.

[0058] Figure 8 shows an example of a pool management table 145.

[0059] The pool management table 145 is control data for managing pool 110. The pool management table 145 has the following entries: pool ID 1451, capacity 1452, usage 1453, virtual capacity 1454, virtual usage 1455, volume ID 1456, and attribute 1457.

[0060] Pool ID 1451 indicates the identifier of the pool. Capacity 1452 indicates the capacity allocated by integrating the pool volumes 111 belonging to the pool identified by Pool ID 1451 (hereinafter referred to as "the pool"), and Usage 1453 indicates the current usage in the pool.

[0061] The virtual capacity 1454 represents the capacity of the actual data residing in another pool, which is allocated by integrating the virtual pool volume 112 belonging to that pool. The virtual usage 1455 represents the amount of the capacity indicated by the virtual capacity 1454 that is actually used.

[0062] Volume ID 1456 indicates the volume IDs of virtual pool volume 112 and pool volume 111 belonging to the pool in question. Attribute 1457 indicates whether the actual data of the volume identified by volume ID 1456 is "inscribed" in the pool or "circumscribed" in a different pool.

[0063] Figure 9 shows an example of a hash value management table 146.

[0064] The hash value management table 146 (hereinafter referred to as "the table") is control data that manages the hash value created for each chunk 115 using a hash algorithm, as well as the identifier and logical address of the volume where the chunk is stored. It is used to determine whether or not there is duplicate data by searching the table for information with matching hash values.

[0065] The hash value 1461 is specific identification information used to identify the data (hereinafter referred to as "the data"), and for example, it represents a hash value created by a hash algorithm.

[0066] Volume ID 1462 indicates the identifier (Volume ID) of the regular volume 113 (hereinafter referred to as "the volume") where the data is stored.

[0067] Logical address 1463 indicates the logical address where the data stored in the volume is located.

[0068] Figure 10 shows an example of an external volume management table 147.

[0069] The external volume management table 147 is control data that manages the node number of the node 100 to which the normal volume 113 connected to the virtual pool volume 112 belongs, and the volume ID of the normal volume 113. The external volume management table 147 has the following items: volume ID 1471, external node number 1472, external volume ID 1473, and external volume status 1474.

[0070] Volume ID 1471 indicates the identifier (volume ID) of virtual pool volume 112 (hereinafter referred to as "the volume").

[0071] The external node number 1472 indicates the identifier (node ​​number) of node 100 to which the regular volume 113 (hereinafter referred to as the connected volume) to which the volume is connected belongs.

[0072] External volume ID 1473 indicates the identifier (volume ID) of the volume to which this volume is connected.

[0073] External volume status 1474 indicates the state of the connected volume, such as "normal," meaning that I / O to the connected volume is possible, or "blocked," meaning that it is in an abnormal state.

[0074] Figure 11 shows an example of a volume transfer management table 148.

[0075] The volume transfer management table 148 is control data used to move data between nodes. The volume transfer management table 148 has the following entries: volume ID 1481, volume transfer instruction 1482, destination node number 1483, destination volume ID 1484, and progress pointer address 1485.

[0076] Volume ID 1481 indicates the identifier (volume ID) of normal volume 113 (hereinafter referred to as "the volume"). Volume move instruction 1482 indicates whether the volume is being moved between nodes, indicating "movement" or "no movement". Destination node number 1483 indicates the identifier (node ​​number) of node 100, the destination node to which the volume is being moved. Destination volume ID 1484 indicates the identifier (volume ID) of normal volume 113 (hereinafter referred to as "destination volume") that will be created at destination node 100 as the destination for the volume. Progress pointer address 1485 is information indicating the progress of the data movement of the volume, and indicates the logical address (starting address) of the next data that has been copied between the volume and the destination volume.

[0077] (1-3) Processing The following describes in detail the processes performed by the storage system 10 according to this embodiment, including "write processing" performed in response to write requests, "read processing" performed in response to read requests, and "volume movement processing" performed when rearranging data between nodes 100.

[0078] (1-3-1) Light Processing Below, we will explain the sequence of steps in the write process using the processing images shown in Figures 12, 13, and 14. Then, we will explain the details of the processing procedure using the flowcharts shown in Figures 16 and 17.

[0079] Figure 12 shows the processing image of node 100 (node ​​#1) which receives a write request from host computer 20, and the processing image of node 100 (node ​​#2) which is the storage location for the actual data, as an example of the write process.

[0080] Specific examples are shown below.

[0081] (S1201) Node #1 is connected to host computer 20 storage A write request to the virtual volume 114 is received via network 30. The write request includes the data and the logical address to which the data is allocated. Upon receiving the write request, node #1 allocates space on the cache area 160 for writing the data and writes the data to the allocated space. In this embodiment, the data written by the host computer 20 is set to chunks 115 of a specific size, but the size of the data is not limited, and a size different from chunk 115 may be specified. When the controller 11 of node #1 receives the write request and writes the data to the cache area 160, it makes the data on the cache redundant with another controller 11 within node #1 and responds to the host computer 20 that the write process is complete.

[0082] (S1202) Node #1 creates a hash value from chunk 115 written to cache area 160 using a hash algorithm. In Figure 12, the hash value "h(D)" is created from chunk 115 "D".

[0083] In this embodiment, the hash value of chunk 115 is calculated as described above. However, this is just one example of identification information for the chunk data. As long as the same identification information is assigned to the same data, a value other than the hash value may be used as identification information. For example, the modulo (remainder) may be used as identification information through modulo arithmetic.

[0084] (S1203) In the case of a write to virtual volume 114, node #1 selects a storage location for chunk 115 from one or more virtual pool volumes 112. The range of hash values ​​for the data to be stored is set in advance for each virtual pool volume 112, and node #1 selects the virtual pool volume 112 with the hash value range corresponding to the aforementioned hash value "h(D)" as the storage location. In the example in Figure 12, the pool 110 (pool #1) within node #1 contains a virtual pool volume 112 with the hash value range h(A) to h(C) set, and a virtual pool volume 112 with the hash value range h(D) to h(F) set, and the latter is selected as the storage location for chunk 115 "D".

[0085] (S1204) The normal volume 113 on node #2, which is the destination (i.e., the external destination) of the virtual pool volume 112, is accessed from node #1. storage A write request is made via network 30. The write request includes chunk 115 "D" on node #1's cache area 160 and the same logical address as the allocation destination of virtual pool volume 112. When node #2 receives the write request, it allocates space on cache area 160 for writing the data, and the data is written to the allocated space. Similar to node #1, node #2 also has redundant data on its cache and responds to node #1, the originator of the write request, with confirmation that the write operation is complete.

[0086] In this embodiment, a pool volume 111 is used for storage on the local node, and the external destination of the virtual pool volume 112 is a normal volume 113 in another node 100. However, a normal volume 113 in the same node 100 may also be used as the external destination. In that case, node #1 will access from the backend IF16. storage A write request to the normal volume 113 within the node is sent via network 30. When the front-end IF15 receives the write request, it performs the same processing as node #2 in the example above.

[0087] (S1205) Node #2 creates a hash value from chunk 115 written to the cache area 160 of node #2. Similar to node #1, the hash value "h(D)" is created from chunk 115 "D".

[0088] (S1206) Node #2, if the received request is a write to volume 113, uses the generated hash value to search for duplicate data. Figure 12 shows the case where there is no duplicate data, and pool volume 111 is allocated as the storage location for chunk 115. In this embodiment, the logical address to which pool volume 111 is allocated is determined by the log structure method (so-called "append").

[0089] (S1207) When a logical address is assigned on pool volume 111, node #2 transfers chunk 115 "D" from cache area 160 to the corresponding area on drive 12. Data written to the area on drive 12 is protected against drive failure using data redundancy techniques such as RAID (e.g., RAID 5 or RAID 6).

[0090] Figure 13 shows an example of the deduplication procedure during writing. Specifically, it shows the process when duplicate data is found during the deduplication process performed within node 100.

[0091] Specific examples are shown below.

[0092] (S1301) A hash value "h(D)" is created from chunk 115 "D" written to the cache area 160 of node 100. Figure 13 shows the case where the duplicate data is in the same normal volume 113 (write to normal volume #4) and the case where the duplicate data is in a different normal volume 113 (write to normal volume #3).

[0093] (S1302) The generated hash value is used to search for duplicate data. Figure 13 assumes that chunk 115 "D" is already stored in volume #1, and the stored chunk 115 "D" is detected by searching for duplicate data. Even if the hash values ​​are the same, the data may not be identical, so the detected chunk 115 "D" is read out to check if the data is identical. If it is found to be identical, it is considered a duplicate, and deduplication is performed by mapping the logical address on pool volume 111 to which chunk 115 "D" is allocated.

[0094] For example, node 100 in Figure 13 corresponds to node #2 in Figure 12, normal volume #4 in Figure 13 corresponds to normal volume 113 within node #2 in Figure 12, and normal volume #3 in Figure 13 can be considered to correspond to another normal volume 113 within node #2 that is not shown in Figure 12. In this case, the example in Figure 13 shows the processing that occurs when node #2 receives two more write requests for chunk 115 "D" after processing the first write request for chunk 115 "D" as shown in Figure 12.

[0095] For example, the two chunks 115 "D" written to normal volume #4 in Figure 13 may be written to virtual volume 114 on node #1 and then transferred to the external node #2 via virtual pool volume 112 corresponding to the hash value "h(D)" of pool #1. On the other hand, the chunks 115 "D" written to normal volume #3 in Figure 13 may be written to virtual volume 114 on node #2 and then transferred to the external node #2 via virtual pool volume 112 corresponding to the hash value "h(D)" of pool 110 within node #2.

[0096] For the first write request for chunk 115 "D" shown in Figure 12, an address on pool volume 111 is assigned. Subsequently, for the second and subsequent write requests for chunk 115 "D" shown in Figure 13, deduplication is performed by mapping to already assigned addresses without assigning a new address on pool volume 111.

[0097] In this embodiment, all nodes 100 included in the storage system 10 are set to the same hash value range for the data to be allocated to the virtual pool volume 112. Then, the virtual pool volume 112 with the same hash value range is mapped to one of the regular volumes 113 within a single node 100. As a result, regardless of which node 100 the data is written to, if it is the same data, its actual data is collected in a single node 100. By performing deduplication in that node 100, deduplication is achieved among all nodes 100 included in the storage system 10.

[0098] Furthermore, writes to each normal volume 113 are performed according to write requests to external destinations via the virtual pool volume 112 mapped to each normal volume 113. In this case, normal volumes 113 and virtual pool volumes 112 are mapped one-to-one. This means that when moving volumes (see Figure 15, etc.), as described later, only the mapping between normal volumes 113 and virtual pool volumes 112 needs to be changed, eliminating the need to change the mapping for each chunk 115, thus reducing processing time.

[0099] Figure 14 shows an example of the procedure for assigning logical addresses during a write operation.

[0100] Specific examples are shown below.

[0101] (S1401) As explained in Figure 12, the virtual pool volume 112 to be stored is selected according to the hash value created for each chunk 115. When the virtual pool volume 112 to be stored is selected, an unassigned logical address 116 on the virtual pool volume 112 is allocated for each chunk 115. Note that if a write (update write) is performed on an allocated logical address 117 on the virtual volume 114, the allocated logical address 117 on the virtual pool volume 112 becomes invalid (unassigned logical address 116), and another new unassigned logical address 116 is allocated. In Figure 14, when chunks 115 "A", "B", and "C" are written, a contiguous area of ​​unassigned logical addresses 116 on the virtual pool volume 112 is allocated.

[0102] (S1402) Chunks 115 "A", "B", and "C", which are allocated on the virtual pool volume 112 so that their logical addresses are consecutive, are transferred from the cache area 160 to the buffer area 170 so that the actual data is also in the same order as the allocation.

[0103] (S1403) Node #1 requests a write to the normal volume 113 on Node #2, which is the external destination of the virtual pool volume 112. In Figure 14, chunks 115 "A", "B", and "C" on the buffer area 170 are written as a single data unit. In other words, the writes between Node 100, which are performed for each chunk 115, are combined into one by assigning a consecutive logical address on the virtual pool volume 112. When Node #2 receives the write request to the normal volume 113, it stores the data in the cache area 160 and responds to Node #1 that the write is complete.

[0104] (S1404) Similar to the explanations in Figures 12 and 13, hash values ​​are created from chunks 115 "A", "B", and "C", and a search for duplicates is performed. Figure 14 shows that, assuming there is no duplicate data, consecutive unassigned logical addresses 116 on pool volume 111 are assigned to chunks 115 "A", "B", and "C". The assignment of logical addresses on pool volume 111 is done by appending. Normally, when a write (update write) is performed on an assigned logical address 117 on volume 113, the assigned logical address 117 on pool volume 111 becomes an invalid area (garbage) while remaining in an assigned state, and the area is freed by an invalid area recovery process called garbage collection, becoming an unassigned logical address 116.

[0105] This allows writing data from multiple chunks, each with its own hash value, to the same destination using a single write request.

[0106] Figure 16 is a flowchart illustrating an example of the processing procedure for write operations on the front-end side. Specifically, it shows the flowchart of the front-end write operation from node 100 (node ​​#1), which receives a write request from host computer 20, to returning a successful write response to host computer 20.

[0107] When a write request is received, the write program 151 is executed to check whether the data for the destination address is cached in the cache area 160, or in other words, whether the data for the destination address is stored in the cache area 160 (i.e., whether it is a cache hit) (step S1601).

[0108] If there is no cache hit (NO in step S1601), the write program 151 allocates a cache area for the write data (step S1602) and transfers the write data to that cache area (step S1603). On the other hand, if there is a cache hit (YES in step S1601), the write program 151 skips step S1602 and transfers the write data to the corresponding cache area (step S1603). Note that the data cached in the cache area 160 (dirty data) is appended with information about the write request received from the host computer 20 (volume ID, logical address, data length).

[0109] Then, the write program 151 returns a good response to the write request to the host (step S1604), and the write process at the front end is terminated.

[0110] Figure 17 shows back This flowchart shows an example of the write processing procedure on the end side. Specifically, it shows the flowchart of the backend write processing performed at node 100 (node ​​#1 and node #2) after a successful response is returned to the host computer 20.

[0111] The write program 151 executes the backend write process. The backend write process may be started in sync with the completion of the frontend write process, or it may be started asynchronously or periodically.

[0112] In step S1701, the write program 151 checks whether dirty data exists on the volume (virtual volume 114 or normal volume 113). If dirty data exists (YES in step S1701), the program proceeds to step S1702; if dirty data does not exist (NO in step S1701), the process terminates.

[0113] In step S1702, the write program 151 creates hash values ​​for each chunk of 115 from the dirty data and proceeds to step S1703.

[0114] In step S1703, the write program 151 checks the volume ID assigned to the dirty data and refers to the volume management table 141 to obtain the matching volume ID 1411 and the corresponding volume type 1414. If volume type 1414 is virtual volume 114 (YES in step S1703), proceed to step S1704; otherwise, proceed to step S1708.

[0115] In step S1704, the write program 151 selects the virtual pool volume 112 to write the data to. Specifically, the write program 151 refers to the data distribution destination management table 142, compares the hash value created in step S1702 with the hash value range 1422, and obtains the corresponding data distribution destination volume ID 1421. Note that there may be multiple data distribution destination volumes corresponding to the hash value range 1422 in the data distribution destination management table 142. If there are multiple volumes, the program checks the capacity 1412 and usage 1413 in the volume management table 141 and selects the volume with the least free space.

[0116] In step S1705, the write program 151 assigns a logical address for writing to the selected virtual pool volume 112. Specifically, the write program 151 refers to the free space management table 143 and searches for a row with volume ID 1431 corresponding to the data distribution destination volume ID 1421 obtained in step S1704, and with status 1433 of "0: Free". The write program 151 updates the status 1433 of the searched row from "0: Free" to "1: Allocated", thereby assigning logical address 1432 on the virtual pool volume 112, which will be the destination for writing the data. Note that the method for searching for free space on the virtual pool volume 112 is not limited to the implementation method of this embodiment. For example, the search may be made more efficient by using a pointer to the search position for each volume, or by managing a specific range of contiguous free space in the form of a list or the like.

[0117] In step S1706, the write program 151 refers to the bounding volume management table 147 and obtains the bounding node number 1472 and bounding volume ID 1473 corresponding to the volume ID 1471 of the virtual pool volume 112. The write program 151 requests a write to the obtained bounding node number 1472 and bounding volume ID 1473, specifying the logical address 1432 on the aforementioned virtual pool volume 112. As explained in Figure 14, the write may be performed for each chunk 115, or multiple consecutive chunks 115 may be written together. Also, the bounding node 100 specified by bounding node number 1472 may be the same as the source requesting the write, or it may be a different node 100.

[0118] In response to a write request from the write program 151 to the external node 100, the external node 100 performs the front-end write processing described in Figure 16 and returns a successful response (Good response).

[0119] In step S1707, the write program 151 updates the logical address translation table 144. Specifically, the write program 151 registers the assigned volume ID 1444 and assigned logical address 1445 as the data storage destination for the volume ID 1441 and logical address 1442 that received the write request, and sets the status 1443 to "1: Assigned". This associates the logical address of the volume that received the write request from the host computer 20 with the logical address of the volume that was assigned as the data storage destination within node 100.

[0120] When the update of the logical address translation table 144 in step S1707 is complete, the backend write process is completed. Note that if an update write is performed when data has already been written to the virtual volume 114 (not shown), the allocated logical address on the virtual pool volume 112, which was the allocation destination before the update, must be released after the write process is complete (i.e., the status 1433 of the free space management table 143 is updated to "0: free").

[0121] Step S1708 is a determination regarding the volume movement process, which will be explained in detail later. If the volume has not been moved, step S1708 will be NO, so step S1709 will be skipped and the process will proceed to S1710. This case will be explained below.

[0122] In step S1710, the write program 151 searches for duplicate data using hash values ​​created from the dirty data for each chunk 115. Specifically, the write program 151 refers to the hash value management table 146 and checks if a matching hash value 1461 is registered. If a matching hash value 1461 is registered, it obtains the volume ID 1462 and logical address 1463 corresponding to that hash value as information for the mapping destination.

[0123] In step S1711, the process is switched depending on the result of step S1710. If a duplicate is found in step S1710 (YES in step S1711), proceed to step S1707; if no duplicate is found (NO in step S1711), proceed to step S1712.

[0124] In step S1712, the write program 151 selects the pool volume 111 and the logical address of the data storage destination. Specifically, the write program 151 selects the pool volume 111 with the same pool ID 1415 as the volume to be written to from the volume management table 141, and allocates the free space of that pool volume 111. The allocation of free space is performed by appending, as explained in Figure 14. The allocation of free space in appending is performed by advancing the pointer (not shown) of the logical address indicating the end of the write destination.

[0125] In step S1713, the write program 151 registers the hash value and information about the pool volume 111 allocated in step S1712 and the logical address of the storage destination into the hash value management table 146, specifically into hash value 1461, volume ID 1462, and logical address 1463. The hash value management table 146 may take the form of a B-tree or other structure to speed up searching and registration, and is not limited to the implementation method of this embodiment.

[0126] As described above, the write process enables the storage system 10 to perform data deduplication across nodes 100. Note that the storage system may contain virtual volumes to which the deduplication function is not applied. In this case, data written to virtual volumes to which the deduplication function is not applied is stored in the pool volume 111. In other words, only the thin provisioning function is applied to the virtual volumes.

[0127] (1-3-2) Read Processing Figure 18 is a flowchart showing an example of the processing procedure for read processing.

[0128] When a read request is made for data on a volume (virtual volume 114 or normal volume 113), the read program 152 is executed.

[0129] Specific examples are shown below.

[0130] According to Figure 18, first, the read program 152 receives a read request (step S1801).

[0131] Next, the read program 152 performs a cache hit / miss determination to determine whether the data to be read is stored in the cache area 160 (step S1802). If the data to be read is a cache hit (Hit in step S1802), the read program 152 transfers the cache hit data to the host (step S1807) and terminates the read process. On the other hand, if the data to be read is a cache miss (Miss in step S1802), the process proceeds to step S1803.

[0132] In step S1803, the read program 152 refers to the read target area of ​​the logical address translation table 144 and obtains the data allocation destination volume ID 1444 and the allocation destination logical address 1445.

[0133] In step S1804, the read program 152 checks whether the assigned volume ID 1444 obtained in step 1803 is virtual pool volume 112 by referring to the volume management table 141. If volume type 1414 is a virtual pool volume (step S1804 is YES), the program proceeds to step S1805; otherwise, it proceeds to step S1808.

[0134] In step S1805, the read program 152 refers to the external volume management table 147 and obtains the external node number 1472 and external volume ID 1473 corresponding to the volume ID 1471 of the allocated volume. The read program 152 makes a read request by specifying the obtained node and volume, as well as the logical address on the virtual pool volume 112. The node 100 that receives the read request similarly performs the read process shown in Figure 18. When the read program 152 receives data from the requesting party of the read request, it proceeds to step S1806.

[0135] In step S1806, the read program 152 stages the data received from the requesting party of the read request onto the cache area 160 (i.e., transfers it to the cache area 160), proceeds to step S1807, and transfers the data to the requesting party of the read request to terminate the process.

[0136] In step S1808, which is executed when the read target is not the virtual pool volume 112, the read program 152 reads the data on the drive 12 within its own node 100 corresponding to the assigned logical address 1445 obtained in step S1803 and stages it on the cache area 160. Once staging is complete, the read program 152 proceeds to step S1807, transfers the data to the source of the read request, and terminates the process.

[0137] For example, if the process in Figure 18 is executed by node 100 which received a read request from host computer 20, the destination of the data in step S1807 will be the host computer 20. On the other hand, if the process in Figure 18 is executed by the external node 100 which received the read request sent in step S1805, the destination of the data in step S1807 will be the node 100 which sent the read request. In the latter case, node 100 which sent the read request stages the data transferred from the external node in step S1806.

[0138] As described above, the read operation is performed, enabling the storage system 10 to read data from its own node and to read data via the externally connected node.

[0139] (1-3-3) Volume transfer process Below, the volume transfer process will be explained using the processing image shown in Figure 15 and the flowcharts shown in Figures 19 and 20. Furthermore, the process for when a write request is received during volume transfer will be explained using Figure 17.

[0140] Figure 15 shows an image illustrating the processing steps for volume movement.

[0141] The volume relocation process is requested by the management server 21 (not shown) when a capacity rebalance occurs due to the addition of node 100 to the storage system 10. The volume relocation process may also be performed when node 100 is replaced or when node 100 is removed. The volumes to be relocated may be specified by the user or automatically by the program. In this embodiment, the management server 21 manages the volume placement for each node 100, and the management server 21 selects the volumes to be moved and requests processing from each node.

[0142] Volume transfers between nodes 100 can involve either transferring a virtual volume 114 or transferring a regular volume 113. Since virtual volume 114 does not contain any physical data and its transfer does not change the capacity between nodes, it is not included in capacity rebalancing. Note that virtual volume 114 may be transferred to change the node 100 to which the host computer 20 is connected. In this embodiment, the case of transferring a regular volume 113 for the purpose of rebalancing the capacity between nodes 100 is illustrated, and Figure 15 shows the case of transferring regular volume #2 from node #3 to node #4.

[0143] When moving a volume, a normal volume #3 of the same size as the source normal volume #2 is created in advance at the destination node #4 according to instructions from the management server 21 (step S1501).

[0144] Next, the management server 21 requests a copy of the data from node #3, and the data is copied between the source normal volume #2 and the destination normal volume #3 (step S1502).

[0145] Once the data copy is complete, the management server 21 instructs node #2 to switch the external destination, and the connection destination of virtual pool volume #2, which is normally connected to volume #2, is switched to the destination normal volume #3 (step S1503).

[0146] Once the switchover is complete, the management server 21 instructs the system to delete the source volume, and the volume transfer is completed by deleting the normal volume #2 on node #3 (step S1504).

[0147] Figure 19 is a flowchart showing an example of the procedure for copying volume data during volume migration.

[0148] Specific examples are shown below.

[0149] When the management server 21 requests a copy of data, the volume transfer program 153 is executed. The volume transfer program 153 receives the source volume ID, destination node number, and destination volume ID included in the copy request (step S1901).

[0150] In step S1902, the volume move program 153 updates the volume move instruction 1482 on the volume move management table 148 corresponding to the volume to be moved to "yes", and sets the destination node number 1483 and destination volume ID 1484 with the information received in step S1901.

[0151] In step S1903, the volume transfer program 153 stages the data from the source volume onto the cache area 160. The staging is performed by grouping multiple chunks 115, such as slots, starting from the logical address at the beginning of the volume. The staging is carried out by the read process described in Figure 18.

[0152] In step S1904, the volume transfer program 153 writes the data staged in step S1903 to the destination volume on the destination node. The write request is made by combining multiple chunks 115, such as slots, starting from the logical address at the beginning of the volume. The write is performed by the write process described in Figure 17.

[0153] In step S1905, the volume transfer program 153 updates the progress pointer address 1485 of the volume transfer management table 148 by advancing the address by the size written in step S1904.

[0154] In step S1906, the volume transfer program 153 determines whether the progress pointer address 1485 in the volume transfer management table 148 is the end of the volume by referring to the capacity 1412 in the volume management table 141. Note that if there is no data allocated in the source volume, copying the data to the destination is unnecessary, so the copy of unnecessary data (zero data) may be omitted by using the usage 1413 in the volume management table 141 or management information for large data allocation units called pages. If the volume transfer program 153 determines that it is the end of the volume (YES in step S1906), the process ends. If it is not the end of the volume (NO in step S1906), the process returns to step S1903 to process the remaining data. Note that if the inter-volume copy process shown in Figure 19 terminates abnormally for any reason, the program can be restarted and the copy process can be resumed from the address indicated by the copy pointer.

[0155] Figure 20 is a flowchart illustrating an example of the procedure for switching the external volume after the data copy between volumes is completed during volume migration.

[0156] Specific examples are shown below.

[0157] The management server 21 instructs node 100, to which the virtual pool volume 112, whose external destination is the source volume, belongs, to switch the external destination. When node 100 receives the instruction to switch the external destination, the volume move program 153 is executed. The volume move program 153 receives the source volume ID, destination node number, and destination volume ID included in the external destination switch instruction (step S2001).

[0158] The volume transfer program 153 finds the destination volume ID 1473 in the destination volume management table 147 that matches the source volume ID, and updates the found destination volume ID 1473 and its corresponding destination node number 1472 with the destination volume ID and destination node number received in step S2001, respectively (step S2002).

[0159] Refer to Figure 17 for a detailed explanation of the procedure for writing data while a data copy is being performed between volumes.

[0160] Specific examples are shown below.

[0161] If a backend write operation is performed during volume transfer (data copying), it is necessary to prevent data inconsistencies caused by discrepancies with the copy operation. In this embodiment, in step S1708, the write program 151 refers to the volume transfer management table 148 and determines whether a write to the destination volume is necessary based on the status of the volume transfer instruction 1482. If the volume transfer instruction 1482 is "present" (YES in step S1708), the program proceeds to step S1709 and requests a write to the destination volume. If the volume transfer instruction 1482 is "absent" (NO in step S1708), the program proceeds to step 1710.

[0162] Through the above process, when a write operation is performed during data copying, the write is reflected on both the source and destination volumes, preventing data inconsistencies.

[0163] As described above, the storage system 10 according to this embodiment, in a loosely coupled scale-out architecture with multiple nodes clustered together, enables data movement on a volume basis by establishing a one-to-one mapping between virtual pool volumes 112 and normal volumes 113 among nodes 100, while maintaining the reduction effect of distributed deduplication between nodes. This eliminates the need for chunk-based processing required in conventional technologies when rearranging data, thereby shortening the processing time for data rearrangement and improving the scalability of the scale-out storage.

[0164] (2) Second embodiment In the first embodiment, when allocating logical addresses on the virtual pool volume 112, the free space management table 143 is referenced to search for free space in chunks 115. However, this method may increase the search load as the amount of free space decreases. Therefore, in the second embodiment, a storage system is described that always secures contiguous free space by allocating logical addresses on the virtual pool volume 112 by appending.

[0165] Figure 21 shows a storage system according to a second embodiment of the present invention. 10 This figure shows an example of the procedure for assigning logical addresses during writing. Storage system according to the second embodiment 10 Since the system configuration is the same as that of the storage system 10 according to the first embodiment, the same reference numerals are used and their description is omitted.

[0166] Specific examples are shown below.

[0167] (S2101) For each chunk 115, a virtual pool volume 112 is selected according to the hash value created. Once a virtual pool volume 112 is selected, a logical address is allocated on the virtual pool volume 112 by appending. An append pointer (not shown) indicating the end of an allocated address on the virtual pool volume 112 is referenced, and the consecutive unallocated logical addresses 116 following the append pointer are allocated. Note that if an allocated logical address 117 on the virtual volume 114 is written (update write), the allocated logical address 117 on the virtual pool volume 112 becomes invalid area (garbage) while remaining allocated. The area that has become garbage is freed by garbage collection, which is executed asynchronously with the write process, and becomes an unallocated logical address 116. In Figure 21, when chunks 115 "A", "B", and "C" are written, consecutive unallocated logical addresses 116 on the virtual pool volume 112 are allocated by appending.

[0168] (S2102) Chunks 115 "A", "B", and "C" on the virtual pool volume 112, which are allocated so that their logical addresses are consecutive, are transferred from the cache area 160 to the buffer area 170 so that the actual data is also in the same order as the allocation.

[0169] (S2103) Node #1 requests a write to the normal volume 113 on Node #2, which is the external destination of the virtual pool volume 112. In Figure 21, as in the first embodiment, chunks 115 "A", "B", and "C" on the buffer area 170 are written as a single data. The writes between Node 100, which are performed for each chunk 115, are combined into one by assigning consecutive logical addresses on the virtual pool volume 112. When Node #2 receives a write request to the normal volume 113, it stores the data in the cache area 160 and responds to Node #1 that the write is complete.

[0170] (S2104) A hash value is created from chunks 115 "A", "B", and "C", and a duplicate search is performed. Figure 21 shows that, assuming there is no duplicate data, consecutive unassigned logical addresses 116 on pool volume 111 are assigned to chunks 115 "A", "B", and "C". The assignment of logical addresses on pool volume 111 is done by appending, in the same way as with virtual pool volume 112. Normally, when a write (update write) is performed on an assigned logical address 117 on volume 113, the assigned logical address 117 on pool volume 111 becomes an invalid area (garbage) while remaining in an assigned state, and the area is freed by garbage collection, which is executed asynchronously with the write process, and becomes an unassigned logical address 116.

[0171] As described above Second embodiment Storage system 10 This system ensures a continuous supply of free space by assigning logical addresses on virtual pool volume 112 via appending, and frees up allocated space by performing garbage collection at a time asynchronous to write operations (such as during periods of low I / O load). Furthermore, the impact of garbage collection on I / O performance can be controlled by changing the trigger for garbage collection according to conditions such as the amount of garbage, free space, and I / O load.

[0172] ( 3 )Third Embodiment In the first and second embodiments, data is stored on drive 12 after deduplication, and the I / O throughput of the storage system 10 may be limited by the processing speed of deduplication. When high I / O throughput is required, such as when the I / O load is high, it is necessary to change the trigger for executing deduplication (make it I / O asynchronous).

[0173] Figure 22 shows a storage system according to a third embodiment of the present invention. 10 This figure shows the processing procedure for write operations. Storage system according to the third embodiment. 10 The system configuration is the same as that of the storage system 10 according to the first embodiment, so the same reference numerals are used and their description is omitted. In this embodiment, the process image shows that node #1, which receives a write request from the host computer 20, stores the data in drive 12 and allocates the data to node #2 asynchronously for deduplication.

[0174] Specific examples are shown below.

[0175] (S2201) Node #1 is connected to host computer 20 storage A write request to virtual volume 114 is received via network 30. The write request includes the data and the logical address to which the data will be allocated. Upon receiving the write request, node #1 allocates space on cache area 160 for writing the data and writes the data to the allocated space. After the controller 11 of node #1 receives the write request and writes the data to cache area 160, it makes the data on the cache redundant with another controller 11 within node #1 and responds to the host computer 20 that the write process is complete.

[0176] (S2202) Node #1 skips creating the hash value because it will asynchronously select virtual pool volume 112 using the hash value.

[0177] (S2203) Node #1 allocates pool volume 111 as the storage location for chunk 115 "D". In this embodiment, the logical address of the allocated pool volume 111 is determined by appending data.

[0178] (S2204) When a logical address is assigned on pool volume 111, node #1 transfers chunk 115 "D" on cache area 160 to the corresponding area on drive 12.

[0179] (S2205) Node #1 is an I / O asynchronous line When triggered (for example, when the I / O load is low or when the system is periodically activated), chunk 115 allocated to pool volume 111 is read into buffer area 170, and a hash value is created using a hash algorithm. In Figure 22, the hash value "h(D)" is created from chunk 115 "D".

[0180] (S2206) Node #1 selects a storage location for chunk 115 "D" from one or more virtual pool volumes 112. The virtual pool volume 112 has a pre-configured range of hash values ​​for the data to be stored (for example, h(D) to h(F)), and selects the virtual pool volume 112 with the hash value range corresponding to the aforementioned hash value "h(D)" as the storage location.

[0181] (S2207) To the normal volume 113 on node #2, which is the destination (i.e., the external destination) of the virtual pool volume 112, from node #1 storage A write request is made via network 30. The write request includes chunk 115 "D" on buffer area 170 of node #1 and the same logical address as the allocation destination of virtual pool volume 112. When node #2 receives the write request, it allocates space on cache area 160 for writing the data, and the data is written to the allocated space. Similar to node #1, node #2 also has redundant data on the cache and responds to node #1, the originator of the write request, with confirmation that the write process is complete.

[0182] (S2208) Once the write operation to the normal volume 113 on node #2 is complete, the logical address translation table 144 is updated to map the logical address on the virtual pool volume 112.

[0183] (S2209) Node #2 creates a hash value from chunk 115 written to the cache area 160 of node #2. Similar to node #1, the hash value "h(D)" is created from chunk 115 "D".

[0184] (S2210) Node #2, if the received request is a write to volume 113, uses the generated hash value to search for duplicate data. Figure 22 shows the case where there is no duplicate data, and pool volume 111 is allocated as the storage location for chunk 115.

[0185] (S2211) When a logical address is assigned on pool volume 111, node #2 transfers chunk 115 "D" on cache area 160 to the corresponding area on drive 12.

[0186] As described above Third Embodiment Storage system 10 By making the deduplication process asynchronous to I / O, the deduplication process can be executed at any desired time. In this embodiment, deduplication is performed only on the external node #2, but a combination of performing deduplication within node #1, then transferring the data to the external node #2 and performing deduplication again is also possible. Furthermore, deduplication at each node and data transfer between nodes may be performed at any time depending on conditions such as the I / O load and capacity consumption of each node, and may also be controlled according to conditions other than those within the node, such as network bandwidth and IOPS.

[0187] For example, node 100 may determine whether data reduction rate or throughput performance takes priority based on predetermined conditions. If it determines that data reduction rate takes priority, it may execute the write process of the first embodiment shown in Figure 12. If it determines that throughput performance takes priority, it may execute up to step S2205 of the write process of the third embodiment shown in Figure 22. In the latter case, node 100 may execute steps S2206 and beyond after executing step S2205, if predetermined conditions for performing deduplication are met.

[0188] Alternatively, node 100 may execute the processes up to step S1205 in Figure 12, regardless of whether data reduction rate or throughput performance is prioritized. If data reduction rate is prioritized, it may continue to execute the processes from step S1206 onward. If throughput performance is prioritized, it may allocate the data to pool volume 111 and store the data without performing deduplication in step S1206. In the latter case, node 100 may read the data stored in pool volume 111 and perform deduplication in step S1206 when predetermined conditions for performing deduplication are met after storing the data in pool volume 111.

[0189] The predetermined conditions for performing the above deduplication may be any or a combination of the following: the I / O load of each node 100 is lower than a predetermined standard, the consumed capacity is higher than a predetermined condition, the bandwidth of the storage network 30 is wider than a predetermined standard, or the throughput (IOPS) is higher than a predetermined standard. Alternatively, whether or not the data reduction rate is prioritized may be determined based on the same conditions as above.

[0190] This allows for processing that prioritizes either data reduction rate or throughput performance depending on the conditions, and enables deduplication at a time that is less likely to affect throughput performance.

[0191] It should be noted that the present invention is not limited to the embodiments described above, and various modifications are included. For example, the embodiments described above are explained in detail for a better understanding of the present invention, and are not necessarily limited to those having all of the configurations described. Furthermore, it is possible to replace parts of the configuration of one embodiment with the configuration of another embodiment, and it is possible to add configurations from other embodiments to the configuration of one embodiment. In addition, it is possible to add, delete, or replace parts of the configuration of each embodiment with other configurations.

[0192] Furthermore, each of the above configurations, functions, processing units, and processing means may be implemented in hardware, either partially or entirely, by designing them as integrated circuits, for example. Alternatively, each of the above configurations and functions may be implemented in software by a processor interpreting and executing programs that implement each function. Information such as programs, tables, and files that implement each function can be stored in storage devices such as non-volatile semiconductor memory, hard disk drives, and SSDs (Solid State Drives), or in computer-readable non-temporary data storage media such as IC cards, SD cards, and DVDs.

[0193] Furthermore, the control lines and information lines shown are those deemed necessary for explanation purposes, and do not necessarily represent all control lines and information lines in the actual product. In practice, it can be assumed that almost all components are interconnected. [Explanation of Symbols]

[0194] 10 Storage Systems 11 Controllers 12 physical drives 13 processors 14 memory 15 Front-end IF 16 Backend IF 20 Host Computers 21 Management Server 30 Storage Networks 100 nodes 110 Pools 111 Pool Volume 112 Virtual Pool Volumes 113 Normal Volume 114 Virtual Volumes 115 chunks 116 Unassigned logical address 117 Assigned Logical Addresses 140 Control Information Area 141 Volume Management Table 142 Data Distribution Destination Management Table 143 Free Space Management Table 144 Logical Address Translation Table 145 Pool Management Table 146 Hash value management table 147 External Volume Management Table 148 Volume migration management table 150 Program Areas 151 Light Program 152 Lead Program 153 Volume Movement Program 160 cache area 170 buffer area

Claims

1. A storage system in which multiple nodes are connected to each other, Each of the aforementioned nodes is, The pool and, A volume associated with the storage area of ​​the aforementioned pool, A processor that processes data input to and output from the volume and pool, Equipped with, Upon receiving the write request, the processor Identification information is created from the data related to the aforementioned write request, and the node to store the data is determined based on the range to which the value of the created identification information belongs. The processor of the node determined to be the node that stores the aforementioned data is: The data relating to the aforementioned write request is acquired, deduplication is performed using the identification information, and the data is stored in the pool of the node. A storage system characterized by the following features.

2. A storage system according to claim 1, The pool includes pool volumes mapped to physical drives that store data, and virtual pool volumes mapped to the volumes on other nodes. The processor stores data that it has determined to be stored on its own node based on the identification information in the pool volume, and data that it has determined to be stored on another node based on the identification information in the virtual pool volume, and then transfers the data to the other node. A storage system characterized by the following features.

3. A storage system according to claim 2, Multiple virtual pool volumes are created for each volume on the other node to which they are mapped. A storage system characterized by the following features.

4. A storage system according to claim 3, The aforementioned processor, If it is determined that the data relating to the write request should be stored on the local node based on the identification information, the data should be stored on the pool volume; if it is determined that the data should be stored on another node, the data should be stored on the virtual pool volume mapped to the volume of the other node. A storage system characterized by the following features.

5. A storage system according to claim 2, The aforementioned deduplication is performed on data stored in the pool volume on the same node. A storage system characterized by the following features.

6. A storage system according to claim 1, The aforementioned identification information is created by modulo operation. A storage system characterized by the following features.

7. A storage system according to claim 2, The aforementioned identification information is a hash value created using a hash function, A range of hash values ​​for determining the node where the data will be stored is allocated to the virtual pool volume. A storage system characterized by the following features.

8. A storage system according to claim 4, The volume includes a virtual volume accessed by the host and a regular volume mapped to the virtual pool volume. The aforementioned processor, The node that creates and stores the identification information from the data received on the virtual volume is determined. Data received from other nodes on the regular volume is stored on the physical drive via the pool volume. A storage system characterized by the following features.

9. A storage system according to claim 8, The aforementioned virtual pool volume includes a virtual pool volume mapped to the aforementioned regular volume mapped to the same node, Based on the aforementioned identification information, the data that is determined to be stored on the local node is stored in the pool volume via the virtual pool volume and the normal volume. A storage system characterized by the following features.

10. A storage system according to claim 2, In a virtual pool volume mapped to the volume on the other node, when moving data from the volume on the other node to the volume on a node different from the other node, the mapping destination of the virtual pool volume is switched from the volume on the source node to the volume on the destination node. A storage system characterized by the following features.

11. A storage system according to claim 2, The aforementioned processor determines whether to prioritize data reduction rate or throughput performance. Upon receiving the write request, the processor If data reduction rate is prioritized, the node to store the data is determined based on the range to which the value of the identification information belongs, and the data is stored in the pool volume or the virtual pool volume mapped to the volume of another node. If throughput is prioritized, the data will be stored in the pool volume without performing a determination of the node to store the data based on the range to which the value of the identification information belongs. A storage system characterized by the following features.

12. A distributed deduplication method using a storage system in which multiple nodes are connected to each other, Each of the aforementioned nodes is, The pool and, A volume associated with the storage area of ​​the aforementioned pool, A processor that processes data input to and output from the volume and pool, Equipped with, The aforementioned distributed deduplication method is: The process includes: the processor receiving a write request creates identification information from the data related to the write request, and determines the node to store the data based on the range to which the value of the created identification information belongs; The procedure includes: the processor of the node determined to be the node for storing the data acquires the data relating to the write request, performs deduplication using the identification information, and stores it in the pool of the node. A distributed deduplication method characterized by the following:

Images