Storage system and storage management method

Abstract

The ability to maintain policies even when creating clones using virtual copies. [Solution] The controller is capable of performing a virtual copy cloning process, which creates a clone volume by creating a virtual copy that shares data with an existing volume, and a physical copy cloning process, which creates a clone volume by physically copying data from the existing volume. Based on the number of existing and new clone volumes, and the upper limit of the number of clone volumes that can be created by the virtual copy cloning process, the controller decides whether to perform the virtual copy cloning process or the physical copy cloning process and executes it accordingly.

Description

Technical Field

[0001] The present invention relates to a storage system and a storage management method, and is suitable for application to a storage system related to a technique for creating a clone volume by virtual copy, for example.

Background Art

[0002] In recent storage systems, as a method for accelerating data copying, there is a method of updating only metadata as a pointer indicating the storage location of the data without actually copying the data. Hereinafter, this method is also referred to as "RoW (Redirect-on-Write)". By using RoW, a snapshot can be created for data at a certain point in time.

[0003] For example, a storage system that uses a function called SPBM (Storage Policy Based Management) automatically creates a virtual volume that satisfies a policy on the storage system by setting a policy when creating a virtual machine (hereinafter also abbreviated as "VM"). The storage system needs to create a virtual volume that satisfies the policy specified by the VM administrator and continue to maintain that policy thereafter. Such a policy includes, for example, a snapshot policy. Examples of the snapshot policy include a snapshot period, a snapshot retention period, and the like. Patent Document 1 discloses a technique for creating and using a clone volume without physical copying.

Prior Art Documents

Patent Documents

[0004]

Patent Document 1

Summary of the Invention

[0005] However, the technology disclosed in Patent Document 1 had the potential to fail to maintain policies after creating a clone volume without a physical copy.

[0006] This invention was made in consideration of the above points, and aims to propose a storage system and storage management method that can always maintain policies even when creating clone volumes using virtual copies. [Means for solving the problem]

[0007] To solve these problems, the present invention provides a storage system comprising a drive for physically storing data and at least one controller that provides a volume to a host computer and controls the input / output processing of data via the volume, wherein the controller is capable of performing a virtual copy clone creation process, which creates a clone volume by a virtual copy that shares data with an existing volume, and a physical copy clone creation process, which creates a clone volume by physically copying data from the existing volume, and estimates the number of clone volumes to be created by the virtual copy clone creation process, and determines and performs either the virtual copy clone creation process or the physical copy clone creation process based on the number of existing and created clone volumes and the upper limit of the number of clone volumes that can be created by the virtual copy clone creation process.

[0008] Furthermore, the present invention relates to a storage management method for a storage system comprising a drive for physically storing data and at least one controller that provides a volume to a host computer and controls data input / output processing via the volume, wherein the controller is capable of performing a virtual copy clone creation process, which creates a clone volume by a virtual copy that shares data with an existing volume, and a physical copy clone creation process, which creates a clone volume by physically copying data from the existing volume, and determines and performs either the virtual copy clone creation process or the physical copy clone creation process based on the number of existing and created clone volumes, and the upper limit of the number of clone volumes that can be created by the virtual copy clone creation process. [Effects of the Invention]

[0009] According to the present invention, policies can always be maintained even when creating clone volumes using virtual copies. [Brief explanation of the drawing]

[0010] [Figure 1] This is a system configuration diagram showing an example of the overall configuration of the information processing system according to this embodiment. [Figure 2] Figure 1 is a system configuration diagram showing an example of the software configuration of the storage node. [Figure 3] Figure 2 is a software configuration diagram showing an example of the contents of the memory of the storage node. [Figure 4] Figure 3 is a diagram illustrating the configuration of the virtual volume management table. [Figure 5] This is an illustrative diagram showing an example configuration of a virtual volume snapshot and a virtual clone tree according to this embodiment. [Figure 6] Figure 3 shows an example of the configuration of the policy management table. [Figure 7] Figure 3 is a diagram showing the configuration of the volume management table. [Figure 8] It is a diagram showing a configuration example of a snapshot / virtual clone management table shown in FIG. 3. [Figure 9] It is a diagram showing a configuration example of a local copy management table shown in FIG. 3. [Figure 10] It is a diagram showing a configuration example of a volume migration management table shown in FIG. 3. [Figure 11] It is a flowchart showing an example of a storage management method including virtual volume clone processing and policy change processing according to this embodiment. [Figure 12] It is a flowchart showing an example of the procedure of virtual volume clone processing shown in FIG. 11. [Figure 13] It is a flowchart showing an example of the procedure of snapshot policy maintainability check processing shown in FIG. 12. [Figure 14] It is a flowchart showing an example of the procedure of virtual copy clone creation processing shown in FIG. 12. [Figure 15] It is a flowchart showing an example of the procedure of local copy clone creation processing shown in FIG. 12. [Figure 16] FIG. 16 is a flowchart showing an example of the procedure of policy change processing shown in FIG. 12. [Figure 17] It is a flowchart showing an example of the procedure of snapshot policy maintainability check processing in the policy change processing shown in FIG. 11. [Figure 18] It is a flowchart showing an example of the procedure of volume migration processing shown in FIG. 16.

Embodiments for Carrying Out the Invention

[0011] Hereinafter, based on the drawings, the present embodiment of the present invention will be described in detail. Note that the embodiments described below do not limit the invention according to the claims, and not all of the elements and combinations thereof described in the embodiments are essential for the solution means of the invention.

[0012] In the following description, information may be described in terms of the "AAA table", but the information may be represented in any data structure. That is, in order to indicate that the information is independent of the data structure, the "AAA table" can be referred to as "AAA information".

[0013] Also, in the following description, the processing may be described with the program as the main entity of operation. However, the program is executed by a processor (e.g., a CPU (Central Processing Unit)) to perform the defined processing while appropriately using a storage resource (e.g., a memory) and / or a communication interface device (e.g., a NIC (Network Interface Card)). Therefore, the main entity of the processing may be the processor. The processing described with the program as the main entity of operation may also be the processing performed by the processor or a computer (system) having the processor.

[0014] Also, in the following description, two or more programs may be realized as one program, or one program may be realized as two or more programs.

