Management system, management method, and management program

Abstract

To automatize a physical structure tuning for a work load using the size and cost of a data source.SOLUTION: A management server has a resource information table to store instance information to specify the instance implemented in a management system and to store the database structure to specify the block number and block size of the block composing the database for each construction condition combining the cost to use the management system and the data size of the database to construct a storage. The management server acquires the construction condition combined by the cost and the data size, acquires the instance information of the construction condition similar to the acquired construction condition and acquires the resource information constituting the database structure, and mounts the acquired resource information in the storage.SELECTED DRAWING: Figure 1

Description

[Technical Field]

[0001] The present invention relates to a management system, a management method, and a management program. [Background technology]

[0002] Patent Document 1 discloses an application platform selection system that supports the selection of an optimal application platform in system construction. In this application platform selection system, a server includes a database that stores each platform software in association with characteristic information of the platform software, and includes means for determining the types of platform software required based on the system requirements input for the system to be constructed and outputting the types on a screen, extracting one or more applicable platform software from the database in accordance with the selection conditions input for each platform software type output on the screen, creating all combinations that constitute the application platform based on the one or more platform software extracted for each type, and determining each of all created combinations as application platform candidates.

[0003] Patent Document 2 discloses a communication system for building and optimizing a deployment pattern. This deployment pattern optimization aggregates event and configuration data of a previous system. Based on the aggregated data, a metadata model of the previous system is generated. Components of an initial deployment pattern for a new system are identified. Target non-functional requirements (NFRs) and target service levels for the new system are determined. Based on the metadata model, previous systems having components that match or are similar to the components of the initial deployment pattern are identified. The performance of the previous systems is compared with the NFRs and target service levels. A new deployment pattern for the new system is generated. The new deployment pattern includes changes to the components identified in the initial deployment pattern. Recommendations for deploying the new system using the new deployment pattern are generated. [Prior art documents] [Patent documents]

[0004] [Patent Document 1] Japanese Patent Application Laid-Open No. 2014-96026 [Patent Document 2] U.S. Patent Publication No. 2018-0165385 Summary of the Invention [Problem to be solved by the invention]

[0005] Database cloud services are moving towards serverless architectures, minimizing the burden of server management on users. However, tuning the physical configuration for a workload still requires users' knowledge and experience. Tuning to match the database performance requirements and balancing this with the estimated costs requires trial and error and a lot of work.

[0006] However, in Patent Document 1, the existing function list is merely viewed and the optimum example is selected, so the list must be updated manually and there is no mention of automatic updating. Patent Document 2 does not mention costs.

[0007] The present invention aims to automate tuning of physical configurations for workloads using the size and cost of data sources. [Means for solving the problem]

[0008] A management system that is one aspect of the invention disclosed in this application is a management system having a management server and storage, wherein the management server has a resource information table that stores instance information that specifies instances to be implemented in the management system and a database configuration that specifies the number of blocks and block size of blocks that make up the database for each construction condition that is a combination of the cost of using the management system and the data size of the database to be constructed in the storage, and the management server is characterized by executing a first acquisition process that acquires construction conditions that are a combination of cost and data size, a resource calculation process that acquires resource information from the resource information that is instance information and database configuration of construction conditions similar to the construction conditions acquired by the first acquisition process, and a resource addition process that mounts the resource information acquired by the resource calculation process to the storage. [Effects of the Invention]

[0009] According to a representative embodiment of the present invention, tuning of a physical configuration for a workload can be automated using the size and cost of data sources. Problems, configurations, and effects other than those described above will become clear from the following description of the examples. [Brief explanation of the drawings]

[0010] [Figure 1] FIG. 1 is an explanatory diagram illustrating an example of the system configuration of a management system. [Figure 2] FIG. 2 is a block diagram showing an example of the hardware configuration of a computer. [Figure 3] FIG. 3 is a block diagram illustrating an example of a functional configuration of the management system. [Figure 4] FIG. 4 is a flowchart showing an example of a DB construction processing procedure performed by the management system. [Figure 5] FIG. 5 is a flowchart showing a detailed example (first half) of the resource calculation process (step S402) shown in FIG. [Figure 6] FIG. 6 is a flowchart showing a detailed example (second half) of the resource calculation process (step S402) shown in FIG. [Figure 7] FIG. 7 is an explanatory diagram showing an example of a client screen displayed on a client. [Figure 8] FIG. 8 is a flowchart illustrating a detailed example of the processing procedure of the resource addition processing (step S403) illustrated in FIG. [Figure 9] FIG. 9 is a flowchart showing a detailed example of the processing procedure of the DB parameter calculation process (step S404) shown in FIG. [Figure 10] FIG. 10 is a flowchart illustrating an example of a DB operation processing procedure performed by the management system. [Figure 11] FIG. 11 is a flowchart illustrating a detailed example of the DB parameter update process (step S1001) illustrated in FIG. [Figure 12] FIG. 12 is a flowchart showing a detailed example (first half) of the resource update process (step S1002) shown in FIG. [Figure 13] FIG. 13 is a flowchart showing a detailed example of the processing procedure (second half) of the resource update processing (step S1002) shown in FIG. DETAILED DESCRIPTION OF THE INVENTION

