Storage management system and storage management method

Abstract

Allow for changes to the environment before and after the migration, and determine the appropriate placement of virtual volumes. [Solution] Multiple storage devices each generate and provide virtual volumes to a host, and each holds a protocol endpoint to access the virtual volumes and a storage container that generates the virtual volumes. When migrating multiple virtual volumes from multiple source storage devices to multiple destination storage devices, the processor configures multiple virtual volume groups from the multiple virtual volumes, configures multiple virtual volume groups, and determines a destination storage device for each of the multiple virtual volume groups to which the multiple virtual volumes of the virtual volume group will be migrated together, based on the capacity and load of each virtual volume group, and then migrates them.

Description

Technical Field

[0001] The present invention relates to a storage management system and a storage management method.

Background Art

[0002] Conventionally, for migrating virtual volumes (VVOLs: Virtual Volumes), there is a technique described in Japanese Patent Application Laid-Open No. 2021-114213 (Patent Document 1). This document describes, "Realize storage-based migration in a VVOL environment.", "The migration processing unit 103 generates a migration group by grouping a virtual volume to be migrated, a protocol endpoint related to the virtual volume, and a storage container that cuts out the virtual volume, migrates the migration group to the storage node 201, and the configuration change unit 208 is based on the information of the migration group transmitted from the storage node 101. Configure the same protocol endpoints, virtual volumes, and storage containers as those configured in the storage node 101 on the storage node 201."

Prior Art Documents

Patent Documents

[0003]

Patent Document 1

Summary of the Invention

Problems to be Solved by the Invention

[0004] The above conventional technology assumes that the environment of the source storage and the environment of the destination storage are the same. Therefore, an object of the present invention is to make it possible to change the environment before and after migration and to determine an appropriate virtual volume placement. Another object of the present invention is to avoid load concentration by an appropriate virtual volume placement. [Means for solving the problem]

[0005] To achieve the above objective, one representative storage management system of the present invention is a storage management system having a processor and managing multiple storage devices, wherein each of the multiple storage devices generates and provides virtual volumes to a host, holds a protocol endpoint to access the virtual volumes and a storage container that generates the virtual volumes, and when multiple virtual volumes are migrated from multiple source storage devices to multiple destination storage devices, the processor configures a virtual volume group with the multiple virtual volumes, configures multiple virtual volume groups, and determines a destination storage device for each of the multiple virtual volume groups to which the multiple virtual volumes of the virtual volume group will be migrated together, based on the capacity and load of each virtual volume group, and migrates them. Furthermore, one representative storage management method of the present invention is a storage management method in a storage management system having a processor and managing a plurality of storage devices, wherein each of the plurality of storage devices generates and provides virtual volumes to a host, holds a protocol endpoint to which the virtual volumes are accessed and a storage container from which the virtual volumes are generated, and when a plurality of virtual volumes are migrated from a plurality of source storage devices to a plurality of destination storage devices, the method is characterized in that the processor includes the steps of: configuring a virtual volume group with the plurality of virtual volumes; configuring a plurality of virtual volume groups; and determining a destination storage device for each of the plurality of virtual volume groups to which the plurality of virtual volumes of the virtual volume group will be migrated together, based on the capacity and load of each of the plurality of virtual volume groups, and then migrating. [Effects of the Invention]

[0006] According to the present invention, the environment can be changed before and after migration, and the appropriate placement of virtual volumes can be determined. Other issues, configurations, and effects will be clarified by the following description of embodiments. [Brief explanation of the drawing]

[0007] [Figure 1] Configuration diagram of the storage management system in Example 1. [Figure 2] A diagram illustrating an example of a storage device configuration. [Figure 3] A diagram illustrating virtual volumes. [Figure 4] A diagram illustrating the memory of a storage device. [Figure 5] A diagram illustrating the memory of the VM provider management server. [Figure 6] Diagram illustrating the memory of the migration management server. [Figure 7] Diagram illustrating the table of a storage device (Part 1). [Figure 8] Diagram illustrating the table of a storage device (part 2). [Figure 9] A diagram illustrating the tables held by the VM provider management server. [Figure 10] A diagram illustrating the tables on the migration management server. [Figure 11] A flowchart illustrating the processing steps of a storage management system. [Figure 12] A flowchart showing the details of step S102. [Figure 13] A flowchart showing the details of step S103. [Figure 14] A flowchart showing the details of step S104. [Figure 15] Configuration diagram of the storage management system in Example 2. [Figure 16] A flowchart showing the details of resource allocation calculation for each VVOL group in Example 2. [Modes for carrying out the invention]

