Resource management program, management device, and resource management method
The resource management program optimizes resource allocation in composable infrastructure systems by scoring resources based on usage history and frequency, addressing allocation inefficiencies and improving utilization efficiency.
Patent Information
- Authority / Receiving Office
- JP · JP
- Patent Type
- Patents
- Current Assignee / Owner
- エフサステクノロジーズ株式会社
- Filing Date
- 2022-12-19
- Publication Date
- 2026-07-29
AI Technical Summary
In composable infrastructure systems, hardware resource allocation for jobs may not be performed properly, leading to resource depletion and preventing new jobs from being executed, especially when high-performance resource requests cannot be fulfilled using only the remaining resources.
A resource management program calculates scores for each resource type based on time-series unused numbers and usage frequency, allocating resources in ascending order of these scores to improve utilization efficiency.
This approach enhances the utilization efficiency in virtualization systems by optimizing resource allocation, even during peak seasons, by selecting lower-performance resources when necessary to accommodate more jobs.
Smart Images
Figure 0007896489000001 
Figure 0007896489000002 
Figure 0007896489000003
Abstract
Description
Technical Field
[0001] The present invention relates to a resource management program, a management device, and a resource management method.
Background Art
[0002] In a composable infrastructure system (or, in other words, a virtualization system), Central Processing Unit (CPU) resources and storage resources are separated and then logically pooled.
[0003] A composable infrastructure system is a solution that can freely extract the optimal resources from a resource pool for various workloads and configure and provide them to a machine.
[0004] In particular, in a large-scale system, there may be resources with various specifications in the resource pool.
[0005] FIG. 1 is a block diagram illustrating a resource extraction process in a composable infrastructure system 600 as a conventional example.
[0006] As indicated by reference sign A1, user 7 specifies "BOOT (no resource conditions)" as the target image and "CPU (unspecified) × 1", "GPU (unspecified) × 1", "SSD × 1" as the configured resources in YAML601 (request order form).
[0007] As indicated by reference sign A2, YAML601 is input into management device 6 as a user request (or, in other words, a job).
[0008] As indicated by reference sign A3, management device 6 selects the resources to be passed to the user from resource pool 602.
[0009] In the example shown in Figure 1, resource pool 602 includes four low-performance CPU nodes, two high-performance CPU nodes, three low-performance Graphics Processing Units (GPUs), three high-performance GPUs, and six Solid State Drives (SSDs). One low-performance CPU node, one low-performance GPU, one high-performance GPU, and one SSD are currently in use.
[0010] As shown in symbol A4, the management device 6 allocates the requested resources from the resource pool 602 and presents the created machine 603. In addition to the various drivers and image files that were previously registered, the created machine 603 has one low-performance CPU, one low-performance GPU, and one SSD that were allocated from the resource pool 602 registered. [Prior art documents] [Patent Documents]
[0011] [Patent Document 1] Japanese Patent Publication No. 2021-193504 [Patent Document 2] Japanese Patent Publication No. 2017-191485 [Patent Document 3] Japanese Patent Publication No. 2019-071026 [Overview of the project] [Problems that the invention aims to solve]
[0012] However, in composable infrastructure systems, hardware resource allocation for jobs may not be performed properly, potentially leading to resource depletion and preventing new jobs from being executed. For example, if a high-performance resource request is made, it may not be possible to deploy it using only the remaining resources.
[0013] One aspect of this is the aim to improve utilization efficiency in virtualization systems. [Means for solving the problem]
[0014] On one side, the resource management program calculates, for a computer that manages a virtualization system, a first score according to the time-series unused number for each resource type in the virtualization system from the usage history of the virtualization system by the user, calculates a second score according to the usage frequency and compatibility with other resources for each resource, and causes the computer to execute a process of allocating each resource to the user in ascending order of the total value of the first score and the second score.
Advantages of the Invention
[0015] On one side, the utilization efficiency in the virtualization system can be improved.
Brief Description of the Drawings
[0016] [Figure 1] It is a block diagram illustrating the resource offloading process in a composable infrastructure system as a conventional example. [Figure 2] It is a block diagram illustrating the resource offloading process in a composable infrastructure system as an embodiment. [Figure 3] It is a block diagram schematically showing an example of the software configuration of a management device as an embodiment. [Figure 4] It is a flowchart explaining the write process of the resource pool registration and deployment status Database (DB) in an embodiment. [Figure 5] It is a flowchart explaining the update process of the resource usage history DB in an embodiment. [Figure 6] It is a flowchart explaining the update process of the resource specification DB in an embodiment. [Figure 7] It is a flowchart explaining the update process of the request combination table DB in an embodiment. [Figure 8] It is a flowchart explaining the update process of the resource scoring in an embodiment. [Figure 9]It is a flowchart for explaining the machine deployment process in an embodiment. [Figure 10] It is a table exemplifying the resource pool registration and deployment status DB in an embodiment. [Figure 11] It is a table exemplifying the resource usage history DB in an embodiment. [Figure 12] It is a table exemplifying the resource specification DB in an embodiment. [Figure 13] It is a diagram for explaining the periodic utilization estimation process of resources in an embodiment. [Figure 14] It is a diagram for explaining the remaining quantity estimation process of resources in an embodiment. [Figure 15] It is a diagram for explaining the confirmation process of the combination count between the BOOT image and resources in an embodiment. [Figure 16] It is a table showing the first example of the request combination table DB in an embodiment. [Figure 17] It is a table showing the second example of the request combination table DB in an embodiment. [Figure 18] It is a table exemplifying the scores of each resource in an embodiment. [Figure 19] It is a diagram for explaining the generation process of the resource scoring DB in an embodiment. [Figure 20] It is a block diagram exemplifying the resource offloading process when the resource utilization rates of the current and future systems in the composable infrastructure system as an embodiment are lower than the set upper threshold value. [Figure 21] It is a block diagram exemplifying the resource offloading process when the resource utilization rates of the current and future systems in the composable infrastructure system as an embodiment are higher than the set upper threshold value. [Figure 22] It is a block diagram schematically showing an example of the hardware configuration of the management device in an embodiment. [Figure 23] It is a diagram for explaining the effects in an embodiment. [Modes for carrying out the invention]
[0017] [A] Embodiment An embodiment will be described below with reference to the drawings. However, the embodiment shown below is merely illustrative, and there is no intention to exclude various modifications or applications of techniques not explicitly shown in the embodiment. In other words, this embodiment can be implemented in various ways without departing from its spirit. Furthermore, each figure is not intended to represent only the components shown in the figure, but may include other functions, etc.
[0018] Figure 2 is a block diagram illustrating the resource allocation process in a composable infrastructure system 100 as an embodiment.
[0019] The composable infrastructure system 100 is an example of a virtualization system and includes a management device 1.
[0020] The management device 1 receives a request from user terminal 2 (hereinafter also referred to as user 2) in the composable infrastructure system 100 and responds with the hardware resources to be used in response to the request.
[0021] Specifically, the management device 1 extracts and responds with hardware resources corresponding to user 2's request based on the usage history of the composable infrastructure system 100. However, during peak seasons for the composable infrastructure system 100, the management device 1 deliberately extracts hardware resources with lower performance than requested in order to accommodate more jobs.
[0022] As shown in symbol B1, user 2 specifies "BOOT_A" as the target image in YAML101 (order form for request), and "SSD_A (direct model number specification)", "GPU performance XX or higher (spec specification)", and "CPU not specified" as configuration resources.
[0023] As shown in symbol B2, YAML101 is passed to the management device 1 as a machine creation request.
[0024] As shown by symbol B3, the management device 1 selects a resource from the resource status based on the resource specification DB142, the user request, and the resource usage history DB141 which shows the usage history from user 2 to date. Details of the resource usage history DB141 will be described later using Figure 11, etc., and details of the resource specification DB142 will be described later using Figure 12, etc.
[0025] Management device 1 will select a low-performance (in other words, an unpopular) CPU in YAML101 because no CPU is specified. Management device 1 will select a GPU with a GPU performance of xx or higher in YAML101, but may select a GPU below the lower limit based on usage history.
[0026] The management device 1 may accept input of information regarding changes in resource utilization status when the resource utilization status in the resource pool 102 changes. The management device 1 may also output various types of information and provide change notifications to the user.
[0027] As shown in symbol B4, the management device 1 selects resources from the resource pool 102 to be passed to the user.
[0028] In the example shown in Figure 2, resource pool 102 includes four low-performance CPU nodes, two high-performance CPU nodes, three low-performance GPUs, three high-performance GPUs, and six SSDs. One low-performance CPU node, one low-performance GPU, one high-performance GPU, and one SSD are currently in use.
[0029] As shown in symbol B5, the management device 1 allocates the requested resources from the resource pool 102 and presents the created machine 103. In addition to the various drivers and image files that were previously registered, the created machine 103 has one low-performance CPU, one low-performance GPU, and one SSD that were allocated from the resource pool 102 registered.
[0030] As shown in symbol B6, the GPU registered with the created machine 103 is a GPU with lower performance than required.
[0031] As shown in reference numeral B7, the management device 1 provides the user 2 with the machine 103 that it created.
[0032] Figure 3 is a schematic block diagram showing an example of the software configuration of the management device 1 as an embodiment.
[0033] The management device 1 functions as a resource pool utilization status acquisition unit 111, a resource usage history acquisition unit 112, a resource deployment status acquisition unit 113, a resource specification input unit 114, a request combination table creation and update unit 115, a usage number estimation model creation unit 116, a resource demand estimation unit 117, an unallocated machine resource estimation unit 118, a resource remaining number point assignment unit 119, a resource combination point assignment unit 120, a point calculation unit for each resource 121, a machine deployment request reception unit 122, a machine deployment decision unit 123, a utilization rate threshold acquisition unit 124, and a machine deployment execution unit 125.
[0034] Furthermore, the management device 1 includes a resource usage history DB141, a resource specification DB142, a resource pool registration and deployment status DB143, a request combination table DB144, and a resource allocation DB145.
[0035] The resource pool usage status acquisition unit 111 periodically acquires the resource usage status of each resource. When there is a difference (in other words, an update) in the resource usage status of each resource, the resource pool usage status acquisition unit 111 registers the current usage status in the resource pool registration and deployment status DB 143.
[0036] When a user requests the use of a resource, the resource usage history acquisition unit 112 registers the user information, resource request information, and request date and time in the resource usage history DB 141.
[0037] The resource deployment status acquisition unit 113 retrieves resource usage results from the resource pool registration and deployment status DB 143 and registers them in the resource usage history DB 141 as deployment results for the request.
[0038] The system administrator (not shown) registers the resource specifications (in other words, specification values) of a new type of resource in the resource specification DB 142 using the resource specification input unit 114 whenever a new type of resource is added to the resource pool 102.
[0039] The request combination table creation and update unit 115 periodically acquires the resource specification DB 142 and the resource usage history DB 141.
[0040] When a new resource combination is specified by a user in the resource usage history DB141, the request combination table creation and update unit 115 creates the request combination table DB144 from the resource usage history DB141. The request combination table creation and update unit 115 then counts the number of request combinations from the resource specification DB142 and the resource usage history DB141 and writes the count to the table in the request combination table DB144.
[0041] If there are incompatible resource combinations in the resource specification DB142, the request combination table creation and update unit 115 extracts the incompatible resources from the resource specification DB142 and writes "×" to the table in the request combination table DB144.
[0042] The unit 116 for creating the usage count estimation model obtains time-series data of resource usage history from the resource usage history DB 141. The unit 116 for creating the usage count estimation model creates a usage count estimation model for each resource type.
[0043] The resource demand estimation unit 117 uses a usage estimation model to obtain an estimated value of the number of units in use at any given time.
[0044] The unallocated machine resource estimation unit 118 uses a machine usage estimation model to obtain an estimated value of the unallocated machine resources (in other words, the remaining number) for each resource type at any given time.
[0045] The resource remaining count scoring unit 119 evaluates the remaining count for each resource type based on the estimated value of unallocated machine resources, and assigns higher scores the fewer resources remaining. In other words, the resource remaining count scoring unit 119 is an example of a scoring unit, and calculates a first score based on the time-series unused count for each resource type in the virtualization system 100 from the resource usage history DB 141 of the virtualization system 100 by user 2.
[0046] Based on the request combination table DB144, the resource combination scoring unit 120 assigns points to each resource. For example, in the tables of the request combination table DB144, "1 item" = 2 points, "×" = -1 point, etc. In other words, the resource combination scoring unit 120 is an example of a scoring unit, and it calculates a second score for each resource according to its frequency of use and compatibility with other resources.
[0047] The resource-specific point calculation unit 121 sums up the points allocated to each resource obtained by the resource combination point allocation unit 120 and the resource remaining number point allocation unit 119, and stores the summed points in the resource allocation DB 145.
[0048] The machine deployment request receiving unit 122 receives machine deployment requests from user 2.
[0049] The machine deployment decision unit 123 determines machine deployment based on the estimated resource demand and machine deployment requests.
[0050] The machine deployment decision unit 123 refers to the resource usage history DB 141 and retrieves the past deployment history of the requesting user.
[0051] The machine deployment decision unit 123 obtains the current system's resource utilization rate from the resource pool registration and deployment status DB 143, and obtains the future system's resource utilization rate from the resource demand estimation unit 117.
[0052] The machine deployment decision unit 123 obtains the upper limit threshold from the utilization threshold acquisition unit 124.
[0053] If the current and future system resource utilization is higher than the upper threshold, and the shortage can be resolved by changing to a resource from the requesting user's past deployment history, the machine deployment decision unit 123 changes the selected resource to a resource from the requesting user's past deployment history and returns a notification to the system administrator that the change has been made. Also, if the remaining resources are insufficient to meet the current machine deployment request, and the shortage can be resolved by changing to a resource from the requesting user's past deployment history, the machine deployment decision unit 123 changes the selected resource to a resource from the requesting user's past deployment history and returns a notification to the system administrator that the change has been made.
[0054] In other words, the machine deployment decision unit 123 is an example of a decision unit, and it assigns each resource to user 2 in order of the lowest sum of the first score and the second score.
[0055] The machine deployment execution unit 125 receives the deployment request information determined by the machine deployment decision unit 123 and actually executes the machine deployment.
[0056] The resource pool registration and deployment status DB143 writing process in this embodiment will be explained using the flowchart (steps S1-S3) shown in Figure 4.
[0057] The resource pool usage status acquisition unit 111 periodically acquires the resource usage status of each resource (step S1).
[0058] The resource pool usage acquisition unit 111 determines whether there is a difference (in other words, an update) in the resource usage status of each resource (step S2).
[0059] If there are no differences (in other words, updates) in the resource usage status of each resource (see NO route in step S2), the resource pool registration and write process to the deployment status DB143 will terminate, and the process will be restarted periodically.
[0060] If there is a difference (in other words, an update) in the resource usage status of each resource (see the YES route in step S2), the resource pool usage status acquisition unit 111 registers the current usage status in the resource pool registration and deployment status DB 143 (step S3). Then, the write process to the resource pool registration and deployment status DB 143 is completed, and the process is restarted periodically.
[0061] Next, the process of updating the resource usage history DB141 in the embodiment will be explained using the flowchart (steps S11 to S12) shown in Figure 5.
[0062] When a user requests the use of a resource, the resource usage history acquisition unit 112 registers the user information, resource request information, and request date and time in the resource usage history DB 141 (step S11).
[0063] The resource deployment status acquisition unit 113 retrieves resource usage results from the resource pool registration and deployment status DB 143 and registers them in the resource usage history DB 141 as deployment results for the request (step S12). Then, the update process for the resource usage history DB 141 is completed, and the process is restarted each time a resource request is made.
[0064] Next, the update process for the resource specification DB142 in the embodiment will be explained using the flowchart (step S21) shown in Figure 6.
[0065] The system administrator (not shown) registers the resource specifications (in other words, specification values) of a new type of resource in the resource specification DB 142 using the resource specification input unit 114 whenever a new type of resource is added to the resource pool 102 (step S21). The update process for the resource specification DB 142 then finishes, and the process restarts each time a new type of resource is added.
[0066] Next, the update process of the request combination table DB144 in the embodiment will be explained using the flowchart (steps S31 to S36) shown in Figure 7.
[0067] The request combination table creation and update unit 115 periodically acquires the resource specification DB 142 and the resource usage history DB 141 (step S31).
[0068] The request combination table creation and update unit 115 determines whether there is a new resource combination specified by a user in the resource usage history DB 141.
[0069] If there are no new resource combinations specified by the user in the resource usage history DB141 (see NO route in step S32), the process proceeds to step S34.
[0070] On the other hand, if there are new resource combinations specified by the user in the resource usage history DB141 (see the YES route in step S32), the request combination table creation and update unit 115 creates the request combination table DB144 from the resource usage history DB141. Then, the request combination table creation and update unit 115 counts the number of request combinations from the resource specification DB142 and the resource usage history DB141 and writes the number to the table in the request combination table DB144 (step S33).
[0071] The resource specification input unit 114 creates resource specifications in the resource specification DB 142 (step S34).
[0072] The request combination table creation and update unit 115 determines whether there are incompatible resource combinations in the resource specification DB 142 (step S35).
[0073] If no incompatible resource combinations exist in resource specification DB142 (see NO route in step S35), the update process for request combination table DB144 is terminated, and the process is restarted periodically.
[0074] On the other hand, if there are incompatible resource combinations in the resource specification DB142 (see the YES route in step S35), the request combination table creation and update unit 115 extracts the incompatible resources from the resource specification DB142 and writes "×" to the table in the request combination table DB144 (step S36). Then the update process for the request combination table DB144 is completed, and the process is restarted periodically.
[0075] Next, the resource allocation update process in the embodiment will be explained using the flowchart (steps S41 to S47) shown in Figure 8.
[0076] The unit 116 that creates the usage number estimation model acquires time-series data of resource usage history from the resource usage history DB 141 (step S41).
[0077] The unit 116 that creates the usage estimation model creates a usage estimation model for each resource type (step S42).
[0078] The resource demand estimation unit 117 uses a usage estimation model to obtain an estimated value of the number of units in use at any given time (step S43).
[0079] The unallocated machine resource estimation unit 118 uses a machine usage estimation model to obtain an estimated value of the unallocated machine resources (in other words, the remaining number) for each resource type at any given time (step S44).
[0080] The resource remaining count scoring unit 119 evaluates the remaining count for each resource type based on the estimated value of unallocated machine resources, and assigns higher scores the fewer resources remaining (step S45).
[0081] The resource combination point allocation unit 120 assigns points to each resource based on the request combination table DB 144 (step S46). For example, in the tables of the request combination table DB 144, "1 item" = 2 points, "×" = -1 point, etc.
[0082] The resource-specific point calculation unit 121 sums the points allocated to each resource obtained by the resource combination point allocation unit 120 and the resource remaining point allocation unit 119, and stores the summed points in the resource allocation DB 145 (step S47). Then the resource allocation update process is completed.
[0083] Next, the machine deployment process in the embodiment will be explained using the flowchart (steps S51 to S63) shown in Figure 9.
[0084] The machine deployment request receiving unit 122 receives a machine deployment request from user 2. Furthermore, the machine deployment decision unit 123 determines the machine deployment based on the estimated resource demand and the machine deployment request (step S51).
[0085] The machine deployment decision unit 123 refers to the resource usage history DB 141 and obtains the past deployment history of the requesting user (step S52).
[0086] The machine deployment decision unit 123 obtains the current system's resource utilization rate from the resource pool registration and deployment status DB 143, and obtains the future system's resource utilization rate from the resource demand estimation unit 117 (step S53).
[0087] The machine deployment decision unit 123 obtains the upper limit threshold from the utilization threshold acquisition unit 124 (step S54).
[0088] The machine deployment decision unit 123 determines whether the current and future resource utilization rates of the system are higher than the upper threshold (step S55).
[0089] If the current and future resource utilization of the system is not higher than the upper threshold (see NO route in step S55), the machine deployment decision unit 123 determines whether the remaining resources are sufficient to meet the current machine deployment request (step S56).
[0090] If the current machine deployment request can be met with the remaining resources (see the YES route in step S56), the machine deployment determination unit 123 retrieves the allocation points for each resource obtained from the resource allocation DB 145 and sorts the results in ascending order (step S57).
[0091] The machine deployment decision unit 123 determines whether there are multiple types of resources corresponding to the machine deployment request (step S58).
[0092] If there are multiple types of resources that correspond to the machine deployment request (see the YES route in step S58), the process proceeds to step S60.
[0093] On the other hand, if there are no multiple types of resources that match the machine deployment request (see NO route in step S58), the machine deployment determination unit 123 refers to the scoring list and selects the resource with the lowest score (step S59).
[0094] The machine deployment request information determined by the machine deployment decision unit 123 is passed to the machine deployment execution unit 125, and the machine deployment is actually executed (step S60). Then, the machine deployment process in this embodiment is completed.
[0095] If, in step S55, the current and future system resource utilization rates are higher than the upper threshold (see the YES route in step S55), or if, in step S56, the current machine deployment request cannot be met with the remaining resources (see the NO route in step S56), the process proceeds to step S61. The machine deployment decision unit 123 determines whether the shortage can be resolved by changing to resources that were in the requesting user's past deployment history (step S61).
[0096] If the shortage can be resolved by changing to a resource that was in the requesting user's past deployment history (see the YES route in step S61), the machine deployment decision unit 123 changes the selected resource to a resource that was in the requesting user's past deployment history and returns the change to the system administrator (step S62). Then the process proceeds to step S60.
[0097] If the shortage cannot be resolved by changing to a resource that was in the requesting user's past deployment history (see NO route in step S61), the machine deployment decision unit 123 returns a machine deployment error to the system administrator because the remaining resources cannot satisfy the machine deployment request (step S63). Then, the machine deployment process in this embodiment ends.
[0098] Figure 10 is a table illustrating the resource pool registration and deployment status DB143 in the embodiment.
[0099] The Resource Pool Registration and Deployment Status DB143 may register the Resource ID, Resource Name, Resource Type, Resource Model Number, and Machine Deployment Status in association with each other.
[0100] The Resource Pool Registration and Deployment Status DB143 records the name, type, specifications, etc., of each individual resource. If resources of the same type and model number exist (in the example shown in Figure 10, resource IDs = 1, 4, 5), the record is recorded for each existing resource. When a new resource is connected, the number of records is increased.
[0101] Figure 11 is a table illustrating the resource usage history DB141 in the embodiment.
[0102] Resource usage history DB141 may register usage history ID, machine name, deployment date and time, decommissioning date and time, resources used, images used, driver versions used, and user request information, all associated with each other.
[0103] The resource usage history DB141 contains a list of resources that were specified by the user during machine deployment.
[0104] If User 2 specifies "above a certain performance level," the resources to be used are marked (as shown in the example in Figure 11, marked with an asterisk (*)) and described in the request information from User 2.
[0105] If resources of the same type and model number are used, they will be listed in the "Resources Used" column for each existing resource.
[0106] Figure 12 is a table illustrating the resource specification DB142 in the embodiment.
[0107] Resource Spec DB142 stores the resource ID, resource name, resource type, resource model number, and resource specifications in an associated format.
[0108] Resource Spec DB142 contains information about resources, such as their name, type, and specifications, on a per-resource-number basis. This specification information can be retrieved using the resource-numbers in Resource Pool Registration and Deployment Status DB143 and linked to Resource Spec DB142. When a new resource is installed, the number of records in Resource Spec DB142 is increased.
[0109] Figure 13 illustrates the resource periodic utilization estimation process in the embodiment.
[0110] As shown in symbol C1, time-series data of the number of units used for each resource (actual value) is obtained from the resource usage history DB141.
[0111] As shown in code C2, the estimated model Y CPU_B =f(X CPU_B ) and Y CPU_A =f(X CPU_A Create ).
[0112] As shown in code C3, the estimation model calculates an estimated number of units in use.
[0113] Figure 14 illustrates the resource remaining number estimation process in the embodiment.
[0114] As indicated by symbol D1, the resource usage estimation model Y shown in Figure 13 CPU_B =f(X CPU_B ), Y CPU_A =f(X CPU_A ) is created.
[0115] As shown in symbol D2, a time-series estimate of unallocated resources (in other words, remaining resources) for each resource type is calculated using an estimation model for the number of machines in use. In the example shown in Figure 14, it is estimated that at time 10:00, there is 1 remaining CPU_B and 10 remaining CPU_A.
[0116] As shown in symbol D3, the number of remaining resources is evaluated for each resource type, and the fewer resources remaining, the higher the score and rank. In the example shown in Figure 14, at time 10:00, CPU_B, with 1 remaining unit, is awarded 1st place (10 points), and CPU_A, with 10 remaining units, is awarded 2nd place (5 points). In addition to ranking by the number of remaining units, rankings can also be made, for example, by the ratio of remaining units to the total amount.
[0117] Then, as shown in symbol D4, a scoring table is obtained by estimating the remaining resources. In the table shown in Figure 14, the score for high-performance CPU (CPU_B) is 10, and the score for medium-performance CPU is 5.
[0118] Figure 15 illustrates the process for verifying the number of combinations between BOOT images and resources in the embodiment.
[0119] The number of requested resource combinations can be confirmed from the user's past YAML101 request history.
[0120] In the request history of YAML101 shown in code E1, "BOOT_X (no resource conditions)" is specified as the target image, and "CPU (unspecified) x1", "GPU (unspecified) x1", and "SSD x1" are specified as the configuration resources. In the example shown in code E1, no score is assigned because no performance is specified.
[0121] In the request history of YAML101 shown in code E2, the target image is specified as "BOOT_X (requires high-performance CPU and high-performance GPU)", and the configuration resources are specified as "CPU (high-performance) x 1", "GPU (high-performance) x 1", and "SSD x 1". In the example shown in code E2, the "CPU (high-performance) and GPU (high-performance) combination" will have +1 item, the "CPU (high-performance) and BOOT_A combination" will have +1 item, and the "GPU (high-performance) and BOOT_A combination" will have +1 item.
[0122] In the YAML101 request history shown in code E3, the target image is specified as "BOOT_X (requires high-performance GPU)", and the configuration resources are specified as "CPU (not specified) x 1", "GPU (high-performance) x 2", and "SSD x 1". In the example shown in code E3, the "GPU (high-performance) · GPU (high-performance) combination" counts as +1, and the "GPU (high-performance) · BOOT_B combination" counts as +2. If there are multiple identical resources, the count is duplicated. In the case shown in code E3, there are two GPUs (high-performance), so the combination with BOOT_B is counted as 2.
[0123] In the request history of YAML101 shown in code E4, the target image is specified as "BOOT_X (requires a medium-performance or higher GPU)", and the configuration resources are specified as "CPU (not specified) x 1", "GPU (high-performance) x 1", and "SSD x 1". In the example shown in code E4, the "GPU (medium-performance) and BOOT_C combination" will receive +1 point, and the "GPU (high-performance) and BOOT_C combination" will receive +1 point. If the required performance is "above a certain performance", points will be added for combinations that meet or exceed that performance. In the case shown in code E4, points will be added for GPU (medium-performance) and GPU (high-performance).
[0124] Figure 16 is a table showing a first example of the requirements combination table DB144 in the embodiment.
[0125] In the list of requested combinations shown in Figure 16, the number of combinations counted in Figure 15 is added together and registered.
[0126] For example, "1" is registered for the CPU (high performance) and GPU (high performance) combination, and "2" is registered for the GPU (high performance) and BOOT_B combination.
[0127] Figure 17 is a table showing a second example of the requirements combination table DB144 in the embodiment.
[0128] In the list of requirement combinations shown in Figure 17, in addition to the number of combinations registered in Figure 16, an "×" mark is registered for requirement combinations that cannot be combined. Requirement combinations that cannot be combined may be incompatible combinations identified by obtaining resource specifications from the manufacturer's website or catalog.
[0129] In the example shown in Figure 17, the combination of CPU (high performance) and GPU (medium performance) is registered as invalid. Also, since only one img (Image) file is used, all combinations of img files are registered as invalid.
[0130] Figure 18 is a table illustrating the points held by each resource in the embodiment.
[0131] The points for each resource shown in Figure 18 may be calculated by adding points for the number of items in the list of request combinations shown in Figure 17, and subtracting points for items marked with an "×".
[0132] In the example shown in Figure 18, the scores registered are calculated as follows: "1 item" = +2 points, "×" = -1 point. For example, in the CPU (high performance) table shown in Figure 17, there are two "1 item"s and one "×", so the score registered is (+2)×2 + (-1)×1 = 3.
[0133] Figure 19 illustrates the process of generating the resource allocation DB145 in the embodiment.
[0134] The resource allocation DB145, shown as code F3 in Figure 19, is generated by summing the scores from the allocation table obtained from the estimated remaining number of resources shown in Figure 14 (see code F1) and the allocation table obtained from the BOOT image and the number of combinations between resources shown in Figure 18 (see code F2), and finally determining the score for each resource.
[0135] For example, in the resource allocation DB145 indicated by symbol F3, the CPU (high performance) value is registered as 13, which is the sum of the CPU (high performance) value of 10 in the allocation table indicated by symbol F1 and the CPU (high performance) value of 3 in the allocation table indicated by symbol F2.
[0136] Figure 20 is a block diagram illustrating the resource allocation process in a composable infrastructure system 100 as an embodiment, when the current and future resource utilization rates of the system are lower than a set upper threshold.
[0137] If the current and future resource utilization of the system is lower than the set upper threshold, the management device 1 will select resources from those with lower scores (in other words, resources with lower usage frequency) when creating a machine, within the range of resource specifications and specification constraints specified by user 2.
[0138] In the example shown in Figure 20, as indicated by symbol G1, when the machine is created, the CPU with the lowest score of "1" in the resource allocation DB145 (low performance) is selected.
[0139] However, as indicated by code G2, if the utilization remains low, the GPU (high performance) will be provided as specified by user 2.
[0140] Figure 21 is a block diagram illustrating the resource allocation process in a composable infrastructure system 100 as an embodiment, when the current and future resource utilization rates of the system exceed a set upper threshold.
[0141] Management device 1, when the current and future system resource utilization is higher than the set upper threshold (in other words, during busy periods with high utilization), deliberately extracts hardware resources different from those requested, thereby enabling it to accept more jobs.
[0142] In the example shown in Figure 21, similar to the example shown in Figure 20, as indicated by symbol H1, the CPU with the lowest score of "1" in the resource allocation DB145 (low performance) is selected when the machine is created.
[0143] As indicated by symbol H2, if the utilization rate becomes low, a GPU different from the one specified by the user will be provided. In the example shown in Figure 21, a GPU that has been used by this user 2 in the past and has a low score (in Figure 21, the GPU (low performance)) will be provided.
[0144] The machine deployment decision unit 123 retrieves the requesting user's past request history from the resource usage history DB 141 shown in Figure 11, checks the resources in the requesting user's past deployment history, makes changes, and returns the changes to the system administrator.
[0145] For example, the user "Mr. A" is picked from the resource usage history DB141 shown in Figure 11, and the resources that were most frequently requested are selected. If the utilization rate is high and resource changes are possible, it is replaced with a resource that has a lower score in past usage history.
[0146] Figure 22 is a schematic block diagram showing an example of the hardware configuration of the management device 1 in the embodiment.
[0147] As shown in Figure 22, the management device 1 comprises a CPU (Central Processing Unit) 11, a memory unit 12, a display control unit 13, a storage device 14, an input interface (IF) 15, an external recording medium processing unit 16, and a communication IF 17.
[0148] The memory unit 12 is an example of a storage unit, and exemplifies it as Read Only Memory (ROM) and Random Access Memory (RAM). The ROM of the memory unit 12 may contain programs such as a Basic Input / Output System (BIOS). The software programs in the memory unit 12 may be read and executed by the CPU 11 as appropriate. The RAM of the memory unit 12 may be used as temporary storage memory or working memory.
[0149] The display control unit 13 is connected to the display device 131 and controls the display device 131. The display device 131 is a liquid crystal display, an organic light-emitting diode (OLED) display, a cathode ray tube (CRT), an electronic paper display, etc., and displays various information to the operator, etc. The display device 131 may be combined with an input device, for example, a touch panel. The display device 131 displays various information to the user of the management device 1.
[0150] The storage device 14 is a storage device with high I / O performance, and may include, for example, Dynamic Random Access Memory (DRAM), SSD (Solid State Drive), Storage Class Memory (SCM), or HDD (Hard Disk Drive).
[0151] Input IF15 is connected to an input device such as a mouse 151 or a keyboard 152, and may control such an input device. The mouse 151 and keyboard 152 are examples of input devices, and the operator performs various input operations through these input devices.
[0152] The external recording medium processing unit 16 is configured to accommodate a recording medium 160. When the recording medium 160 is mounted, the external recording medium processing unit 16 is configured to read the information recorded on the recording medium 160. In this example, the recording medium 160 is portable. For example, the recording medium 160 may be a flexible disk, optical disk, magnetic disk, magneto-optical disk, or semiconductor memory.
[0153] Communication IF17 is an interface that enables communication with external devices.
[0154] The CPU 11 is an example of a processor, and is a processing unit that performs various control and calculations. The CPU 11 realizes various functions by executing the Operating System (OS) and programs loaded into the memory unit 12. The CPU 11 may be a multiprocessor containing multiple CPUs, a multicore processor having multiple CPU cores, or a configuration having multiple multicore processors.
[0155] The device for controlling the overall operation of the management device 1 is not limited to the CPU 11, but may be, for example, one of the following: MPU, DSP, ASIC, PLD, or FPGA. Furthermore, the device for controlling the overall operation of the management device 1 may be a combination of two or more types of CPU, MPU, DSP, ASIC, PLD, and FPGA. Note that MPU is an abbreviation for Micro Processing Unit, DSP is an abbreviation for Digital Signal Processor, and ASIC is an abbreviation for Application Specific Integrated Circuit. Also, PLD is an abbreviation for Programmable Logic Device, and FPGA is an abbreviation for Field Programmable Gate Array.
[0156] [B] effect According to the resource management program, management device 1, and resource management method in the above-described embodiment, the following effects can be achieved, for example.
[0157] Figure 23 is a diagram illustrating the effects in the embodiment.
[0158] In this embodiment, hardware resources can be appropriately allocated to jobs. Therefore, as shown in Figure 23, even if in the conventional example the remaining resources in the resource pool 602 consist of 2 low-performance CPU nodes, 1 low-performance GPU, and 2 SSDs, in this embodiment the remaining resources in the resource pool can consist of 2 high-performance CPU nodes, 1 high-performance GPU, and 2 SSDs.
[0159] In this case, if a new user request is issued for a target image "BOOT (no resource conditions)" without specifying resource requirements, and configuration resources "GPU (unspecified) x 1", "CPU (unspecified) x 1", and "SSD x 1", then deployment will be possible using only the remaining resources in both the conventional example and the embodiment.
[0160] On the other hand, if a new user request is issued for a target image "BOOT (requires high-performance CPU)" with specified resource requirements, and the configuration resources "GPU (requires high-performance) x 1", "CPU (not specified) x 1", and "SSD x 1", in the conventional example, deployment would not be possible with only the remaining resources. However, in this embodiment, deployment is possible with only the remaining resources.
[0161] The resource remaining points allocation unit 119 calculates a first score based on the time-series unused count of each resource type in the virtualization system 100 from the resource usage history DB 141 of the virtualization system 100 by user 2. The resource combination points allocation unit 120 calculates a second score for each resource based on its usage frequency and compatibility with other resources. The machine deployment decision unit 123 assigns each resource to user 2 in descending order of the sum of the first and second scores.
[0162] This improves the utilization efficiency of the virtualization system 100. Specifically, hardware resource allocation to jobs becomes more appropriate, allowing new jobs with resource restrictions to run without depleting hardware resources.
[0163] [C] Others The disclosed technology is not limited to the embodiments described above and can be implemented in various modified forms without departing from the spirit of this embodiment. Each configuration and process of this embodiment can be selected or combined as needed.
[0164] [D] Note The following additional information is disclosed regarding the embodiments described above.
[0165] (Note 1) On the computer that manages the virtualization system, From the user's usage history of the virtualization system, a first score is calculated according to the number of unused resources of each resource type in the virtualization system over time. For each resource, a second score is calculated based on its frequency of use and compatibility with other resources. The resources are assigned to the users in descending order of the sum of the first score and the second score. A resource management program characterized by its ability to execute processes.
[0166] (Note 2) When the resource utilization rate in the virtualization system is higher than the threshold, the allocation is performed. The resource management program according to Appendix 1, characterized in that it causes the computer to perform the processing.
[0167] (Note 3) In the process of calculating the second score, the second score for the relevant resource is added according to the frequency of use. A resource management program according to Appendix 1 or 2, characterized by causing the computer to perform the processing.
[0168] (Note 4) In the process of calculating the second score, the second score for the resource with low compatibility is deducted. A resource management program according to Appendix 1 or 2, characterized by causing the computer to perform the processing.
[0169] (Note 5) The computer that manages the virtualization system, From the user's usage history of the virtualization system, a first score is calculated according to the number of unused resources of each resource type in the virtualization system over time. For each resource, a second score is calculated based on its frequency of use and compatibility with other resources. The resources are assigned to the users in descending order of the sum of the first score and the second score. A resource management method characterized by executing a process.
[0170] (Note 6) When the resource utilization rate in the virtualization system is higher than the threshold, the allocation is performed. The resource management method according to Appendix 5, characterized in that the computer performs the processing.
[0171] (Note 7) In the process of calculating the second score, the second score for the relevant resource is added according to the frequency of use. The resource management method according to Appendix 5 or 6, characterized in that the computer performs the processing.
[0172] (Note 8) In the process of calculating the second score, the second score for the resource with low compatibility is deducted. The resource management method according to Appendix 5 or 6, characterized in that the computer performs the processing.
[0173] (Note 9) In a management device for managing a virtualization system, A scoring unit calculates a first score based on the user's usage history of the virtualization system, corresponding to the number of unused resources of each resource type in the virtualization system over time, and calculates a second score for each resource based on its usage frequency and compatibility with other resources. A determination unit that assigns each resource to the user in order of the lowest sum of the first score and the second score, A control device characterized by being equipped with the following features.
[0174] (Note 10) The determination unit performs the allocation when the resource utilization rate in the virtualization system is higher than a threshold. The control device described in Appendix 9, characterized by the features described herein.
[0175] (Note 11) The scoring unit, in the process of calculating the second score, adds the second score for the corresponding resource according to the frequency of use. The control device according to Appendix 9 or 10, characterized in that it is a control device.
[0176] (Note 12) The scoring unit, in the process of calculating the second score, deducts points from the second score for the resource with low compatibility. The control device according to Appendix 9 or 10, characterized in that it is a control device. [Explanation of Symbols]
[0177] 1,6 :Management device 2,7: User 11: CPU 12: Memory section 13: Display Control Unit 14:Storage device 15: Input IF 16: External recording medium processing unit 17: Communication Interface 100,600: Composable Infrastructure System 101,601:YAML 102,602: Resource pool 103,603: Machine 111: Resource pool usage status acquisition unit 112: Resource Usage History Acquisition Unit 113: Resource Deployment Status Acquisition Unit 114: Resource Specification Input Section 115: Request Combination Table Creation and Update Unit 116: Unit Usage Estimation Model Creation Section 117: Resource Demand Estimation Unit 118: Machine Unallocated Resource Estimation Unit 119: Resource remaining amount point allocation unit 120: Resource Combination Point Assignment Section 121: Resource-specific point allocation calculation unit 122: Machine Deployment Request Reception Department 123: Machine Deployment Decision Department 124: Usage rate threshold acquisition unit 125: Machine Deployment Execution Unit 131:Display device 141: Resource Usage History DB 142: Resource Spec DB 143: Deployment Status Database 144: Request combination table DB 145: Resource Allocation DB 151: Mouse 152: Keyboard 160: Recording media
Claims
1. On the computer that manages the virtualization system, From the user's usage history of the virtualization system, a first score is calculated according to the number of unused resources of each resource type in the virtualization system over time. For each resource, a second score is calculated based on its frequency of use and compatibility with other resources. The resources are assigned to the users in descending order of the sum of the first score and the second score. A resource management program characterized by its ability to execute processes.
2. When the resource utilization rate in the virtualization system is higher than the threshold, the allocation is performed. The resource management program according to claim 1, characterized in that it causes the computer to perform the processing.
3. In the process of calculating the second score, the second score for the corresponding resource is added according to the frequency of use. The resource management program according to claim 1 or 2, characterized in that it causes the computer to perform the processing.
4. In the process of calculating the second score, the second score for the resource with low compatibility is deducted. The resource management program according to claim 1 or 2, characterized in that it causes the computer to perform the processing.
5. The computer that manages the virtualization system, From the user's usage history of the virtualization system, a first score is calculated according to the number of unused resources of each resource type in the virtualization system over time. For each resource, a second score is calculated based on its frequency of use and compatibility with other resources. The resources are assigned to the users in descending order of the sum of the first score and the second score. A resource management method characterized by executing a process.
6. In a management device for managing a virtualization system, A scoring unit calculates a first score based on the user's usage history of the virtualization system, corresponding to the number of unused resources of each resource type in the virtualization system over time, and calculates a second score for each resource based on its usage frequency and compatibility with other resources. A determination unit that assigns resources to the users in order of the lowest sum of the first score and the second score, A control device characterized by being equipped with the following features.