[0011] <Figure 1: Example of management system configuration> 1 is an explanatory diagram showing an example of the system configuration of a management system 100. The management system 100 has a management server 101 and storage 102. The management system 100 is communicably connected to a client 103 via a network 104 such as the Internet, a LAN (Local Area Network), or a WAN (Wide Area Network).

[0012] The client 103 receives, through operation by the user 130, data size and cost related to the services (for example, virtual servers and applications running on the virtual servers) provided by the management system 100, and transmits them to the management system 100.

[0013] The management system 100 automatically constructs an instance of a service to be provided to the client 103 and a database (hereinafter referred to as DB) for using the service in the storage 102 according to the received data size and cost. A DBMS (Data Base Management System) is implemented in the management server 101. The DBMS accesses the DB constructed in the storage 102.

[0014] <Figure 2: Example of hardware configuration of computers (management server 101, client 103)> FIG. 2 is a block diagram showing an example of the hardware configuration of a computer (management server 101, client 103). The computer 200 has a processor 201, a storage device 202, an input device 203, an output device 204, and a communication interface (communication IF) 205. The processor 201, the storage device 202, the input device 203, the output device 204, and the communication IF 205 are connected via a bus 206. The processor 201 controls the computer 200. The storage device 202 serves as a working area for the processor 201. The storage device 202 is a non-transitory or temporary recording medium that stores various programs and data. Examples of the storage device 202 include a read-only memory (ROM), a random access memory (RAM), a hard disk drive (HDD), and a flash memory. The input device 203 inputs data. Examples of the input device 203 include a keyboard, a mouse, a touch panel, a numeric keypad, a scanner, a microphone, and a sensor. The output device 204 outputs data. Examples of the output device 204 include a display, a printer, and a speaker. The communication IF 205 connects to the network 104 and transmits and receives data.

[0015] <Figure 3: Example of functional configuration of management system 100> 3 is a block diagram showing an example of the functional configuration of the management system 100. The management system 100 includes an acquisition unit 301, a resource calculation unit 302, a resource addition unit 303, a DB parameter calculation unit 304, and a DB parameter update unit 305. Specifically, the acquisition unit 301, the resource calculation unit 302, the resource addition unit 303, the DB parameter calculation unit 304, and the DB parameter update unit 305 are functions that are realized by, for example, having the processor 201 execute a program stored in the storage device 202 shown in FIG.

[0016] The acquisition unit 301 acquires data from the client 103. This acquired data includes, as required data input by the user 130 of the client 103, the cost, the data size, and the group ID of the group to which the user 130 belongs.

[0017] The cost is the fee paid by the user 130 to the operator of the management system 100 to build a virtual server instance and a DB in the storage 102 of the management system 100. The data size is the capacity of the DB.

[0018] The group ID may be, for example, a subnet of the IP (Internet Protocol) address of the client 103. Optional data may also include IOPS (the number of reads and writes per second, or the number of IO accesses) and throughput.

[0019] Of the required data (excluding the group ID) and optional data, at least the required data (excluding the group ID) is referred to as a construction condition.

[0020] The resource calculation unit 302 calculates resource information based on the data acquired by the acquisition unit 301. The resource information is information related to the instances and DBs of the virtual servers, which are resources, and specifically, for example, the instance information and DB configuration described below. The resource calculation unit 302 has a resource information table 320, a first cost information table 321, and a second cost information table 322.

[0021] The resource information table 320 stores, for each group ID, the construction conditions and resource information (instance information and DB configuration) that satisfies the construction conditions. The instance information includes the instance type indicating the type of instance, the number of virtual processor cores (vCPU) for that instance type, and the memory size (MS). The DB configuration is the number of blocks that make up the DB and their block size.

[0022] The first cost information table 321 stores a plurality of combinations of the first monthly cost per block, block size, IOPS, and throughput.

[0023] The second cost information table 322 stores the second monthly cost for each instance type. The instance type has the number of virtual processor cores (vCPU) and the memory size (MS).