[0015] <​​​​A VVOL (Virtual Volume), used as an example of a virtual volume in the following embodiment, is implemented by an SLU (Subsidiary Logical Unit), which is a logical unit (LU) specified in the Conglomerate LUN structure, a SCSI (Small Computer System Interface) architecture model, and may be referred to as SLU. An SLU is a logical unit as a logical storage area based on the physical storage area of ​​a storage device, and is accessed from the host by setting a connection relationship (binding) with a volume called an ALU (Administrative Logical Unit), which is the entry point for host access (IO requests). An ALU may also be called a PE (Protocol Endpoint). Note that SLUs and ALUs may be implemented as the aforementioned logical volumes.

[0017] Figure 1 is a system configuration diagram showing an example of the overall configuration of the information processing system 1 according to this embodiment. The information processing system 1 comprises a storage system 1000 and a host computer 200. The storage system 1000 comprises one or more storage nodes 100. The storage system 1000 may also be called a storage cluster.

[0018] The storage node 100 and the host computer 200 are connected to each other via a network 300, and can exchange data, etc. The network 300 may be, for example, a LAN (Local Area Network), a WAN (Wide Area Network), etc.

[0019] The storage node 100 is a device that provides storage space for reading and writing data to the host computer 200. The storage node 100 may be a physical computer or a virtual computer.

[0020] The storage system 1000 includes an API server that accepts API (Application Programming Interface) requests for management operations such as creating virtual volumes from the host computer 200. The API server may be implemented within the storage node 100. Alternatively, the API server may be implemented on a separate server (computer) that can communicate with both the storage node 100 and the host computer 200. In the following embodiments, the case where the API server is implemented within the storage node 100 will be described as an example.

[0021] The host computer 200 is a computer that sends read / write requests to the storage system 1000 in response to user operations or requests from application programs (e.g., file server programs, database server programs). Hereinafter, these read / write requests will be referred to as I / O (Input / Output) requests. The host computer 200 may be a physical computer, a virtual computer (hereinafter also referred to as "VM"), or a configuration in which one or more virtual machines are built within the host computer 200. For example, if multiple storage nodes 100 constitute a cluster, the host computer 200 will be configured with multipathing between the storage nodes constituting the cluster. Multipathing can be configured, for example, using multipath-tools when using Linux®. On the other hand, if the host computer 200 is, for example, Windows Server®, multipathing can be configured using the MPIO (MultiPath Input / Output) service. The host computer 200 may be, for example, an on-premises device, or alternatively, a cloud device.

[0022] Figure 2 is a system configuration diagram showing an example of the software configuration of storage node 100 shown in Figure 1. Each storage node 100 includes at least a storage device 130 as an example of a drive on which volumes for physically storing data are created, and at least one controller 111 that controls data input / output processing through the volumes. The controller 111 includes CPUs 110 interconnected via an internal network 150, memory 120, multiple storage devices 130, and a communication interface (hereinafter referred to as "I / F"). Each storage node 100 may have, for example, one or more CPUs 110, memory 120, storage devices 130, and communication interfaces.

[0023] The CPU 110 is a processor that controls the operation of the entire storage node 100. The CPU 110 executes various processes based on programs and management information stored in memory 120. The CPU 110 may be a physical CPU of a physical computer, or it may be a virtual CPU that is virtually allocated using the virtualization function of the cloud.

[0024] Memory 120 is a volatile semiconductor memory such as SRAM (Static Random Access Memory) or DRAM (Dynamic Random Access Memory). Memory 120 stores various programs executed by the CPU 110 and management information referenced or updated by the CPU 110. Memory 120 may be physical memory, or it may be virtual memory created by virtually allocating physical memory using the virtualization function of the cloud.

[0025] The storage device 130 is a storage device that stores user data used by the host computer 200. The storage device 130 may be, for example, a non-volatile storage device. The storage device 130 may be, for example, an HDD (Hard Disk Drive) or an SSD (Solid State Drive). The storage device 130 may be a physical storage device, or instead, it may be a virtual storage device that virtually allocates a physical storage device using the virtualization function of the cloud.

[0026] The communication interface 140 is an interface that allows the storage node 100 to communicate with the host computer 200, other storage nodes 100, and management devices via the network 300. The communication interface 140 is, for example, a NIC (Network Interface Card) or an FC (Fibre Channel) card. The communication interface 140 may be a physical communication interface, or it may be a virtual communication interface that virtually assigns a physical communication interface using the virtualization function of the cloud.

[0027] Figure 3 is a software configuration diagram showing an example of the contents of the memory 120 of the storage node 100 shown in Figure 2. The memory 120 of the storage node 100 stores the API processing unit 1200, the storage control unit 1300, the API management table 1400, and the storage management table 1500.

[0028] The API processing unit 1200 and the storage control unit 1300 may, for example, operate as a program and be implemented together as a single program, or alternatively, as two or more programs.

[0029] The API processing unit 1200 operates, for example, as an API server. The API processing unit 1200 receives API requests for management operations from the host computer 200. Depending on the content of the received API request, the API processing unit 1200 performs internal processing or sends instructions to the storage control unit 1300.

[0030] The API processing unit 1200 includes an API transmission / reception unit 1210, a clone processing unit 1220, and a policy change processing unit 1230. These API transmission / reception unit 1210, clone processing unit 1220, and policy change processing unit 1230 may be in the form of the same program as the API processing unit 1200, or at least some of them may be combined and other parts may be separate and independent. The API processing unit 1200 usually includes a processing unit for creating virtual volumes, and also includes other processing units such as a processing unit for setting the binding between the PE and the virtual volume.

[0031] The API transmission / reception unit 1210 receives instructions from the host computer 200 and passes them to a program that executes processing for those instructions, and also sends the execution result of the program that executes processing for those instructions back to the host computer 200.

[0032] When a virtual volume clone instruction is sent from the host computer 200, the clone processing unit 1220 executes a virtual copy clone creation process to create a clone volume using a virtual copy. The clone processing unit 1220 determines whether it is possible to execute the virtual copy clone creation process and whether it is possible to maintain the snapshot policy as an example of a policy based on the effects after executing the virtual copy clone creation process. Other policies can also include matters related to replication and QoS (Quality of Service).

[0033] Controller 111 has a policy for creating clone volumes, and based on this policy, it estimates the number of clone volumes to be created, and based on the estimated number of clone volumes, the number of existing clone volumes, and the upper limit of the number of clone volumes that can be created by the virtual copy clone creation process, it decides whether to perform the virtual copy clone creation process or the physical copy clone creation process and performs it. A clone is a snapshot. The policy for clone volumes defines the snapshot creation period and retention period. Hereinafter, this policy will also be referred to as the "snapshot policy". Regarding the virtual copy clone creation process, if it is possible to maintain the snapshot policy, the clone volume is created using virtual copies, while if it is not possible to maintain the snapshot policy, the clone volume is created using physical copies.