[0008] Hereinafter, embodiments will be described with reference to the drawings.

Embodiment

[0009] FIG. 1 is a configuration diagram of the storage management system of Embodiment 1. The storage management system of Embodiment 1 includes a migration management server 10, a VM overall management server 20, one or more hosts 30, one or more storage devices 40, a VM provider management server 50, and one or more storage devices 60.

[0010] The host 30 is a server that operates a virtual machine (VM: Virtual Machine). The VM overall management server 20 is a server that manages all VMs in the system. The VM provider management server 50 is a server that provides a provider 100 that provides a virtual volume (VVOL) function, and operates as a virtual volume providing unit. The storage device 40 and the storage device 60 are storage devices that provide storage areas for the host 30. The VM provider management server 50 and the plurality of storage devices 40 constitute the source storage system 2 of the virtual volume. The plurality of storage devices 60 constitute the destination storage system 3 of the virtual volume. The migration management server 10 is a server that manages a program when migrating VVOL data from the storage system 2 to the storage system 3, and operates as a migration management unit. The migration management server 10 may exist independently of other servers as shown in the figure, may be the same as other management servers, or may exist in any one of the storage devices.

[0011] The provider 100 may be outside the storage device or may exist inside the storage device as shown in the figure. The provider 100 is a program that operates on the memory of the VM provider management server 50 or the storage device.

[0012] The network used for storage data and the network used for management can be the same. User data I / O is transmitted on the storage data network. Management commands are transmitted on the management network. The network may be redundant. The network can use any communication format, and the storage service network and the backend network may be different networks.

[0013] Figure 2 is an explanatory diagram of an example configuration of a storage device. The storage device 60a has a CPU (Central Processing Unit) 61, memory 62, and a drive 63, and is configured to share computing resources for processing input / output (I / O) commands for user data and commands for management operations. Although only one CPU, memory, and drive are shown in the diagram, multiple CPUs, memory, and drives may be present.

[0014] The storage device 60b includes a management module 70, separate from the CPU 61, memory 62, and drive 63 that process input / output (I / O) commands for user data on the main storage device side. The management module 70 has computing resources (CPU 71, memory 72, drive 73) that process management operation commands. In other words, the storage device 60b has a configuration in which the computing resources that process input / output (I / O) commands for user data and the computing resources that process management operation commands are separated. Alternatively, instead of physically separating them with a management module, the computing resources that process input / output commands for user data and the computing resources that process management operation commands may be logically separated, while they are physically common. If the provider 100 is built into the storage device, the provider 100 uses the CPU, memory, and drive of the management module 70. Alternatively, it uses the CPU, memory, and drive that are logically allocated to management operation commands.

[0015] In this embodiment, we will explain using a configuration in which the management modules are physically separated as an example, but it is also possible to implement it with other configurations. In this embodiment, the source storage device has a management module, does not have a built-in provider 100, and one provider 100 manages multiple storage devices. In this embodiment, the destination storage device has a management module, has a built-in provider 100, and one in-device provider manages one storage device.

[0016] Figure 3 is an explanatory diagram of a virtual volume. Host 30 is running virtual machines 31 and 32. Virtual machines 31 and 32 access logical unit 33. Datastore 34 is the storage area as seen from virtual machines 31 and 32.

[0017] In Conglomerate SCSI (Small Computer System Interface), one or more Subsidiary Logical Units (SLUs) 42-43, which provide logical volumes based on physical storage devices, and an Administrative Logical Unit (ALU) 41, which acts as an I / O port for SLUs 42-43, are created in the storage device 40. All access from the host 30 is performed via the ALU 41, and the ALU 41 distributes I / O to the SLUs it is bound to. Therefore, when the host 30 performs I / O (Read / Write, etc.), it is only necessary to mount the ALU 41. When the operation to bind SLUs 42-43 to the ALU 41 is performed, the ALU 41 becomes capable of issuing I / O to SLUs 42-43. When the ALU 41 unbinds SLUs 42-43, the ALU 41 becomes unable to issue I / O to SLUs 42-43. If the host recognizes the relationship between ALU41 and SLU42-43 (i.e., by associating ALU41 with logical unit 33), I / O to ALU41 recognized by the storage side will be forwarded to the appropriate SLU. ALU41 is a protocol endpoint, and SLU42-43 are virtual volumes. Furthermore, the storage container 44 processes the data that is input / output via the SLU to the storage device 40's capacity blocks (a collection of pools). SLU42-43 are partitioned by the storage container 44 to correspond to the pools. The datastore 34 as seen from the host 30 corresponds to the storage container 44 of the storage device 40. The total capacity that can be created as a VM on the host 30 is the capacity of the datastore. These management operations are performed on the ALU and SLU through the provider 100. Management operations may be sent from the host 30 to the provider 100, or from the VM overall management server 20 to the provider 100.