[0024] The resource adding unit 303 adds a virtual server instance and a database to the storage 102 based on the resource information calculated by the resource calculating unit 302 .

[0025] The DB parameter calculation unit 304 calculates DB parameters based on the data acquired by the acquisition unit 301. The DB parameters 324 are parameters required for the DB and are set within the DBMS. The DB parameters 324 are parameters related to the instances belonging to the group for each group ID, and include, for example, the number of parallel executions and the amount of memory used.

[0026] The number of parallel executions is the number of cores (vCPU) of the virtual processor that are used to execute the virtual processors of the virtual server in parallel in the database. The amount of memory used is the amount of memory that can be used by the DBMS.

[0027] The DB parameter update unit 305 updates the DB in the storage with the DB parameters 324 calculated by the DB parameter calculation unit 304. The resource update unit 306 updates the resources constructed in the storage .

[0028] <Figure 4 DB construction process> 4 is a flowchart showing an example of a DB construction processing procedure by the management system 100. The management server 101 acquires data transmitted from the client 103 (step S401).

[0029] Next, the management server 101 executes a resource calculation process using the resource calculation unit 302 (step S402). Next, the management server 101 executes a resource addition process using the resource addition unit 303 (step S403). Next, the management server 101 executes a DB parameter calculation process using the DB parameter calculation unit 304 (step S404). Then, the management server 101 uses the DB parameters calculated in the DB parameter calculation process (step S404) to build a DB in the storage 102 (step S405). This completes the DB construction in the storage 102.

[0030] <Figure 5 Resource calculation process (step S402)> FIG. 5 is a flowchart showing a detailed example (first half) of the resource calculation process (step S402) shown in FIG.

[0031] (Step S501) The management server 101 determines whether or not there is a resource in the resource information table 320 with construction conditions similar to the construction conditions acquired in step S401 (hereinafter referred to as acquired construction conditions) within the group to which the user 130 belongs. To determine the similarity between the acquired construction conditions and the construction conditions in the resource information table 320, the management server 101 calculates the distance between the vectors, treating both construction conditions as vectors, and determines that the two construction conditions are similar if the distance between the vectors is equal to or less than a threshold value. Also, cosine similarity may be used instead of the distance between the vectors.

[0032] If the resource information table 320 contains a resource with construction conditions similar to the construction conditions acquired in step S401 within the group to which the user 130 belongs (step S501: Yes), the process proceeds to step S502. On the other hand, if the resource information table 320 does not contain a resource with construction conditions similar to the acquired construction conditions (step S501: No) in step S501, the process proceeds to step S503.

[0033] (Step S502) The management server 101 acquires the resource information (instance information and DB configuration) whose construction conditions are most similar to the acquired construction conditions from the resource information table 320, outputs it to the resource addition unit 303, and proceeds to resource addition processing (step S403). This makes it possible to reuse existing resources, simplify the resource calculation processing (step S402), and speed up DB construction. After this, the process proceeds to resource addition processing (step S403).

[0034] (Step S503) The management server 101 calculates the provisional DB capacity DBTS based on the data size of the acquired construction conditions. Specifically, for example, the management server 101 calculates the provisional DB capacity DBTS by multiplying the data size of the acquired construction conditions by a value greater than 1 (for example, 2.5 times). Then, the process proceeds to step S504.

[0035] (Step S504) Next, the management server 101 determines whether the temporary DB capacity DBTS is lower than the minimum DB capacity MINVOL. If the temporary DB capacity DBTS is lower than the minimum DB capacity MINVOL (step S504: Yes), the process proceeds to step S505. If the temporary DB capacity DBTS is not lower than the minimum DB capacity MINVOL (step S504: No), the process proceeds to step S506.

[0036] (Step S505) Next, the management server 101 sets the number of blocks BNUM to BNUM=1, and sets the block size BVOL to BVOL=DBTS. The combination of the number of blocks BNUM and the block size BVOL is called a DB configuration. After this, the process proceeds to step S507.

[0037] (Step S506) The management server 101 sets the number of blocks BNUM to the value shown in the following formula (1).

[0038] BNUM=DBTS / MINVOL+1 (1)

[0039] The size of one block is determined by dividing the temporary DB capacity DBTS by the number of blocks BNUM (DBTS / BNUM).Then, the process proceeds to step S507.

[0040] (Step S507) Next, the management server 101 sets the IOPS and throughput. Specifically, for example, if the acquired construction conditions do not include optional data, the management server 101 sets the IOPS to the default of 3000 iops and the throughput to the default of 125 MB / sec. If the acquired construction conditions include optional data, the management server 101 sets the IOPS and throughput to the IOPS and throughput of the optional data. After this, the process proceeds to step S601 in FIG. 6.