[0034] The policy change processing unit 1230 executes a policy change process to modify the snapshot policy when a policy change instruction is sent from the host computer 200. The policy change processing unit 1230 dynamically changes the processing behavior related to the virtual copy clone creation process and the policy change process depending on whether the policy change process can be executed and whether the snapshot policy can be maintained due to the effects after the virtual copy clone creation process is executed.

[0035] The policy change processing unit 1230, when performing a policy change, will change the snapshot policy directly if it is possible to maintain the snapshot policy. However, if it is not possible to maintain the snapshot policy, it will migrate one or more volumes belonging to the policy change target volume or the snapshot / virtual clone tree (an example of a tree to which the policy change target volume belongs) to a clone volume created by a physical copy via volume migration, or a clone volume created by a physical copy via a snapshot or virtual copy, before executing the policy change processing. This tree is also referred to as, for example, Family. In this embodiment, a clone volume created by a virtual copy is also referred to as a "virtual clone".

[0036] The policy change processing unit 1230 determines whether the above-mentioned upper limit can be maintained by determining whether the upper limit of the snapshot / virtual clone tree is exceeded, based on the assumed maximum number of snapshots calculated from the snapshot period and snapshot retention period included in the snapshot policy, and the number of clone volumes already created by virtual copying. The clone volume includes virtual clone volumes and snapshot volumes. In this embodiment, virtual clone volumes and snapshot volumes are managed with the same virtual clone tree ID as the volume from which they were created, and the above upper limit is set for the number of volumes having the same virtual clone tree ID.

[0037] If the controller 111 estimates that the number of clone volumes will exceed the above upper limit, it will assign a different virtual clone tree ID to some of the existing or newly created clone volumes that have the same virtual clone tree ID and manage them separately. The controller 111 creates clone volumes using a physical copy clone creation process when it is necessary to create clone volumes using a physical copy clone creation process when it is necessary to create clone volumes using a physical copy clone creation process and manage them separately when it is necessary to create clone volumes using a physical copy clone creation process when it is necessary to create clone volumes using a virtual copy clone creation process and manage them separately.

[0038] The API management table 1400 is a table for managing information used by the API processing unit 1200. The API management table 1400 includes the virtual volume management table 1410 and the policy management table 1420.

[0039] The virtual volume management table 1410 is a table that manages the ID, type, capacity, etc., of virtual volumes. The virtual volume management table 1410 is used by the clone processing unit 1220 and the policy change processing unit 1230.

[0040] The policy management table 1420 is a table that manages the policy settings for each virtual volume. The policy management table 1420 is used by the clone processing unit 1220 and the policy change processing unit 1230.

[0041] The storage control unit 1300 has a program for processing I / O requests to volumes from the host computer 200, and a program for creating, deleting, and modifying logical resources of the storage node 100 according to instructions received from the host computer 200 via the API processing unit 1200, such as creating, deleting, virtual copy clones, local copy clones, and snapshots of virtual volumes. Details of the virtual copy clone and local copy clone processes will be described later. In this embodiment, the physical copying of data from an existing volume, that is, the physical copying of data from the existing volume, is also referred to as a "local copy".

[0042] In this embodiment, the method for realizing a virtual volume in the storage control unit 1300 is, for example, to use a volume managed by the storage control unit 1300. In the following description, the actual virtual volume managed by the API processing unit 1200 will be described as, for example, a volume managed by the storage control unit 1300.

[0043] The storage control unit 1300 includes a snapshot / virtual clone processing unit 1310, a local copy processing unit 1320, and a volume migration processing unit 1330.

[0044] The storage control unit 1300, although not shown in the figure, typically includes other processing units such as a processing unit for creating volumes for virtual volumes, a processing unit for creating volumes for the PE, and a processing unit for setting up I / O paths between the host computer 200 and the PE.

[0045] The snapshot / virtual clone processing unit 1310 executes processing when a snapshot / virtual clone instruction for a volume is sent from the API processing unit 1200. Snapshots and virtual clones may be in the RoW (Redirect-on-Write) format, for example, which only updates metadata indicating the data storage location of the volume. In this embodiment, "virtual clone" refers collectively to clone volumes created by virtual copying.

[0046] In this case, with a Row of Wire (RoW) snapshot, the data used to create the snapshot is shared between the source volume and the snapshot volume, and the data storage area is managed as metadata.

[0047] When data from the source volume for creating a snapshot or a snapshot volume is written by host I / O, the snapshot / virtual clone processing unit 1310 does not overwrite the data before writing, but instead stores the data to be written in a new data storage area of ​​the volume and rewrites the metadata to refer to the data stored in that new data storage area.

[0048] As mentioned above, host I / O reads access data stored in the data storage area, which is recorded in the metadata. Therefore, for data storage areas that have not been updated by host I / O writes after snapshot creation, the read access will refer to the data storage area shared by the snapshot source volume and the snapshot volume.

[0049] A virtual clone is a volume cloning method that utilizes the Row of Work (RoW) format. Snapshots retain pair information between the source and destination volumes as storage management information. In contrast, a virtual clone replicates a RoW-formatted volume without retaining this pair information.

[0050] The local copy processing unit 1320 executes a local copy when it receives a local copy instruction for a volume from the API processing unit 1200. A local copy (physical copy) may take the form of physically copying the data stored in the source volume to another volume that has a different data storage location.

[0051] Unlike snapshots, local copies do not share data between multiple volumes. Instead, when a local copy is created, all the data from the source volume's data storage area is physically copied to a newly allocated data storage area for the destination volume. Therefore, during host I / O after a local copy is created, data is read and written to separate data storage areas on the source and destination volumes.

[0052] The volume migration processing unit 1330 executes volume migration when it receives a migration instruction for a volume from the API processing unit 1200. Volume migration may be performed by physically copying the data stored in the source volume to another volume and then deleting the source volume, or alternatively, by changing only the metadata without changing the data storage location. Furthermore, migration to snapshots or virtual clones may be performed by physically copying the stored data to another volume and then deleting metadata such as differential information for the snapshot or virtual clone. In addition, volume migration may include not only the stored data but also configuration management information such as virtual volume ID and path information.

[0053] The storage management table 1500 is a table for managing information used by the storage control unit 1300. The storage management table 1500 includes the volume management table 1510, the snapshot / virtual clone management table 1520, the local copy management table 1530, and the volume migration management table 1540.