[0018] Figure 4 is an explanatory diagram of the memory of the storage device. The memory 200 shown in Figure 4 corresponds to a configuration that does not include a provider 100. Memory 200 stores the control software 201, the configuration management unit 202, and the operation information management unit 203. Memory 200 also stores the device identifier 211, configuration information 212, the ALU management table 213, the SLU management table 214, the capacity management table 215, and the operation information table 216.

[0019] The control software 201 is a program that receives requests from the host 30, performs I / O processing, and stores data in the drive. The configuration management unit 202 is a program that updates information on ALUs and SLUs in response to management operation instructions from external sources. The operational information management unit 203 is a program that updates the operational information table 216. The device identifier 211 contains information that uniquely identifies the device. In addition to simple device identification information, it also contains information such as the device type and the IP address for access from an external server. Configuration information 212 stores management information such as the logic-to-physical transformation table necessary for storage control. ALU management table 213 shows the management information for the ALU. The SLU management table 214 displays management information for SLUs. The SLU management table 214 also holds information related to binding. The capacity management table 215 shows the management information for the storage pool. The operational information table 216 shows the operational information for each resource.

[0020] Figure 5 is a diagram illustrating the memory of the VM provider management server 50. The memory of the management module when it is built into a storage device is similar. The memory 300 shown in Figure 5 stores the provider 100. The memory 300 also stores the PE management table 311, the VVOL management table 312, the SC management table 313, and the operation log 314.

[0021] Provider 100 is a program that receives VVOL operation commands and sends instructions to the storage device. The PE management table 311 is a table that contains information that maps the information in the storage device's ALU management table 213 to the VVOL mechanism. The VVOL management table 312 is a table that contains information that maps the information in the storage device's SLU management table 214 to the VVOL mechanism. It also contains information that shows the relationships between multiple VVOLs that make up a single virtual machine. SC management table 313 is a table that holds information that maps the storage device pool information to the VVOL mechanism. Operation log 314 contains operation log (history) information for VVOL operation commands.

[0022] Furthermore, if provider 100 resides on a VM provider management server 50 located outside the storage device, it holds information on various management tables corresponding to multiple storage devices. If provider 100 is built into the storage device, it only holds information related to the built-in storage device.

[0023] Figure 6 is an explanatory diagram of the memory of the migration management server 10. The memory 400 shown in Figure 6 stores the migration plan determination unit 401, the migration processing instruction unit 402, and the operation information collection unit 403. The memory 400 also stores the load criteria table 411 for each management operation, the device hardware specification table 412, the I / O performance history table 413, and the resource allocation proposal table 414.

[0024] The migration plan determination unit 401 is a program that calculates logic for determining a migration plan from various management information of each storage device and various management information of the provider 100. The migration processing instruction unit 402 is a program that creates operation procedures for the storage device and VMs in accordance with the plan of the migration plan determination unit 401, and executes the processing of the operation procedures based on instructions from the storage device 40, the VM overall management server 20, or the host 30. The operational information management unit 203 is a program that collects operational information from each storage device.

[0025] The load criteria table 411 for each management operation is a table that contains information that serves as a basis for the load on computing resources for each operational operation of VVOL. The device hardware specification table 412 is a table containing hardware specification information for each storage device and its management module. The I / O performance history table 413 is a table that collects operational information for each storage device and stores historical information on I / O performance. Resource allocation plan table 414 is a table that shows proposed resource allocations.

[0026] Figures 7 and 8 are explanatory diagrams of the tables contained within the storage device. The ALU management table 213 has a structure in which "Names" are associated with "ALU IDs". The SLU management table 214 has a configuration in which "SLU ID" is associated with "Name," "Capacity," "Binded ALU ID," "Pool ID," "Related SLU ID," and "Applied Function." The "Related SLU ID" is independent for each VVOL, but indicates the SLU ID of the related counterpart within the storage device due to functions within the storage device (local copy function, snapshot function, remote copy function, etc.). The applied function indicates which function the related SLU is using (local copy (LC), snapshot (SS), remote copy (RC), etc.). In the case of remote copy, it contains information including the device identifier of the destination storage. The capacity management table 215 has a configuration in which "Name" and "Capacity" are associated with "Pool ID".