[0041] FIG. 6 is a flowchart showing a detailed example (second half) of the resource calculation process (step S402) shown in FIG.

[0042] (Step S601) The management server 101 refers to the first cost information table 321, extracts the first monthly cost C1 corresponding to the DB configuration (number of blocks BNUM and block size BVOL) of step S505 or S506, and calculates the remaining budget RC by subtracting the cost of the acquired construction conditions from the first monthly cost C1. The first monthly cost C1 corresponding to the DB configuration is the monthly cost that matches the DB configuration. Furthermore, if there is no monthly cost that matches the DB configuration in the first cost information table 321, the first monthly cost C1 corresponding to the DB configuration is the monthly cost that makes the DB configuration the smallest of all the monthly costs that exceed the DB configuration.

[0043] (Step S602) The management server 101 selects from the second cost information table 322 the instance type whose second monthly cost C2 is the largest and is equal to or less than the remaining budget RC, and acquires the second monthly cost C2.

[0044] (Step S603) The management server 101 subtracts the second monthly cost C2 from the remaining budget RC to update the remaining budget RC.

[0045] (Step S604) The management server 101 transmits the instance information, DB configuration, and cost information to the client 103. The instance information is the instance type selected in step S602 with the largest second monthly cost C2, the number of cores vCPU of its virtual processor, and the memory size MS. The cost information is the first monthly cost C1 extracted in step S601, the second monthly cost C2 selected in step S602, and the remaining budget RC after the update in step S603.

[0046] (Step S605) The management server 101 determines whether or not a confirmation signal has been received from the client 103. If a confirmation signal has not been received from the client 103 (step S605: No), the management server 101 proceeds to step S401 and attempts to acquire data from the client 103. On the other hand, if a confirmation signal has been received from the client 103 (step S605: Yes), the management server 101 proceeds to step S606.

[0047] (Step S606) The management server 101 outputs the resource information (instance information and DB configuration) to the resource addition unit 303, and proceeds to resource addition processing (step S403).

[0048] <Figure 7 Client screen> 7 is an explanatory diagram showing an example of a client screen displayed on the client 103. The client screen 700 has a construction condition setting area 701 and a recommended configuration display area 702. The construction condition setting area 701 has a cost setting section 711, a data size setting section 712, and a send button 713.

[0049] The cost setting unit 711 is a user interface for setting the cost of the construction conditions through operation by the user 130. The data size setting unit 712 is a user interface for setting the data size of the construction conditions through operation by the user 130. The send button 713 is a user interface for sending the cost set in the cost setting unit 711 and the data size set in the data size setting unit 712 as construction conditions to the management server 101 when pressed by the user 130.

[0050] Although not shown, the setting section for option data (IPOS and throughput) is also included in the construction condition setting area 701, and is sent to the management server 101 when the send button 713 is pressed.

[0051] The recommended configuration display area 702 is an area that displays instance information 721, DB configuration 722, and cost information 723. The instance information 721, DB configuration 722, and cost information 723 are transmitted from the management server 101 to the client 103 in step S604. The confirmation button 724 is a user interface for transmitting a confirmation signal to the management server 101 when pressed by the user 130. When the management server 101 receives the confirmation signal (step S605: Yes), it executes step S606.

[0052] <Figure 8 Resource Addition Processing (Step S403)> FIG. 8 is a flowchart illustrating a detailed example of the processing procedure of the resource addition processing (step S403) illustrated in FIG.

[0053] (Step S801) The management server 101 mounts the instance and DB in the storage 102 based on the instance information 721 and DB configuration 722 .

[0054] (Step S802) The management server 101 determines whether the number of blocks BNUM in the DB configuration 722 is greater than 1. If the number of blocks BNUM is greater than 1 (step S802: Yes), the process proceeds to step S803. If the number of blocks BNUM is not greater than 1 (step S802: No), the process proceeds to DB parameter calculation processing (step S404).

[0055] (Step S802) The management server 101 performs expansion of partitions, physical volumes (PVs), volume groups (VGs), logical volumes (LVs), and file systems (FSs). Specifically, for example, the management server 101 performs expansion according to the block size and number of blocks per partition. Then, the process proceeds to DB parameter calculation processing (step S404).

[0056] <Figure 9 DB parameter calculation process (step S404)> FIG. 9 is a flowchart showing a detailed example of the processing procedure of the DB parameter calculation process (step S404) shown in FIG.