[0054] The volume management table 1510 is a table that manages volume IDs, their mapping to virtual volumes, and their capacity, and is used by the snapshot / virtual clone processing unit 1310, the local copy processing unit 1320, and the volume migration processing unit 1330.

[0055] The snapshot / virtual clone management table 1520 is a table for managing pair information, type, and status of the snapshot / virtual clone source volume as a PVOL (Primary Volume) and the snapshot / virtual clone destination volume as a SVOL (Secondary Volume). The snapshot / virtual clone management table 1520 is used by the snapshot / virtual clone processing unit 1310.

[0056] The local copy management table 1530 is a table for managing pair information and status between the local copy source volume as a PVOL (Primary Volume) and the local copy destination volume as a SVOL (Secondary Volume). The local copy management table 1530 is used by the local copy processing unit 1320.

[0057] The volume migration management table 1540 is a table for managing information and status between the source volume and the destination volume for migration. The volume migration management table 1540 is used by the volume migration processing unit 1330.

[0058] Figure 4 is a diagram of the volume management table 1510 shown in Figure 3. The volume management table 1510 is a table that manages the ID, type, capacity, etc. of virtual volumes. The volume management table 1510 stores an entry for each virtual volume. The entries in the volume management table 1510 include the fields: virtual volume ID 1411, virtual volume type 1412, clone type 1413, snapshot / clone source virtual volume ID 1414, snapshot and virtual clone tree ID (Family) 1415, capacity 1416, free space 1417, and virtual volume creation time 1418.

[0059] Virtual volume ID 1411 stores the identification number of the virtual volume corresponding to the entry. Virtual volume type 1412 stores the type of virtual volume corresponding to the entry. This type should store information that identifies the type, such as "Normal VOL (Normal Volume)", "Snapshot", or "Clone".

[0060] The clone type 1413 stores the clone type of the virtual volume corresponding to the entry. When the virtual volume type 1412 is "Clone," this clone type should store information about how the clone volume is implemented. For example, the clone type can be set to "Virtual Clone," indicating that the clone volume is created by a virtual copy, or "Local Copy," indicating that the clone volume is created by a local copy (physical copy).

[0061] The snapshot / clone source virtual volume ID 1414 stores the ID of the snapshot / clone source virtual volume of the virtual volume corresponding to the entry. When the virtual volume type 1412 is "snapshot" or "clone," this snapshot / clone source virtual volume ID 1414 should store the virtual volume ID 1411 of the virtual volume from which the snapshot or clone originates.

[0062] The snapshot and virtual clone tree ID (Family) 1415 stores the identification number of the snapshot and virtual clone tree to which the virtual volume corresponding to the entry belongs. The snapshot and virtual clone tree ID (Family) 1415 is inherited by the virtual volume that was the source of the snapshot and virtual clone when a virtual volume is created by a snapshot or virtual clone. For example, a virtual volume A and a virtual volume B created by a snapshot and virtual clone of virtual volume A have the same snapshot and virtual clone tree ID 1415. A virtual volume C created as a snapshot and virtual clone of virtual volume B also has the same snapshot and virtual clone tree ID 1415 as virtual volumes A and B.

[0063] When creating a new virtual volume as a standard VOL, the snapshot and virtual clone tree ID 1415 are set in a way that does not overlap with the snapshot and virtual clone tree ID 1415 of an existing entry.

[0064] On the other hand, when creating a clone volume through a local copy, i.e., creating a new virtual volume as a virtual clone, a snapshot and virtual clone tree ID 1415 are set that do not overlap with the snapshot and virtual clone tree ID 1415 of an existing entry.

[0065] Capacity 1416 stores the capacity of the virtual volume corresponding to the entry. Free space 1417 stores the free space of the virtual volume corresponding to the entry. Virtual volume creation time 1418 stores the time when the virtual volume corresponding to the entry was created.

[0066] Next, we will describe an example of a virtual volume snapshot and a virtual clone tree image. The virtual clone tree is sometimes referred to as "Family". Figure 5 is an illustrative diagram showing an example configuration of a virtual volume snapshot and virtual clone tree according to this embodiment. The illustrated snapshot and virtual clone tree 14141 correspond to the example entries in the virtual volume management table 1410 shown in Figure 4. Note that "VVOL" in the illustration refers to a virtual volume.

[0067] Snapshot and virtual clone tree 14141, whose snapshot and virtual clone tree ID is "1", has virtual volume 14111, whose virtual volume ID is "1", as the root of the tree. Virtual volume 14113, whose virtual volume ID is "3", created as a snapshot of virtual volume 14111, belongs to the tree as a child of virtual volume 14111. Virtual volume 14114, whose virtual volume ID is "4", created as a virtual clone of virtual volume 14111, belongs to the tree as a child of virtual volume 14111. Virtual volume 14115, whose virtual volume ID is "5", created as a snapshot of virtual volume 14114, belongs to the tree as a child of virtual volume 14114.

[0068] Virtual volume 14112, which is a regular volume different from virtual volume 14111 and has a virtual volume ID of "2", will be configured in the tree as a snapshot and virtual clone tree with a different ID than virtual volume 14111, namely virtual volume 2. Virtual volume 14116, which is created as a virtual clone of virtual volume 14112 and has a virtual volume ID of "6", will belong to the tree as a child of virtual volume 14112.

[0069] Figure 6 shows an example configuration of the policy management table 1420 shown in Figure 3. The policy management table 1420 is a table that manages the policy settings for each virtual volume. The policy management table 1420 stores entries for each policy.

[0070] The entries in policy management table 1420 include fields for policy ID 1421, virtual volume ID 1422, snapshot policy presence / absence 1423, snapshot execution cycle 1424, and snapshot retention period 1425.

[0071] Policy ID 1421 stores the identification number of the policy corresponding to the entry. Virtual Volume ID 1422 stores the ID of the virtual volume corresponding to the entry. Virtual Volume ID 1422 corresponds to Virtual Volume ID 1411 in Virtual Volume Management Table 1410.

[0072] The snapshot policy status 1423 stores whether or not snapshot-related policy settings exist for the virtual volume corresponding to the entry. For example, snapshot policy status 1423 is set to "ON" if a snapshot policy setting exists, and to "OFF" if a snapshot policy setting does not exist.