[0027] The operation information table 216 includes device operation information 216a and volume operation information 216b. The device operation information 216a has a configuration in which an "ID" that identifies computing resources such as the CPU and memory is associated with a "data type," "time," and "value." The data type is, for example, CPU usage rate or memory write wait rate. Volume operation information 216b has a configuration in which "Data Type," "Time," and "Value" are associated with "SLU ID." The data type is, for example, IOPS (Input / Output Per Second) or data transfer rate.

[0028] Figure 9 is an explanatory diagram of the tables held by the VM provider management server 50 (or the management module 70 when it is built into the storage device). First, the device ID is the device identifier that each device has, as shown in Figure 4. The PE management table 311 corresponds to the ALU management table 213. The PE management table 311 has the following fields: "Device ID", "PE ID" which is the identification information of the protocol endpoint (PE), "PE name" which is the name of the protocol endpoint, and "ALU ID". The VVOL management table 312 corresponds to the SLU management table 214. Since one VVOL may correspond to multiple VMs, they are identified by their VM names. A group of VVOLs that have the same VM name and require to be placed on the same device due to the functions that constitute the VVOL will henceforth be called a VVOL group. The VVOL management table 312 has the following fields: "Device ID", "VVOL ID", "VVOL Name", "Capacity", "SLU ID", "SC (Storage Controller) ID", "Type", and "VM Name". The SC management table 313 corresponds to the capacity management table 215. However, one SC (storage controller) corresponds to multiple pools. When integrated into a storage device, all device ID information is either identical or omitted. The SC management table 313 has the following fields: "Device ID", "SC ID", "SC Name", "Capacity", and "Pool IDs".

[0029] Figure 10 is an explanatory diagram of the tables in the migration management server 10. The IO performance history table 413, which is not shown in the diagram, is a table in which the device identifier, the device ID, is added to the operational information table of each storage device.

[0030] The Load Criteria Table 411 for each management operation shows load criteria information for each management operation. The Load Criteria Table 411 for each management operation has the following items: "Management Operation", "Type", "CPU Criteria Value", and "Memory Criteria Value". "Management Operation" includes "createVVOL", "deleteVVOL", "cloneVVOL", "queryVVOL", etc. "Type" "Setting" indicates a configuration change operation. "Type" "Reference" indicates an information retrieval operation. "CPU Criteria Value" is information that shows the CPU utilization rate (or CPU workload) for that operation at a certain standard CPU type and frequency. "Memory Criteria Value" shows the amount of memory consumed when retrieving information in a certain standard unit (basically one).

[0031] The device hardware specification table 412 shows the specifications of the storage device itself and the CPU and memory used by the provider of the storage device to be managed (if the provider is external storage, the specifications of the VM provider management server; if it is built into the storage device, the specifications of the management module). The device hardware specification table 412 has the following items: "Device type", "Compatible device ID", "Provider", "Main unit CPU type", "Main unit CPU frequency", "Main unit memory capacity", "Provider CPU", and "Provider memory capacity". In this embodiment, for simplicity, only the CPU type, frequency, and memory capacity are listed, but other information may be retained to improve calculation accuracy.

[0032] Resource allocation proposal table 414 shows proposed destinations for VMs / VVOLs before migration, namely which device and which SC. Resource allocation proposal table 414 includes the following fields: "Device ID" before migration, "VVOL ID" before migration, "VM name" before migration, "Temporary Device ID" at the destination, "Temporary SC ID" at the destination, and "Temporary SC Capacity" at the destination.

[0033] Figure 11 is a flowchart showing the processing procedure of the storage management system. The migration management server 10 sequentially executes the following steps S101 to S106. Step S101: The migration management server 10 accepts registration of source and destination storage and provider information, and the operational information collection unit 403 collects various information. This step makes all programs on the migration management server 10 able to use all the information held by each storage device and provider. The process then proceeds to step S102.

[0034] In step S102, the migration plan determination unit 401 calculates the required capacity and processing load for each VVOL group. Then, the process proceeds to step S103. In step S103, the migration plan determination unit 401 performs resource allocation calculations for each VVOL group. Then, the process proceeds to step S104. In step S104, the migration plan determination unit 401 generates and presents the storage / VM-side configuration commands for creating SC / PE / VVOLs that meet the resource placement proposal. The process then proceeds to step S105.