[0057] (Step S901) The management server 101 acquires the resource information (instance information and DB configuration) output in step S502 or S606.

[0058] (Step S902) The management server 101 calculates the similarity between the resource information acquired in step S901 and each piece of resource information of the instance group identified by the group ID included in the data acquired in step S401.

[0059] The resource information includes the number of virtual processor cores vCPU, memory size MS, number of blocks BNUM, and block size BVOL. To determine the similarity between pieces of resource information, the management server 101 calculates the distance between the vectors as the similarity, using each of the pieces of resource information as a vector. The shorter the distance between the vectors, the more similar the pieces of resource information are (the higher the similarity). Alternatively, the similarity may be determined by cosine similarity instead of vector distance. The greater the cosine similarity, the more similar the pieces of resource information are.

[0060] (Step S903) The management server 101 determines whether a similar instance exists in the same group. A similar instance is an instance whose similarity is equal to or greater than a threshold value, or an instance whose similarity is among the top N (N is a preset integer equal to or greater than 1). If a similar instance exists (step S903: Yes), the process proceeds to step S904. If a similar instance does not exist (step S903: No), the process proceeds to step S905.

[0061] (Step S904) The management server 101 acquires the DB parameters of the DBMS held by the instance having the highly similar resource information, and then proceeds to step S405.

[0062] (Step S905) The management server 101 calculates sizing from the current resource information and sets the DB parameters 324 by multiplying the base DB parameters by sizing. The base DB parameters are the DB parameters of the minimum size that the DBMS can execute for the given resources. For example, if the DB parameter 324 is the number of parallel executions, the minimum number of parallel executions is the minimum required number of CPU cores, and if it is the amount of memory used, it is the minimum required number of memories. The base DB parameters are preset information. Then, the process proceeds to step S405.

[0063] sizing = Number of CPU cores in current resource information / Number of CPU cores in minimum resource configuration

[0064] The minimum resource configuration is the virtual server configuration with the smallest DB parameter set among the virtual server candidates. In other words, the number of CPU cores in the minimum resource configuration is the number of parallel executions among the base DB parameter set.

[0065] <Figure 10 DB operation processing procedure> 10 is a flowchart showing an example of a DB operation processing procedure by the management system 100. The DB operation processing is a process for operating the DB constructed in the DB construction processing. In the DB operation, a query is input from the client 103 to the constructed DB, and the history of the execution time is stored in the DB.

[0066] (Step S1001) The management system 100 executes DB parameter update processing. The DB parameter update processing (step S1001) will be described later with reference to FIG.

[0067] (Step S1002) The management system 100 executes the resource update process (step S1002), which will be described later with reference to FIG.

[0068] <Figure 11 DB parameter update process (step S1001)> FIG. 11 is a flowchart illustrating a detailed example of the DB parameter update process (step S1001) illustrated in FIG.

[0069] (Step S1101) The management system 100 acquires the response time identified from the current resource information and, if any, the user requirements (e.g., requested response time). The response time is the time from when the client 103 sends a query to an instance to when it receives a response, and for example, the execution time of the query by the instance is used. Note that if there are multiple queries, a statistical value (average, maximum, minimum, median, or mode) of the execution times of the multiple queries is used. The requested response time is the response time required by the user and is set arbitrarily.

[0070] (Step S1102) The management system 100 determines whether the response time satisfies the required response time of the user requirements. If it does (step S1102: Yes), the process proceeds to the resource update process (step S1002). The same applies if the response time is acquired in step S1101 but the required response time of the user requirements is not acquired.

[0071] If the condition is not satisfied (step S1102: No), the process proceeds to step S1103. The same applies if the response time is not acquired within a predetermined period of time.

[0072] (Step S1103) The management system 100 repeatedly executes steps S1104 to S1109 until the response time is equal to or less than the required performance threshold and there is no room for changing the DB parameters 324. Although the number of parallel executions and the amount of memory used are set as the DB parameters 324, this means that such changes are not possible because they cannot be changed beyond the numbers set in the resource information (instance information and DB configuration).

[0073] (Step S1104) The management system 100 determines whether the number of resource CPU cores is greater than the current number of parallel executions. The number of resource CPU cores is the number of cores vCPU of the virtual processor in the current resource information. The number of parallel executions is the value calculated in step S905. If the number of resource CPU cores is greater than the current number of parallel executions (step S1104: Yes), the process proceeds to step S1105. If the number of resource CPU cores is not greater than the current number of parallel executions (step S1104: No), the process proceeds to step S1106.

[0074] (Step S1105) The management system 100 increases the number of parallel executions by a predetermined number, which is set in advance.