[0073] The snapshot execution period 1424 stores the snapshot execution period of the virtual volume corresponding to the entry. The snapshot execution period 1424 is set to, for example, "1 day" or "1 hour" depending on the end date of the snapshot being executed.

[0074] The snapshot retention period 1425 stores the snapshot retention period for the virtual volume corresponding to the entry. The snapshot retention period 1425 is set according to the retention period of the snapshot being performed, for example, "1 day" or "1 hour".

[0075] Figure 7 is a diagram of the volume management table 1510 shown in Figure 3. The volume management table 1510 is a table that manages the virtual volume ID, capacity, etc., of each volume. The volume management table 1510 stores entries for each volume. The entries in the volume management table 1510 include fields for volume ID 1511, virtual volume ID 1512, capacity 1513, and free space 1514.

[0076] Volume ID 1511 stores the identification number of the volume corresponding to the entry. Virtual Volume ID 1512 stores the identification number of the virtual volume provided by the volume corresponding to the entry.

[0077] Capacity 1513 stores the capacity of the volume corresponding to the entry. Free space 1514 stores the free space of the volume corresponding to the entry.

[0078] Figure 8 shows an example configuration of the snapshot / virtual clone management table 1520 shown in Figure 3. The snapshot / virtual clone management table 1520 is a table for managing pair information, type, and status of, for example, the source volume of the snapshot / virtual clone as a PVOL (Primary Volume) and the destination volume of the snapshot / virtual clone as a SVOL (Secondary Volume).

[0079] The snapshot / virtual clone management table 1520 stores entries for each PVOL and SVOL pair. Entries in the snapshot / virtual clone management table 1520 include fields for ID 1521, primary volume ID 1522, secondary volume ID 1523, type 1524, and state 1525.

[0080] ID 1521 stores the identification number of the pair corresponding to the entry. Primary volume ID 1522 stores the identification number of the PVOL of the pair corresponding to the entry. Primary volume ID 1522 corresponds to volume ID 1511 in volume management table 1510.

[0081] Secondary volume ID 1523 stores the identification number of the SVOL pair corresponding to the entry. Secondary volume ID 1523 corresponds to volume ID 1511 in volume management table 1510.

[0082] Type 1524 stores the type of the pair corresponding to the entry. For example, Type 1524 might be set to "Snapshot" and "Virtual Clone".

[0083] State 1525 stores the status of the pair corresponding to the entry. State 1525 can be set to, for example, "Created" to indicate that the pair has already been created, or "Copying" to indicate that the pair is being created.

[0084] Figure 9 shows an example of the configuration of the local copy management table 1530 shown in Figure 3. The local copy management table 1530 is a table for managing pair information and status between the local copy source volume as a PVOL (Primary Volume) and the local copy destination volume as a SVOL (Secondary Volume).

[0085] The local copy management table 1530 stores entries for each PVOL and SVOL pair. The entries in the local copy management table 1530 include fields for ID 1531, primary volume ID 1532, secondary volume ID 1533, and status 1534.

[0086] ID 1531 stores the identification number of the pair corresponding to the entry. Primary volume ID 1532 stores the identification number of the PVOL of the pair corresponding to the entry. Primary volume ID 1532 corresponds to volume ID 1511 in volume management table 1510.

[0087] Secondary volume ID 1533 stores the identification number of the SVOL pair corresponding to the entry. Secondary volume ID 1533 corresponds to volume ID 1511 in volume management table 1510. Status 1534 stores the status of the pair corresponding to the entry. Status 1534 is set to, for example, "Created" and "Copying".

[0088] Figure 10 shows an example configuration of the volume migration management table 1540 shown in Figure 3. The volume migration management table 1540 is a table for managing information and status of the source volume and the destination volume for migration.

[0089] The volume migration management table 1540 stores an entry for each volume migration process. Each entry in the volume migration management table 1540 includes the fields ID 1541, source volume ID 1542, destination volume ID 1543, and status 1544.

[0090] ID 1541 stores the identification number of the volume migration process corresponding to the entry. Source volume ID 1542 stores the identification number of the source volume for the volume migration process corresponding to the entry. Source volume ID 1542 corresponds, for example, to volume ID 1511 in volume management table 1510.

[0091] The destination volume ID 1543 stores the identification number of the destination volume for the volume migration process corresponding to the entry. Destination volume ID 1543 corresponds to volume ID 1511 in volume management table 1510.

[0092] State 1544 stores the status of the volume migration process corresponding to the entry. State 1544 can be set to, for example, "Completed" or "Copying".

[0093] The storage system 1000 according to this embodiment has the configuration described above. Next, an overview of the overall flow of the virtual copy clone creation process and the policy change process will be explained. Figure 11 is a flowchart showing an example of a storage management method including virtual volume cloning and policy change processing according to this embodiment.

[0094] First, the storage management method according to this embodiment will be described. In this storage management method, the controller 111 can perform a virtual copy clone creation process, which creates a clone using a virtual copy that shares data with an existing volume, and a physical copy clone creation process, which creates a clone volume by physically copying data from an existing volume. Based on the number of existing and clone volumes to be created, and the upper limit of the number of clone volumes that can be created by the virtual copy clone creation process, the controller 111 decides whether to perform the virtual copy clone creation process or the physical copy clone creation process and executes it.

[0095] The host computer 200 sends an API request (hereinafter abbreviated as "API request") to the API processing unit 1200 of the storage node 100 (step S2000). The API request is a request to operate on virtual volume-related management resources, such as "create virtual volume", "delete virtual volume", "take a virtual volume snapshot", "clone virtual volume", and "change virtual volume policy".

[0096] The API sending / receiving unit 1210 of the API processing unit 1200 receives an API request (step S2100). The API sending / receiving unit 1210 of the API processing unit 1200 checks the API type (step S2200). The API type is information used to determine what operation to perform using the API, such as "create virtual volume," "delete virtual volume," "take a snapshot of a virtual volume," "clone a virtual volume," or "change a virtual volume policy."

[0097] If the API type in step S2200 is "Virtual Volume Clone," indicating that the volume is a clone created by virtual copying, the clone processing unit 1220 executes the virtual copy clone creation process (step S2300). On the other hand, if the API type in step S2200 is "Virtual Volume Policy Change," the policy change processing unit 1230 executes the policy change process (step S2400).

[0098] After completing step S2300 or step S2400, the API transmission / reception unit 1210 sends an API response (hereinafter abbreviated as "API response") to the host computer 200 (step S2500). The API response includes information such as the result of processing the API request. Finally, the host computer 200 receives the API response from the API transmission / reception unit 1210 (step S2600).