[0035] Step S105 The transition processing instruction unit 402 proceeds to step S106 if it receives input indicating that the proposed plan is acceptable (S105; YES). If it does not receive input indicating that the proposed plan is acceptable (S105; NO), the process terminates. In step S106, the migration processing instruction unit 402 executes operation commands to each storage device and the VM overall management server 20, and then terminates the process.

[0036] Figure 12 is a flowchart detailing step S102. In step S102, the transition plan determination unit 401 sequentially executes the next steps S201 to S206. In step S201, the migration plan determination unit 401 confirms the VVOL groups with the same VM name. Furthermore, it refers to the application function of the SLUs that constitute the VVOL and calculates the set of VVOLs that will form the VVOL group. After that, it proceeds to step S202. For example, a real data volume that stores actual data and a snapshot volume that stores snapshots of the real data volume will belong to the same group if they have the same VM name. Similarly, a virtual volume for local copies and a configuration volume that stores configuration information for the real data volume will belong to the same group as the real data volume with the same VM name. On the other hand, a remote copy volume that stores copy data from a remote copy of the real data volume will not belong to the same group as the real data volume with the same VM name, and will be controlled to be located on different storage.

[0037] In step S202, the transition plan determination unit 401 calculates the total capacity of each VVOL in the VVOL group and determines the required capacity for the VVOL group. Then, the process proceeds to step S203. In step S203, the transition plan determination unit 401 aggregates the load information of all VVOLs constituting the VVOL group at each time point from the information in the IO performance history table, and uses this as the IO performance history for the VVOL group. After that, the process proceeds to step S204.

[0038] In step S204, the migration plan determination unit 401 lists all management operations for all VVOLs constituting the VVOL group at each time point in the past period based on the information in the operation log. Then, the process proceeds to step S205. The period can be set as appropriate, for example, one day or one week. Alternatively, the user may specify the period by input. In step S205, the transition plan determination unit 401 calculates the total load criterion value of management operations for all VVOLs constituting the VVOL group at each time point in a certain past period from the information in the operation log, and sets this as the management operation performance history for the VVOL group. Then, the process proceeds to step S206.

[0039] Step S206: The transition plan determination unit 401 checks whether processing has been performed on all VVOL groups. If there are still unprocessed VVOL groups (S206; NO), the process returns to step S202. If processing has been performed on all VVOL groups (S206; YES), the process ends.

[0040] Figure 13 is a flowchart detailing step S103. In step S103, the migration plan determination unit 401 sequentially executes the next steps S301 to S312. Between the storage unit and the management module, the management module generally has fewer available computing resources. Therefore, this flowchart prioritizes considering the processing load of the management module. In particular, the CPU load of the management module is used as the primary criterion. The process involves adding up the total values ​​for each VM group, referencing the history for each time period in the past, and calculating the placement so that it fits within the hardware limit. In addition, the migration destination candidates are selected from devices with low device ID numbers. Note that this flowchart is just one example of an optimal placement algorithm, and other algorithms may be used. Any algorithm is acceptable as long as it can determine a placement where the expected performance and capacity of the management module and the main unit for each VVOL group fit within the upper limit of the migration destination.

[0041] In step S301, the migration plan determination unit 401 processes the VVOL group with the smallest number among the VVOL groups for which a provisional migration destination has not been determined, and selects a migration destination storage that meets the SLU application function conditions of the VVOL group to be processed. After that, the process proceeds to step S302.

[0042] Step S302: The migration plan determination unit 401 calculates the CPU utilization rate of the management module of the destination storage at each time point from the sum of the load criteria for the VVOL group at each time point. Then, the process proceeds to step S303. Specifically, the CPU utilization rate of the management operation commands of the management module is calculated from the hardware specifications that form the basis of the criteria and the destination hardware specifications. Any method can be used for the calculation formula, such as a simple ratio or a model formula created from the ratio of CPU type architecture and frequency. Step S303 The migration plan determination unit 401 determines whether the total estimated CPU utilization of the management module will be within 100%. If it is within 100% (S303; YES), proceed to step S304. If it is not within 100% (S303; NO), proceed to step S308. Step S304 The migration plan determination unit 401 determines whether the total estimated memory capacity of the management module fits within the memory capacity of the migration destination. If it fits (S303; YES), proceed to step S304. If it does not fit (S303; NO), proceed to step S308.