[0075] (Step S1106) The management system 100 determines whether the resource memory size (memory size MS) is greater than the maximum memory usage of the server. If the resource memory size (memory size MS) is greater than the maximum memory usage (step S1106: Yes), the management system 100 proceeds to step S1107. If the resource memory is not greater than the maximum memory usage (step S1106: No), the management system 100 proceeds to step S1108.

[0076] (Step S1107) The management system 100 increases the memory usage amount of the DB parameter 324 by a predetermined amount.

[0077] (Step S1108) The management system 100 estimates the planned cost based on the latest DB parameters. Specifically, for example, the management system 100 stores past DB parameters and costs, and generates a model that estimates costs when DB parameters are input through machine learning. Since the DB parameters are updated in steps S1105 and S1107, the management system 100 calculates the planned cost by inputting the latest updated DB parameters into the model.

[0078] (Step S1109) If the response time is equal to or less than the required performance threshold and there is no room for DB parameter changes, the management system 100 repeats steps S1104 to S1108. If the response time is equal to or less than the required performance threshold and there is no room for DB parameter changes, the management system 100 proceeds to step S1110.

[0079] (Step S1110) The management system 100 transmits to the client 103 multiple DB parameter proposals for which the deviation between the planned cost estimated in step S1108 and the user budget is less than a predetermined value, and sets the DB parameters using the DB parameter proposal selected by the client 103, or automatically sets the DB parameters with the lowest deviation. The user budget is the cost set in the cost setting section 711 on the client screen 700 in FIG. 7. The deviation is the difference (absolute value). Then, the process proceeds to resource update processing (step S1002).

[0080] This makes it possible to search for DB parameters that maximize performance within the given resource information during operation, and to prioritize the adoption of DB parameter proposals that are closest to the user's costs.

[0081] <Figure 12 Resource update process (step S1002)> FIG. 12 is a flowchart showing a detailed example (first half) of the resource update process (step S1002) shown in FIG.

[0082] (Step S1201) The management system 100 acquires state information of the instance and DB, and user requirements. The state information is, for example, the DB usage of the DB mounted on the storage 102. The required performance is, for example, the required IOPS and the required response time.

[0083] (Step S1202) The management system 100 determines whether the remaining capacity of the DB is equal to or greater than a predetermined amount. The remaining capacity of the DB is, for example, the value obtained by subtracting the DB usage amount from the total capacity of the DB. If the remaining capacity of the DB is equal to or greater than the predetermined amount (step S1202: Yes), the process proceeds to step S1206. If the remaining capacity of the DB is not equal to or greater than the predetermined amount (step S1202: No), the process proceeds to step S1203.

[0084] (Step S1203) The management system 100 sends an alert to the client 103 that the DB capacity is insufficient.

[0085] (Step S1204) The management system 100 adds to each block a capacity calculated by multiplying the DB usage by 1.25 and dividing the capacity by the number of blocks in the DB. Note that 1.25 is a preset value and is not limited to 1.25, as long as it is 1.00 or greater. The management system 100 transmits the size of each block after addition and the DB usage of the DB after addition as recommendation information to the client 103.

[0086] (Step S1205) The management system 100 expands the PV (Physical Volume), VG (Volume Group), LV (Logical Volume), FS (File System), and DB area in response to the capacity addition in step S1204.

[0087] (Step S1206) The management system 100 determines whether the response time, which is the query execution time, satisfies the requested response time. If it does (step S1206: Yes), the resource update process (step S1002) ends. If it does not (step S1206: No), the process proceeds to step S1301 in FIG. 13.

[0088] FIG. 13 is a flowchart showing a detailed example of the processing procedure (second half) of the resource update processing (step S1002) shown in FIG.

[0089] (Step S1301) The management system 100 determines whether or not there is a bottleneck in the instance. Specifically, for example, if the CPU usage rate of a virtual processor having cores of the number of cores vCPU is equal to or greater than a predetermined percentage (e.g., 80%), or if the memory usage rate (memory size MS / total memory) is equal to or greater than a predetermined percentage (e.g., 80%), the management system 100 determines that there is a bottleneck in the instance. Total memory refers to all memory held by the resource. If there is no bottleneck in the instance (step S1301: No), the process proceeds to step S1302, and if there is a bottleneck in the instance (step S1301: Yes), the process proceeds to step S1305.

[0090] (Step S1302) The management system 100 increases the IOPS and / or throughput of the resources (virtual server instances and DBs) by a predetermined percentage and changes the monthly planned cost. Specifically, for example, the management system 100 increases the IOPS and / or throughput of the resources, and refers to the first cost information table 321 and the second cost information table 322 to calculate multiple monthly planned costs after the increase.