[0099] Figure 12 is a flowchart showing an example of the procedure for the virtual copy clone creation process (step S2300) shown in Figure 11. The clone processing unit 1220 performs a check to determine whether the snapshot policy can be maintained during the virtual copy clone creation process (step S2301). The determination of whether the snapshot policy can be maintained refers to information on whether snapshots can be created in accordance with the snapshot period and snapshot retention period set as the policy. For example, if the snapshot period and snapshot retention period of any policy cannot be maintained due to the effects of this virtual copy clone creation process, it is determined that the snapshot policy cannot be maintained.

[0100] The clone processing unit 1220 determines whether or not it is possible to maintain the snapshot policy based on the check results in step S2301 (step S2302).

[0101] If it is possible to maintain the snapshot policy in step S2302, the clone processing unit 1220 requests the snapshot / virtual clone processing unit 1310 of the storage control unit 1300 to perform the virtual clone process (step S2303).

[0102] On the other hand, if it is impossible to maintain the snapshot policy in step S2302, the clone processing unit 1220 requests the local copy processing unit 1320 of the storage control unit 1300 to perform a local copy operation (step S2304).

[0103] Finally, the clone processing unit 1220 updates the virtual volume management table 1410 based on the results of steps S2303 and S2304 (step S2305). Specifically, for example, if in S2303 the virtual copy clone creation process created a virtual volume with virtual volume ID "10" using a virtual volume with virtual volume ID "1" as the source, the clone processing unit 1220 creates a new entry where virtual volume type 1412 is "clone", clone type 1413 is "virtual clone", and snapshot / source virtual volume ID 1414 is "1".

[0104] Figure 13 is a flowchart showing an example of the procedure for checking whether the snapshot policy can be maintained, as shown in Figure 12. The snapshot policy maintenance check is performed by the clone processing unit 1220.

[0105] The clone processing unit 1220 obtains a list of virtual volume IDs from the virtual volume management table 1410 that have a virtual volume type of snapshot and have the same snapshot and virtual clone tree ID as the source virtual volume which is the virtual volume to be cloned (step S23011).

[0106] The clone processing unit 1220 retrieves a list of policy entries from the policy management table 1420 that match the virtual volume IDs in the virtual volume ID list obtained in step S23011 (step S23012).

[0107] The clone processing unit 1220 calculates the expected maximum number of snapshots for each entry in the policy entry list obtained in step S23012 (step S23013). The expected maximum number of snapshots refers to the number of snapshots required to achieve the snapshot period and snapshot retention period set in the policy. For example, the maximum number of snapshots that can be created for a virtual volume with a policy set to have a snapshot retention period of 1 week and a snapshot execution period of 1 day is, for example, 7 days / 1 day = 7.

[0108] The clone processing unit 1220 calculates the sum of the assumed maximum number of snapshots for each policy entry calculated in step S23013 (step S23014).

[0109] The clone processing unit 1220 calculates the number of virtual volumes from the virtual volume management table 1410 that are of the type virtual clone and have the same snapshot and virtual clone tree ID as the source virtual volume (step S23015).

[0110] If the API request includes a snapshot policy setting for the virtual volume to be created by executing the virtual clone process, the clone processing unit 1220 calculates the expected maximum number of snapshots for the virtual volume to be cloned based on that policy setting (step S23016). The method for calculating the expected maximum number of snapshots is the same as in step S23013 described above. On the other hand, if there is no snapshot policy setting, the clone processing unit 1220 sets the expected maximum number of snapshots for the virtual volume to be cloned to "0".

[0111] The clone processing unit 1220 calculates the sum of the values ​​calculated in steps S23014, S23015, and S23016 and the number of clone virtual volumes created in the virtual copy clone creation process (step S23017).

[0112] Finally, the clone processing unit 1220 responds that the snapshot policy cannot be maintained if the calculated value in step S23017 exceeds the upper limit on the number of snapshots and virtual clones that can be created for snapshots and virtual clone trees (hereinafter also referred to as the "storage system limit"), while responding that the snapshot policy can be maintained if it does not exceed the limit. The upper limit on the number of snapshots and virtual clones that can be created (storage system limit) may be an upper limit for each snapshot and virtual clone tree, or it may be an upper limit for the entire storage system. Furthermore, the above-mentioned upper limit may be logically set in advance as a specification of the storage control unit 1300 as an example of a storage control program, or it may be determined from constraints on physical resources such as memory.

[0113] Figure 14 is a flowchart showing an example of the procedure for the virtual copy clone creation process (step S2303) shown in Figure 12. The snapshot / virtual clone processing unit 1310 of the storage control unit 1300 starts executing the virtual copy clone creation process (step S23031). The virtual clone may be in RoW (Redirect-on-Write) format, for example, by updating only the metadata indicating the data storage location of the volume.

[0114] The snapshot / virtual clone processing unit 1310 updates the snapshot / virtual clone management table 1520 and the volume management table 1510 based on the processing details in step S23031 and the information of the volume created by the virtual clone (step S23032).

[0115] Figure 15 is a flowchart showing an example of the procedure for the local copy clone creation process (step S2304) shown in Figure 12. The local copy processing unit 1320 of the storage control unit 1300 starts executing the local copy process (step S23041). The local copy may be in the form of physically copying the data stored in the source volume to another volume having a different data storage location.

[0116] The local copy processing unit 1320 updates the local copy management table 1530 and the volume management table 1510 based on the processing details of step S23041 and the information of the volume created by the local copy (step S23042).

[0117] Figure 16 is a flowchart showing an example of the procedure for the policy change process (step S2400) shown in Figure 12. The policy change processing unit 1230 determines whether or not the policy change includes snapshot-related policy information (step S2401). If the policy change processing unit 1230 includes snapshot-related policy information, it executes step S2402; otherwise, it executes step S2405.

[0118] In step S2402, the policy change processing unit 1230 executes a check to determine whether the snapshot policy can be maintained during the policy change process. The check to determine whether snapshots can be created while adhering to the snapshot period and snapshot retention period set as a policy. For example, if the snapshot period and snapshot retention period, which are policies for any virtual volume, cannot be maintained due to the impact of this policy change process, the policy change processing unit 1230 determines that the snapshot policy cannot be maintained.