[0043] In step S305, the migration plan determination unit 401 calculates the expected I / O load for each time point of the destination storage unit from the sum of the I / O performance history for each time point of the VVOL group. Then, the process proceeds to step S306. Similar to step S304, any method may be used to calculate the expected I / O load (sizing). The calculation formula may be a simple ratio, or it may be calculated from a corresponding model formula between hardware specifications and I / O load, etc.

[0044] Step S306 The migration plan determination unit 401 determines whether the total estimated I / O load of the main unit will fit within 100% CPU utilization. If it does (S306; YES), proceed to step S307. If it does not fit (S306; NO), proceed to step S308. Step S307 The migration plan determination unit 401 determines whether the total estimated capacity pool of the main unit fits within the storage capacity of the destination. If it fits (S307; YES), proceed to step S310. If it does not fit (S307; NO), proceed to step S308.

[0045] Step S308 The migration plan determination unit 401 determines whether all storage devices have been confirmed as potential migration destinations. If there are still unconfirmed storage devices (S308; NO), the process returns to step S301. If all storage devices have been confirmed as potential migration destinations (S308; YES), the process proceeds to step S309. Step S309 The transition plan determination unit 401 outputs an error and terminates the process.

[0046] In step S310, the migration plan determination unit 401 adds the total estimated CPU utilization, memory capacity, I / O load, and capacity of the management module and the main unit to the destination storage. Then, the process proceeds to step S311. In step S311, the migration plan determination unit 401 updates the resource allocation proposal table. Then, the process proceeds to step S312. Step S312: The migration plan determination unit 401 determines whether the migration destination has been confirmed for all VVOL groups. If there are any unconfirmed VVOL groups remaining (S312; NO), the process returns to step S301. If all VVOL groups have been confirmed (S312; YES), the process terminates.

[0047] Figure 14 is a detailed flowchart of step S104. In step S104, the transition plan determination unit 401 sequentially executes the next steps S401 to S407. In step S401, the migration plan determination unit 401 creates storage container and pool creation commands listed in the resource allocation proposal table for each storage device. Then, the process proceeds to step S402. In step S402, the migration plan determination unit 401 creates ALU / PE creation commands corresponding to the storage containers for each storage device. Then, the process proceeds to step S403. Note that it is acceptable to create one ALU for each storage container or one ALU for each storage device; it is sufficient that at least one corresponding ALU exists.

[0048] In step S403, the migration plan determination unit 401 creates host path setting commands for each storage device, connecting the host where the migrated VMs will run with the ALU. Then, the process proceeds to step S404. In step S404, the migration plan determination unit 401 registers the post-migration provider for the VM central management server and creates a PE scan execution command. Then, the process proceeds to step S405. Step S405: The migration plan determination unit 401 creates a command for the VM central management server to create a VVOL that will run the migrated VM via the provider. Then, the process proceeds to step S406. In step S406, the migration plan determination unit 401 creates a command for the VM central management server to copy data to the VVOL on which the migrated VMs will run via the provider. Then, the process proceeds to step S407. Step S407 The transition plan determination unit 401 presents the commands created in each step to the user and terminates the process. The presentation to the user may be the command itself, a sentence expressing the meaning of the operation in natural language, or a graphical representation of the operation. Alternatively, all commands may be presented to the user and their approval may be requested, or only some of the commands may be presented and approval may be requested. [Examples]

[0049] Figure 15 is a configuration diagram of the storage management system of Example 2. The storage management system of Example 2 differs from that of Example 1 in that the storage cluster is included in the targets managed by the source and destination providers. In Figure 15, the source storage system 2 is a storage cluster 80 that includes two storage nodes 81. The destination storage system is a storage device 60 and a storage cluster 90, and the storage cluster 90 has multiple storage nodes 91. In addition, one of the multiple storage nodes 91 is equipped with a provider 100.

[0050] A storage cluster is a logical collection of multiple storage nodes within a cluster. In a cluster environment where VVOL groups are placed without spanning across storage nodes and ALU / PE is created for each storage node, resource allocation that considers the internal storage nodes rather than the entire storage cluster becomes important when considering I / O performance.

[0051] In this embodiment, it is more important to consider the nodes within the cluster when allocating resources than whether the source and destination providers are external or internal. Therefore, as an example, the provider 100 managing the source storage cluster 80 is shown as an external server, and the destination storage cluster 90 has a cluster-internal provider. Furthermore, although the example shows a configuration where the provider is located on a representative storage node rather than each storage node having its own provider, this does not limit the configuration of the present invention.