[0091] (Step S1303) The management system 100 selects multiple types of increased monthly planned costs that are closest to the user's budget from the multiple types of increased monthly planned costs calculated in step S1302, and transmits them to the client 103. The user's budget is the cost set in the cost setting section 711 on the client screen 700 in FIG.

[0092] (Step S1304) The management system 100 changes the configuration to one selected from the options. The management system 100 accepts a selection of one of the multiple types of increased monthly planned costs from the client 103, and changes the IOPS and / or throughput of the resource to the increased IOPS and / or throughput corresponding to the selected increased monthly planned cost. This completes the resource update process (step S1304).

[0093] (Step S1305) The management system 100 refers to the resource information table 320 and determines whether the instance can be changed to an instance type equivalent to a number of cores (vCPUs) proportional to the CPU core count ratio. Specifically, for example, the management system 100 determines whether the instance type exists as an option, or, if it exists, whether the number of cores (vCPUs) of the instance type is equal to or less than a threshold. The CPU core count ratio is calculated by dividing the current performance (response time) by the required performance (required response time). If the change is possible (the number of cores in the instance type is equal to or less than the threshold) (step S1305: Yes), the process proceeds to step S1306. If the change is not possible (step S1305: No), the process proceeds to step S1309.

[0094] (Step S1306) The management system 100 refers to the resource information table 320, changes the instance to an instance type equivalent to the number of cores and vCPUs proportional to the CPU core count ratio, and calculates the estimated cost. For example, each cloud vendor defines usage fees based on the basic unit price of the instance type and its usage fee. The usage fee is set based on the monthly usage percentage (for example, assuming a fixed usage of 12 hours per day, the initial setting is 50%) and individual settings such as the number of additional CPU cores.

[0095] Therefore, for example, the planned cost is calculated as follows: instance type setting value (for example, a certain size of the instance type) x unit price (unit price amount of that size) x estimated usage frequency (for example, 50%) x number of multi-nodes (number of divisions; if the number of divisions is not calculated, it is 1). In step S1302, the increase is taken into consideration, so the value obtained by multiplying the estimated usage frequency by the increase in individual parameters such as IOPS and number of cores vCPU is added to the monthly planned cost.

[0096] (Step S1307) The management system 100 transmits a combination of the planned cost and the resource information used to calculate the planned cost to the client 103, and receives the combination selected by the client 103.

[0097] (Step S1308) The management system 100 temporarily suspends the DB, and changes the instance to an instance type corresponding to the number of cores and vCPUs proportional to the CPU core count ratio by referring to the resource information table 320. This ends the resource update process (step S1304).

[0098] (Step S1309) The management system 100 determines the number of divisions for the required performance acquired in step S1201. The number of divisions is the ratio of the number of CPU cores described above (fractions are rounded down). The number of divisions is the number of nodes in the multi-node system.

[0099] (Step S1310) The management system 100 corrects the DB performance settings. Specifically, for example, the management system 100 adds the number of divisions set in step S1309, that is, the number of nodes in the multi-node, to the DB parameters 324.

[0100] (Step S1311) The management system 100 calculates the planned cost using the number of divisions added as the number of multi-nodes to the DB parameters 324 in step S1310. The planned cost is calculated by multiplying the setting value of the single instance type (size indicating the size of the instance type) by the single instance unit price (the unit price of the instance type for that size) by the increase in individual parameters such as IOPS, number of cores, or vCPUs by the estimated usage frequency (for example, 50%) by the number of divisions (the number of divisions set in step S1309). The management system 100 then transmits the calculated estimated planned cost to the client 103. This completes the resource update process (step S1304).

[0101] In step S1311, the client 103 displays the estimated cost transmitted from the management system 100. This completes the resource update process (step S1304).

[0102] This allows resources to be expanded in response to additional requirements during operation. Also, multiple proposals can be presented to the user 130, starting with those with the smallest deviation from the budget.

[0103] As described above, according to the embodiment of the present invention, resource information that optimizes the balance between data size and cost can be provided to the user 130 with a small amount of work. This allows the user 130 to use the DB for a wider variety of data and analysis. Furthermore, by specifying the cost and original data size, appropriate resource information can be constructed, enabling basic operation. This makes it possible to recommend to the user 130 resource information that maximizes performance within a given cost.