[0119] The policy change processing unit 1230 determines whether the snapshot policy can be maintained based on the check result in step S2402 (step S2403). If the policy change processing unit 1230 determines in step S2303 that the snapshot policy can be maintained, it executes step S2405. On the other hand, if the policy change processing unit 1230 determines in step S2303 that the snapshot policy cannot be maintained, it requests the volume migration processing unit 1330 to perform volume migration (step S2404). The virtual volume to be migrated may be the virtual volume whose policy is to be changed, or it may be one or more virtual volumes belonging to the same snapshot and virtual clone tree as the virtual volume whose policy is to be changed. However, if one or more virtual volumes belonging to the same snapshot and virtual clone tree as the virtual volume whose policy is to be changed are to be migrated, it is necessary to select the virtual volumes to be migrated so that the number of assumed maximum snapshots does not exceed the upper limit in order to maintain the snapshot policy.

[0120] Finally, the policy change processing unit 1230 updates the policy management table 1420 based on the policy changes described above (step S2405).

[0121] Figure 17 is a flowchart showing an example of the procedure for the snapshot policy maintenance feasibility check process (step S2402) in the policy change process shown in Figure 11. Here, as described above, the clone volume includes virtual clone volumes and snapshot volumes. In this embodiment, virtual clone volumes and snapshot volumes are managed with the same virtual clone tree ID as the volume from which they were created, and the above upper limit is set for the number of volumes having the same virtual clone tree ID.

[0122] The policy change processing unit 1230 obtains a list of virtual volume IDs from the virtual volume management table 1410 that have a virtual volume type of snapshot and the same snapshot and virtual clone tree ID as the virtual volume whose policy is to be changed (step S24021).

[0123] The policy change processing unit 1230 retrieves a list of policy entries from the policy management table 1420 that match the virtual volume IDs in the virtual volume ID list obtained in step S24021 (step S24022).

[0124] The policy change processing unit 1230 calculates the expected maximum number of snapshots for each entry in the policy list obtained in step S24022 (step S24023). The expected maximum number of snapshots is the number of snapshots required to achieve the snapshot period and snapshot retention period set as a policy. For example, the maximum number of snapshots that can be created for a virtual volume with a policy set to have a snapshot retention period of one week and a snapshot execution period of one day is, for example, 7 days / 1 day = 7.

[0125] The policy change processing unit 1230 calculates the sum of the assumed maximum number of snapshots for each policy entry calculated in step S24023 (step S24024).

[0126] The policy change processing unit 1230 calculates from the virtual volume management table 1410 the number of virtual volumes whose clone type is virtual clone and which have the same snapshot and virtual clone tree ID as the virtual volume whose policy is to be changed (step S24025).

[0127] The policy change processing unit 1230 calculates the expected maximum number of snapshots based on the snapshot policy setting if the virtual volume to be modified has a snapshot policy setting as part of the API request (step S24026). The method for calculating the expected maximum number of snapshots is the same as in step S24023 described above.

[0128] The policy change processing unit 1230 calculates the sum of the values ​​calculated in steps S24024, S24025, and S24026 (step S24027).

[0129] Finally, the policy change processing unit 1230 responds that the snapshot policy cannot be maintained if the value calculated in step S24027 exceeds the upper limit (storage system limit) for the number of snapshots and virtual clones that can be created for the snapshot and virtual clone tree, and responds that the policy can be maintained if it does not exceed the limit.

[0130] Here, snapshots and virtual clones need to be managed as a tree in relation to their source volume for Row of Work (RoW) processing. When the source volume is the same, both snapshots and virtual clones are managed together in the same RoW management tree. The number of volumes managed within these trees (source volume for snapshots and virtual clones, snapshot volume, and virtual clone volume) is limited by constraints such as the upper limit of physical resources (memory). Therefore, this tree management limit imposes a limit on the number of snapshots and virtual clones that can be created for the same source volume.

[0131] The maximum number of snapshots and virtual clones that can be created (storage system limit) is set for each snapshot and virtual clone tree. Alternatively, there may be a limit for the entire storage system. This limit may be a logical limit set in advance as part of the specifications of the storage control unit 1300, which is an example of a storage control program, or it may be a limit determined by constraints on physical resources such as memory.

[0132] In contrast, clone volumes created by physical copying do not need to maintain a relationship with the source volume and are therefore not managed by snapshots or virtual clone trees. Consequently, the number of clone volumes created by physical copying is not limited by the limits managed by snapshots and virtual clone trees, such as those imposed by snapshots and virtual clone trees.

[0133] Figure 18 is a flowchart showing an example of the volume migration process (step S2404) as shown in Figure 16. The volume migration processing unit 1330 of the storage control unit 1300 starts executing the volume migration process (step S24041). The volume migration process may be performed by physically copying the data stored in the source volume to another volume and then deleting the source volume, or it may be performed by changing only the metadata without changing the data storage location.

[0134] The volume migration processing unit 1330 updates the volume migration management table 1540 and the volume management table 1510 based on the processing details of step S24041 and the information of the volume created by volume migration (step S24042).

[0135] As described above, the storage system 1000 according to this embodiment is a storage system comprising a storage device 130 as an example of a drive on which volumes are created for which data input / output processing is performed with a host computer 200, and at least one controller 111 that controls the input / output processing. The controller 111 is capable of performing a virtual copy clone creation process, which creates a clone volume by virtual copying that shares data with an existing volume, and a physical copy clone creation process, which creates a clone volume by physically copying data from an existing volume. The controller 111 decides whether to perform the virtual copy clone creation process or the physical copy clone creation process based on the number of existing and clone volumes to be created, and the upper limit of the number of clone volumes that can be created by the virtual copy clone creation process, and then performs the process.

[0136] In this way, the processing behavior related to the virtual copy clone creation process and the process of changing the policy is dynamically changed depending on whether or not the policy can be maintained after the virtual copy clone creation process is executed. Therefore, even when a clone volume is created using a virtual copy, the policy can always be maintained.

[0137] In this embodiment, the controller 111 has a policy for creating clone volumes, estimates the number of clone volumes to be created based on the policy, and decides whether to execute a virtual copy clone creation process or a physical copy clone creation process based on the estimated number of clone volumes, the number of existing clone volumes, and the upper limit of the number of clone volumes that can be created by the virtual copy clone creation process.

[0138] In this embodiment, the clone is a snapshot. The policy for the clone volume defines the snapshot creation cycle and retention period.