[0052] In the memory images shown in Figures 9 and 10, various information is displayed for each device ID. However, in the case of Example 2, each device ID is considered a storage node, and the table structure has cluster ID information that indicates a large storage cluster encompassing multiple storage nodes.

[0053] Figure 16 is a flowchart detailing the resource allocation calculation for each VVOL group in Example 2 (step S103). In step S103, the migration plan determination unit 401 sequentially executes the following steps S501 to S513. In step S501, the migration plan determination unit 401 processes the VVOL group with the smallest number among the VVOL groups for which a provisional migration destination has not been determined, and selects a migration destination storage cluster or storage device that matches the SLU application function conditions of the VVOL group to be processed. Then, the process proceeds to step S502.

[0054] In step S502, the migration plan determination unit 401 calculates the CPU utilization rate of the management module of the destination storage at each time point from the sum of the load criteria for the VVOL group at each time point. Then, the process proceeds to step S503. Specifically, the CPU utilization rate of the management operation commands of the management module is calculated from the hardware specifications that form the basis of the criteria and the destination hardware specifications. Any method can be used for the calculation formula, such as using a simple ratio or a model formula created from the ratio of CPU type architecture and frequency. Step S503 The migration plan determination unit 401 determines whether the total estimated CPU utilization of the management module will be within 100%. If it is within 100% (S503; YES), proceed to step S504. If it is not within 100% (S503; NO), proceed to step S509. Step S504 The migration plan determination unit 401 determines whether the total estimated memory capacity of the management modules fits within the memory capacity of the migration destination. If it fits (S503; YES), proceed to step S504. If it does not fit (S503; NO), proceed to step S509.

[0055] In step S505, the migration plan determination unit 401 selects a node of the destination storage cluster from the sum of the I / O performance history for each time point of the VVOL group and calculates the expected I / O load for each time point of the main unit. Then, the process proceeds to step S506. Similar to step S504, any method may be used to calculate the expected I / O load (sizing). The calculation formula may be a simple ratio, or it may be calculated from a corresponding model formula between hardware specifications and I / O load, etc.

[0056] Step S506 The migration plan determination unit 401 determines whether the total estimated I / O load of the main unit will fit within 100% CPU utilization. If it does (S506; YES), proceed to step S507. If it does not fit (S506; NO), proceed to step S508. Step S507 The migration plan determination unit 401 determines whether the total estimated capacity pool of the main unit fits within the storage capacity of the destination. If it fits (S507; YES), proceed to step S511. If it does not fit (S507; NO), proceed to step S508.

[0057] Step S508 The migration plan determination unit 401 determines whether all storage nodes have been selected and confirmed. If there are still unconfirmed storage nodes (S508; NO), the process returns to step S505. If all storage nodes have been selected and confirmed (S508; YES), the process proceeds to step S509. Step S509 The migration plan determination unit 401 determines whether all devices (storage devices or storage clusters) have been confirmed as candidates for migration. If there are still unconfirmed devices (S509; NO), the process returns to step S501. If all devices have been confirmed as candidates for migration (S509; YES), the process proceeds to step S510. Step S510 The transition plan determination unit 401 outputs an error and terminates the process.

[0058] In step S511, the migration plan determination unit 401 adds the total estimated CPU utilization, memory capacity, I / O load, and capacity of the management module and the main unit to the destination storage. Then, the process proceeds to step S512. Step S512: The migration plan determination unit 401 updates the resource allocation proposal table. Then, the process proceeds to step S513. Step S513: The migration plan determination unit 401 determines whether the migration destination has been confirmed for all VVOL groups. If there are any unconfirmed VVOL groups remaining (S513; NO), the process returns to step S501. If all VVOL groups have been confirmed (S513; YES), the process terminates.

[0059] As described above, the storage management system disclosed in the embodiment is a storage management system having a processor and managing a plurality of storage devices, each of which generates and provides virtual volumes to a host, and holds a protocol endpoint to which the virtual volumes are accessed and a storage container from which the virtual volumes are generated, and when multiple virtual volumes are migrated from a plurality of source storage devices to a plurality of destination storage devices, the processor configures a virtual volume group with the plurality of virtual volumes, configures a plurality of virtual volume groups, and determines a destination storage device for each of the plurality of virtual volume groups to which the plurality of virtual volumes of the virtual volume group will be migrated together, based on the capacity and load of each virtual volume group, and migrates them. This configuration and operation allows the storage management system to modify the environment before and after the migration, enabling it to determine the appropriate placement of virtual volumes.