[0104] The present invention is not limited to the above-described embodiments, and includes various modifications and equivalent configurations within the spirit and scope of the appended claims. For example, the above-described embodiments have been described in detail to clearly explain the present invention, and the present invention is not necessarily limited to configurations including all of the described configurations. Furthermore, part of the configuration of one embodiment may be replaced with the configuration of another embodiment. Furthermore, the configuration of another embodiment may be added to the configuration of one embodiment. Furthermore, part of the configuration of each embodiment may be added to, deleted from, or replaced with other configurations.

[0105] Furthermore, the aforementioned configurations, functions, processing units, processing means, etc. may be realized in part or in whole in hardware, for example by designing them as integrated circuits, or may be realized in software by having a processor interpret and execute a program that realizes each function.

[0106] Information such as programs, tables, files, etc. that realize each function can be stored in storage devices such as memory, hard disks, SSDs (Solid State Drives), or recording media such as IC (Integrated Circuit) cards, SD cards, and DVDs (Digital Versatile Discs).

[0107] In addition, the control lines and information lines shown are those that are considered necessary for the explanation, and do not necessarily show all the control lines and information lines that are necessary for implementation. In reality, it can be considered that almost all components are interconnected. [Explanation of symbols]

[0108] 100 Management Systems 101 Management Server 102 Storage 103 Client 130 users 301 Acquisition Department 302 Resource Calculation Department 303 Resource Addition Department 304 DB Parameter Calculation Unit 305 DB parameter update section 306 Resource Update Department 320 Resource Information Table 321 First Cost Information Table 322 Second Cost Information Table

Claims

1. A management system having a management server and a storage, the management server has a resource information table that stores, for each construction condition that is a combination of the cost of using the management system and the data size of a database to be constructed in the storage, instance information that defines an instance to be implemented in the management system and a database configuration that defines the number of blocks and block size of blocks that constitute the database; The management server a first acquisition process for acquiring a construction condition that is a combination of cost and data size; a resource calculation process for acquiring, from the resource information table, instance information of construction conditions similar to the construction conditions acquired by the first acquisition process and resource information which is a database configuration; a resource addition process for mounting the resource information acquired by the resource calculation process in the storage; A management system characterized by executing the above.

2. The management system according to claim 1, the management server has a first cost information table and a second cost information table; the first cost information table stores a block size for each first cost per block; the second cost information table stores a second cost for each instance type that defines the number of cores of a virtual processor that executes an instance and a memory size; In the resource calculation process, if the resource information does not contain instance information and database configuration of the similar construction conditions, the management server sets a specific database configuration based on the data size of the acquired construction conditions, extracts a specific first cost corresponding to the specific database configuration from the first cost information table, calculates a remaining budget by subtracting the cost of the acquired construction conditions from the specific first cost, acquires a specific instance type and a specific second cost that are equal to or less than the remaining budget and have the largest second cost, updates the remaining budget based on the second cost, and outputs specific instance information including the specific instance type, the specific database configuration, and cost information consisting of the specific first cost, the specific second cost, and the remaining budget. A management system characterized by:

3. The management system according to claim 1, The management server a DB parameter calculation process for searching the resource information table for other resource information similar to the resource information, and setting DB parameters for the resource information based on the search results; A management system characterized by executing the above.

4. The management system according to claim 1, The management server a second acquisition process for acquiring a state of the resource information and a required performance for the resource information; a resource update process for updating the resource information based on the state of the resource information and the required performance acquired by the second acquisition process; A management system characterized by executing the above.

5. A management method executed by a management system having a management server and a storage, comprising: the management server has a resource information table that stores, for each construction condition that is a combination of the cost of using the management system and the data size of a database to be constructed in the storage, instance information that defines an instance to be implemented in the management system and a database configuration that defines the number of blocks and block size of blocks that constitute the database; The management server a first acquisition process for acquiring a construction condition that is a combination of cost and data size; a resource calculation process for acquiring, from the resource information table, instance information of construction conditions similar to the construction conditions acquired by the first acquisition process and resource information which is a database configuration; a resource addition process for mounting the resource information acquired by the resource calculation process in the storage; A management method characterized by executing the following.

6. A management program executed by a management system having a management server and a storage, the management server has a resource information table that stores, for each construction condition that is a combination of the cost of using the management system and the data size of a database to be constructed in the storage, instance information that defines an instance to be implemented in the management system and a database configuration that defines the number of blocks and block size of blocks that constitute the database; The management server, a first acquisition process for acquiring a construction condition that is a combination of cost and data size; a resource calculation process for acquiring, from the resource information table, instance information of construction conditions similar to the construction conditions acquired by the first acquisition process and resource information which is a database configuration; a resource addition process for mounting the resource information acquired by the resource calculation process in the storage; A management program characterized by causing the program to execute the above.

Images