[0139] In this embodiment, the controller 111 creates clone volumes using virtual copies if it is possible to maintain the virtual copy clone creation process within the above upper limit, and creates clone volumes using physical copies if it is not possible to maintain the virtual copy clone creation process within the above upper limit. In this way, even when attempting to continuously increase the number of clone volumes created by virtual copies, the snapshot policy specified by the VM administrator can be maintained. Furthermore, even when creating a large number of clone volumes, as would be the case if physical copies were performed from the beginning and then clone volumes were created using virtual copies, the consumption of storage capacity is less likely to increase significantly.

[0140] In this embodiment, the policy change processing unit 1230 determines whether the snapshot policy can be maintained by determining whether the upper limit of the snapshot / virtual clone tree is exceeded, based on the assumed maximum number of snapshots calculated based on the snapshot period and snapshot retention period included in the snapshot policy, and the number of clone volumes already created by virtual copies.

[0141] In this embodiment, the clone volume includes a virtual clone volume and a snapshot volume. The virtual clone volume and snapshot volume are managed with the same virtual clone tree ID as the volume from which they were created, and the above-mentioned upper limit is set on the number of volumes that have the same virtual clone tree ID.

[0142] In this embodiment, if the controller 111 estimates that the number of clone volumes exceeds the above upper limit, it assigns a different virtual clone tree ID to some of the existing or to be created clone volumes that have the same virtual clone tree ID and manages them separately.

[0143] In this embodiment, the controller 111 creates clone volumes using a virtual copy clone creation process, and when managing them separately with other virtual clone tree IDs, it creates clone volumes using a physical copy clone creation process.

[0144] In this embodiment, the controller 111 creates clone volumes using a virtual copy clone creation process. When managing them separately by assigning them to other virtual clone tree IDs, the controller 111 creates clone volumes using a physical copy clone creation process and separates their management.

[0145] In this embodiment, since virtual clones are managed in a single group called a snapshot / virtual clone tree, when implemented on a storage system 1000 with physical resource limits such as memory 120 and storage devices 130, it is possible to ensure that the number of executable snapshots within a snapshot / virtual clone tree does not decrease as the number of virtual clones within that snapshot / virtual clone tree increases. When implemented in this way using virtual clones, even when the number of virtual clones continues to increase, the number of executable snapshots within the snapshot / virtual clone tree to which the virtual clone belongs does not decrease, thereby ensuring that the snapshot policy specified by the VM administrator is always maintained. Furthermore, when implemented using virtual clones, in situations where there are many clone volumes, the VM administrator can enable or change the snapshot policy, ensuring that the snapshot policy of the virtual volume within the snapshot / virtual clone tree to which the virtual volume whose policy is being changed belongs is always maintained.

[0146] It should be noted that the present invention is not limited to the embodiments described above, but includes various modifications and equivalent configurations within the spirit of the attached claims. For example, the embodiments described above are described in detail for the purpose of clearly illustrating the present invention, and the present invention is not necessarily limited to having all the configurations described. Also, each element described in parallel in this embodiment may be configured such that at least one of the elements is connected in series with respect to the other elements. [Industrial applicability]

[0147] This invention can be applied to storage systems that utilize a technique for creating clone volumes from virtual copies. [Explanation of Symbols]

[0148] 100...Storage node, 1000...Storage system, 1200...API processing unit, 1210...API transmission / reception unit, 1220...Clone processing unit, 1230...Policy change processing unit.

Claims

1. A storage system comprising a drive for physically storing data, and at least one controller that provides a volume to a host computer and controls the input / output processing of data via the volume, The aforementioned controller, It is possible to perform a virtual copy clone creation process that creates a clone volume by sharing data with an existing volume, and a physical copy clone creation process that creates a clone volume by physically copying data from the existing volume. Based on the number of existing and to be created clone volumes, and the upper limit of the number of clone volumes that can be created by the virtual copy clone creation process, it is determined and executed whether to perform the virtual copy clone creation process or the physical copy clone creation process. A storage system characterized by the following features.

2. The aforementioned controller, Having a policy regarding the creation of the aforementioned clone volume, Based on the aforementioned policy, the number of clone volumes to be created is estimated, and based on the estimated number of clone volumes, the number of existing clone volumes, and the upper limit of the number of clone volumes that can be created by the virtual copy clone creation process, it is determined and executed whether to perform the virtual copy clone creation process or the physical copy clone creation process. The storage system according to feature 1.

3. The aforementioned clone is a snapshot, The policy for the aforementioned clone volume defines the snapshot creation cycle and retention period. The storage system according to claim 2, characterized by the features described above.

4. The aforementioned controller, Regarding the virtual copy clone creation process, if it is possible to maintain the limit, the clone volume is created using the virtual copy; however, if it is not possible to maintain the limit, the clone volume is created using the physical copy. The storage system according to feature 1.

5. The aforementioned controller, Regarding whether the aforementioned upper limit can be maintained, the determination of whether the upper limit is exceeded is made based on the assumed maximum number of snapshots calculated from the snapshot period and snapshot retention period included in the policy, and the number of clone volumes already created by virtual copies. The storage system according to claim 2, characterized by the features described above.

6. The aforementioned clone volume includes a virtual clone volume and a snapshot volume. Virtual clone volumes and snapshot volumes are managed with the same virtual clone tree ID as the volume from which they were created. The upper limit is set for the number of volumes having the same virtual clone tree ID. The storage system according to feature 1.

7. The aforementioned controller, If the number of clone volumes is estimated to exceed the upper limit, some of the existing or created clone volumes having the same virtual clone tree ID are assigned a different virtual clone tree ID and managed separately. The storage system according to feature 1.

8. The aforementioned controller, The aforementioned clone volume is created by the virtual copy clone creation process. When managing them separately with other virtual clone tree IDs, the physical copy clone creation process creates a clone volume. The storage system according to feature 1.

9. The aforementioned controller, The aforementioned clone volume is created by the virtual copy clone creation process. When managing separate virtual clone tree IDs, a clone volume is created using the physical copy, and its management is separated. The storage system according to feature 1.

10. A storage management method for a storage system comprising a drive for physically storing data, and at least one controller that provides a volume to a host computer and controls the input / output processing of data via the volume, The aforementioned controller, It is possible to perform a virtual copy clone creation process that creates a clone volume by sharing data with an existing volume, and a physical copy clone creation process that creates a clone volume by physically copying data from the existing volume. Based on the number of existing and to be created clone volumes, and the upper limit of the number of clone volumes that can be created by the virtual copy clone creation process, it is determined and executed whether to perform the virtual copy clone creation process or the physical copy clone creation process. A storage management method characterized by the following features.

Images