[0060] Furthermore, the virtual volume group includes the multiple virtual volumes, generates the storage container and protocol endpoint necessary for the migration destination of the multiple virtual volumes, and migrates the multiple virtual volumes of the virtual volume group together to the destination storage device. At this time, the multiple virtual volumes of the virtual volume group are migrated to the same destination storage device. Therefore, multiple virtual volumes can be placed on the same storage device.

[0061] Furthermore, the virtual volume is associated with a virtual machine, and the virtual volume group is configured based on the associated virtual machine. Therefore, the appropriate placement of virtual volumes can be determined on a per-virtual machine basis.

[0062] As an example, the virtual volume group may include snapshot volumes of the virtual volumes. Therefore, snapshot volumes can be placed on the same storage device as virtual volumes.

[0063] Furthermore, as an example, the load on the virtual volume group is characterized by including the management load of the virtual volume group and the load of data input / output to the plurality of virtual volumes. Therefore, it is possible to determine the appropriate placement of virtual volumes by considering the management load of the virtual volume group and the load of data input / output to the multiple virtual volumes.

[0064] As an example, the storage management system calculates the management load based on the management history of the virtual volume group and calculates the data input / output load based on the data input / output history of the multiple virtual volumes. Therefore, the management load of the virtual volume group and the data input / output load to the multiple virtual volumes can be easily determined, and an appropriate virtual volume arrangement can be decided considering these loads.

[0065] 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 to make the present invention easier to understand, and are not necessarily limited to those having all the configurations described. Furthermore, it is possible to replace or add configurations, not just delete them. [Explanation of Symbols]

[0066] 10: Migration management server, 20: VM overall management server, 30: Host, 31-32: Virtual machine, 33: Logical unit, 34: Datastore, 40, 60: Storage device, 50: VM provider management server, 201: Control software, 202: Configuration management unit, 203: Operation information management unit, 208: Configuration change unit, 401: Migration plan judgment unit, 402: Migration processing instruction unit, 403: Operation information collection unit

Claims

1. In a storage management system having a processor and managing multiple storage devices, Each of the aforementioned plurality of storage devices generates and provides virtual volumes to the host, and holds a protocol endpoint to which the virtual volumes are accessed, and a storage container from which the virtual volumes are generated. When migrating multiple virtual volumes from multiple source storage devices to multiple destination storage devices, the processor: Multiple virtual volumes constitute a virtual volume group. Multiple virtual volume groups are configured as described above. Based on the capacity and load of each of the aforementioned virtual volume groups, the destination storage device to which multiple virtual volumes of each virtual volume group will be migrated together is determined for each of the aforementioned virtual volume groups, and the migration is performed. A storage management system characterized by the following features.

2. A storage management system according to claim 1, The virtual volume group includes the plurality of virtual volumes, The system generates the necessary storage containers and protocol endpoints for the migration destination of the multiple virtual volumes, and migrates the multiple virtual volumes of the virtual volume group to the destination storage device. A storage management system characterized by the following features.

3. A storage management system according to claim 2, The plurality of virtual volumes of the virtual volume group are migrated to the same destination storage device. A storage management system characterized by the following features.

4. A storage management system according to claim 2, The aforementioned virtual volume is associated with a virtual machine, The virtual volume group is configured based on the associated virtual machine. A storage management system characterized by the following features.

5. A storage management system according to claim 2, The virtual volume group includes snapshot volumes of the virtual volumes. A storage management system characterized by the following features.

6. A storage management system according to claim 1, The load on the virtual volume group includes the management load of the virtual volume group and the load of data input / output to the plurality of virtual volumes. A storage management system characterized by the following features.

7. A storage management system according to claim 2, The management load is calculated based on the management history of the virtual volume group, and the data input / output load is calculated based on the data input / output history of the multiple virtual volumes. A storage management system characterized by the following features.

8. A storage management method in a storage management system having a processor and managing multiple storage devices, Each of the aforementioned plurality of storage devices generates and provides virtual volumes to the host, and holds a protocol endpoint to which the virtual volumes are accessed, and a storage container from which the virtual volumes are generated. When migrating multiple virtual volumes from multiple source storage devices to multiple destination storage devices, the processor, The steps include: configuring a virtual volume group using multiple virtual volumes; The steps include configuring multiple virtual volume groups, Based on the capacity and load of each of the aforementioned virtual volume groups, the steps include determining a destination storage device for migrating multiple virtual volumes of each of the aforementioned virtual volume groups together, and then migrating them. A storage management method characterized by including the following.

Images