Resource management apparatus, resource management method and resource management program

Abstract

To suppress an increase in the power consumption of a processor at a low load while suppressing a decrease in the processing performance of an application(s) at a high load.SOLUTION: A resource management apparatus allocates cores to each process executed by a cores-comprising processor. The apparatus comprises: a process number change unit which changes the deployment number of processes executed by the processor in response to changes in the load amount of the processor: and a core allocation unit which decreases the number of cores to be allocated to each process when the deployment number increases in response to an increase in the load amount, and increases the number of cores to be allocated to each process when the deployment number decreases in response to a decrease in the load amount. In this way, the generation of migration at a high load can be suppressed, and an increase in consumption power at a low load can be suppressed, so that a server or the like can be power-saved without decreasing processing performance, and it can contribute to a decrease in an environmental load.SELECTED DRAWING: Figure 2

Description

Technical Field

[0001] The present invention relates to a resource management device, a resource management method, and a resource management program.

Background Art

[0002] When migrating a monolithic system composed of virtual machines or the like to a microservices-based system, a configuration definition support system is known that allocates the amount of resources required for each microservice with a small number of man-hours (see, for example, Patent Document 1).

[0003] A core allocation device is known that acquires feature information indicating the characteristics of a task from design information defining the task, and easily allocates the task to a core based on the feature information and the core configuration of a multi-core processor (see, for example, Patent Document 2).

[0004] In the autoscaling of virtual machines and containers on virtual machines, a technique is known that reflects the required number of virtual machines calculated from the required number of containers in the scaling of virtual machines to suppress the startup of unnecessary virtual machines (see, for example, Patent Document 3).

Prior Art Documents

Patent Documents

[0005]

Patent Document 1

Patent Document 2

Patent Document 3

Summary of the Invention

Problems to be Solved by the Invention

[0006] For example, Kubernetes, which is one of the container integration management tools, has an auto-scaling function that increases or decreases the number of Pods including containers according to the load of the application. With the auto-scaling function, even when the load of the application changes, appropriate processing performance according to the load can be obtained, and the performance of the application can be maintained.

[0007] For example, when the load of a plurality of cores assigned to a Pod approaches the upper limit and load variation occurs among the plurality of cores, migration for equalizing the load among the cores may be executed. The processing load of the migration tends to be larger as the number of cores assigned to the Pod is larger and the number of cores to be migrated is larger. The larger the processing load of the migration, the relatively lower the processing performance of the application.

[0008] Also, when using a processor including physical cores that perform frequency control according to the load and allocating a minimum number of logical cores to a Pod regardless of the load of the application, there is a possibility that the load of the logical cores allocated to the Pod becomes large even when the processing load is small. When the frequency of the physical cores increases due to the increase in the load of the logical cores, there is a possibility that the power consumption of the processor increases compared to the case of allocating many logical cores to the Pod and maintaining the low frequency of the physical cores.

[0009] In one aspect, an object of the present invention is to suppress a decrease in the processing performance of an application at high load and suppress an increase in the power consumption of a processor at low load.

Means for Solving the Problems

[0010] According to one aspect, a resource management device is a resource management device that allocates cores to processes executed by a processor including a plurality of cores, and includes a process number change unit that changes the number of deployed processes executed by the processor according to a change in the load of the processor, and a core allocation unit that, when the number of deployments increases according to an increase in the load, decreases the number of cores allocated to each of the processes, and when the number of deployments decreases according to a decrease in the load, increases the number of cores allocated to each of the processes.

Advantages of the Invention

[0011] It is possible to suppress a decrease in the processing performance of an application during high load and an increase in the power consumption of a processor during low load.

Brief Description of the Drawings

[0012]

Figure 1

Figure 2

Figure 3

Figure 4

Figure 5

Figure 6

Figure 7

Figure 8

Figure 9

Figure 10

Figure 11

Figure 12

Figure 13

Figure 14

Figure 15

Figure 16

Figure 17

Figure 18

Figure 19

Figure 20

BEST MODE FOR CARRYING OUT THE INVENTION

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

[0014] FIG. 1 shows an example of a resource management apparatus according to an embodiment. For example, a resource management apparatus 10 shown in FIG. 1 is mounted on a system 30 together with a processor 20 which is a multi-core processor having a plurality of cores 21. The resource management apparatus 10 is connected to the processor 20 via a bus 31 such as PCIe (Peripheral Component Interconnect express), for example. Note that the resource management apparatus 10 may be connected to the processor 20 via a network. The resource management apparatus 10 includes a process number changing unit 11 and a core allocation unit 12.

[0015] For example, the processor 20 is mounted on a physical server or the like via a socket (not shown). For example, the processor 20 has eight cores 21 each capable of executing a process which is a constituent unit of an application. The core 21 may be a logical core (virtual core). In this case, two logical cores may be provided for each physical core indicated by a broken line frame. In FIG. 1, when the maximum usage rate (load amount) of each core 21 is 100%, the maximum usage rate (load amount) of the processor 20 is 800%. Note that three or more logical cores may be provided for each physical core. Also in this case, the maximum usage rate of the processor 20 is indicated by the product of the number of mounted logical cores and 100%.

[0016] The resource management apparatus 10 controls to increase or decrease the number of deployed processes according to the usage rate of the processor 20 that executes a process (that is, the load of an application), and allocate a predetermined number of cores 21 to each process according to the number of processes. Thereby, a flexible and highly efficient system 30 can be constructed according to changes in the load of the application.

[0017] In FIG. 1, for the sake of simplicity of explanation, an example in which the resource management device 10 manages one processor 20 is shown. However, the resource management device 10 may manage the resources of a server (information processing device) equipped with a plurality of processors 20, or may manage the resources of a plurality of servers each equipped with a plurality of processors 20. At this time, the plurality of servers may be physically located at separate positions and may be connected to the resource management device 10 via a network. Further, the plurality of servers may be used for a cloud computing service that increases or decreases the number of computing resources for executing a process according to fluctuations in the load.

[0018] The process number changing unit 11 monitors the load amount of the processor 20 that executes a process, and changes the number of processes deployed by the processor according to changes in the load amount. For example, every time the usage rate of the processor 20 increases by a preset specified value, the process number changing unit 11 increases the number of processes by one, and every time the usage rate of the processor 20 decreases by the specified value, the process number changing unit 11 decreases the number of processes by one. For example, the specified value may be 200%, which is the maximum usage rate of two cores 21.

[0019] When the number of processes deployed increases in response to an increase in the load amount of the processor 20, the core allocation unit 12 instructs the processor 20 to set a decrease in the number of cores 21 allocated to each of the processes. When the number of processes deployed decreases in response to a decrease in the load amount of the processor 20, the core allocation unit 12 instructs the processor 20 to set an increase in the number of cores 21 allocated to each of the processes.

[0020] FIG. 2 shows an example of control for allocating cores 21 to processes by the resource management device 10 in FIG. 1. That is, FIG. 2 shows an example of a resource management method of the resource management device 10. The control shown in FIG. 2 may be realized by a resource management program executed by the resource management device 10.

[0021] In FIG. 2, an example is shown of the increase and decrease in the number of processes deployed when the load on the processor 20 switches to a low load state (e.g., 100%), a medium load state (e.g., 400%), and a high load state (e.g., 800%), and the assignment of the cores 21 to each process according to the number of processes that increase and decrease.

[0022] When in the low load state (100%), the core assignment unit 12 assigns all the cores 21 to one process. In this case, the average load of each core 21 is 12.5% as shown by the shading. When in the medium load state (400%), the core assignment unit 12 assigns 4 cores 21 to each process. In this case, the average load of each core 21 is 50%. When in the high load state (800%), the core assignment unit 12 assigns 2 cores 21 to each process. In this case, the average load of each core 21 is 100%.

[0023] In this way, the core assignment unit 12 sets the number of cores 21 assigned to each process to be smaller as the load on the processor 20 increases, and sets the number of cores 21 assigned to each process to be larger as the load on the processor 20 decreases. Also, the core assignment unit 12 assigns each of the plurality of cores 21 to one process and does not assign it to other processes.

[0024] Note that, for example, the load amount boundaries for switching the increase and decrease in the number of processes are set to 200%, 400%, and 600%. In this case, the low load state is set when it is greater than 0% and less than or equal to 200%. The medium load state is divided into two stages: a first medium load state greater than 200% and less than or equal to 400%, and a second medium load state greater than 400% and less than or equal to 600%. The high load state is set when it is greater than 600% and less than or equal to 800%. The assignment of the cores 21 to each process in the first medium load state is the same as that in the medium load state in FIG. 2.

[0025] In the second medium load state, the core allocation unit 12 allocates a predetermined number of cores 21 to each of the three processes. For example, the core allocation unit 12 allocates three cores 21 to two processes and two cores 21 to the remaining one process. For example, in the second medium load state, when the load amount of the processor 20 is 600%, the average load of each core 21 is 75%.

[0026] In a graph showing the relationship between the load amount of the processor 20 and the processing performance (processing amount) of the processor 20, the solid line indicates the characteristics when resources are managed by the resource management device 10. The dashed-dotted line indicates the characteristics when implementing a distributed resource management method in which the load is distributed to all cores 21 regardless of the number of processes. The solid line and the dashed-dotted line that are adjacent and parallel to each other actually overlap, but are shifted for easy identification. Note that the processor 20 has a function of executing migration to distribute the processing load from the core 21 with concentrated processing load to the core 21 with sufficient processing load in each process when the processing load concentrates on a certain core 21.

[0027] Although not shown in the figure, in the distributed resource management method, for example, in the medium load state (400%), eight cores 21 are allocated to each of the two processes in an overlapping manner, and the load of each core 21 is 25% for each process. Also, in the high load state (800%), eight cores 21 are allocated to each of the four processes in an overlapping manner, and the load of each core 21 is 25% for each process. In the high load state, the number of cores 21 allocated to each process (eight) in the distributed resource management method is larger than the number of cores 21 allocated to each process (two) in the resource management by the resource management device 10 shown in FIG. 2.

[0028] Therefore, the occurrence frequency of migration in the distributed resource management method is higher than that during management by the resource management device 10, and waiting time occurs due to the switching of logical cores during the execution of migration. For this reason, the processing load associated with migration in the distributed resource management method becomes larger than the processing load associated with migration during management by the resource management device 10, and the processing performance of the application deteriorates as the processing load increases.

[0029] In contrast, the core allocation unit 12 sets the number of cores 21 allocated to each process to be smaller as the load on the processor 20 increases, allocates each of the plurality of cores 21 to one process, and does not allocate them to other processes. For this reason, in the resource management by the resource management device 10 shown in FIG. 2, the occurrence frequency of migration can be made lower than that of the distributed resource management method, and a decrease in the processing performance of the application can be suppressed.

[0030] Also, in the resource management by the resource management device 10 shown in FIG. 2, the number of cores 21 allocated to a process in a low load state is increased compared to the medium load state. For this reason, even when the processor 20 performs frequency control according to the load, since the load on each core 21 is small, the operating frequency does not switch to the higher side. Therefore, it is possible to suppress an increase in the power consumption of the processor 20 due to an increase in the operating frequency in the low load state.

[0031] As described above, in this embodiment, when the number of processes increases in response to an increase in the load of the processor 20, the core allocation unit 12 decreases the number of cores 21 allocated to each process. When the number of processes decreases in response to a decrease in the load of the processor 20, the core allocation unit 12 increases the number of cores 21 allocated to each process. Also, the core allocation unit 12 allocates each of the plurality of cores 21 to one process and does not allocate them to other processes. Therefore, the higher the load, the fewer the number of cores 21 allocated to each process. As a result, when the processor 20 managed by the resource management device 10 is in a high-load state, the frequency of occurrence of migration can be reduced compared to the distributed resource management method, and a decrease in the processing performance of the application can be suppressed.

[0032] Also, by increasing the number of cores 21 allocated to a process in a low-load state compared to a medium-load state, the load on each core 21 can be kept low. Thereby, even when the processor 20 performs frequency control according to the load, it is possible to suppress the switching of the operating frequency to the higher side at low load. Therefore, it is possible to suppress an increase in the power consumption of the processor 20 due to an increase in the operating frequency in a low-load state. As a result, it is possible to suppress an increase in the power consumption of the processor at low load while suppressing a decrease in the processing performance of the application at high load.

[0033] FIG. 3 shows an example of a resource management device in another embodiment. Detailed descriptions of elements similar to those in FIG. 1 are omitted. The system 300 shown in FIG. 3 includes a resource management device 100 that functions as a master node and a physical server 200 that functions as a worker node. The physical server 200 includes a CPU (Central Processing Unit) 210 and resources such as a memory (not shown). The resource management device 100 is connected to the physical server 200 via a bus 310 such as PCIe. Note that the resource management device 100 may be connected to the physical server 200 via a network.

[0034] Although not particularly limited, an example in which the system 300 is operated using Kubernetes (K8S), which is a container integration management tool, is shown below. In Kubernetes, a Pod, which is a collection of containers, is deployed to the CPU 210 in the physical server 200 that is a worker node. Each Pod is composed of one or more containers.

[0035] FIG. 3 shows an example in which a plurality of worker nodes function as a cluster. A worker node may include one physical server or may include a plurality of physical servers. Therefore, a cluster may include a plurality of physical servers.

[0036] A worker node may be used for cloud computing services. Note that the worker node for executing an application may be selected using an existing selection algorithm. Also, in this embodiment, an example in which a Pod is deployed to one worker node assigned by an existing node allocation algorithm and an application is executed on one worker node is described.

[0037] The resource management device 100 is an information processing device such as a server, for example. The resource management device 100 includes a resource monitoring unit 110, an auto-scale determination unit 120, a resource allocation unit 130 including a core allocation unit 132, a storage unit 140 in which configuration information is stored, and a storage unit 150 in which the core allocation result is stored. The storage units 140 and 150 may be included in the same storage device or may be respectively included in different storage devices.

[0038] Note that the resource monitoring unit 110, the auto-scale determination unit 120, and the resource allocation unit 130 may be implemented by a resource management program executed by a CPU (not shown) mounted on the resource management device 100. Further, the resource monitoring unit 110, the auto-scale determination unit 120, and the resource allocation unit 130 may be implemented by hardware such as an FPGA (Field-Programmable Gate Array), or may be implemented by combining hardware and software.

[0039] For example, the resource management device 100 is connected to a terminal 400 such as a console operated by an operator of the system 300. The resource management device 100 receives a definition file (manifest file) created by the operator from the terminal 400, and performs setting and monitoring of worker nodes so as to satisfy the conditions of the definition file.

[0040] For example, the definition file includes descriptions of request values (Request) of resources (CPU, memory, etc.) used by the Pod and upper limit values (Limit) of the resources. Further, the definition file includes descriptions of the upper limit value (CPU_th) of the CPU usage rate of each Pod, the minimum number of Pods (minReplicas) at the time of auto-scaling, and the maximum number of Pods (maxReplicas). Auto-scaling is a function of automatically increasing or decreasing the number of Pods deployed on worker nodes according to the load on the CPU 210. Hereinafter, the load on the CPU 210, the load on physical cores, the load on logical cores, and the load on Pods are also referred to as the CPU usage rate.

[0041] The resource management device 100 receives a command (kubectl) input by an operator to the terminal 400 and executes application processing on the worker nodes. The resource management device 100 stores the configuration information of the worker nodes in the storage unit 140. The configuration information of the worker nodes includes the total number of physical cores, the total number of logical cores (Core_total), and the number of logical cores (N) that make up each physical core by hyper-threading technology, etc. The number of logical cores (N) that make up each physical core is obtained by the resource monitoring unit 110 from the CPU 210 and is, for example, "2" in this embodiment. When hyper-threading technology is not used, the number of logical cores (N) that make up each physical core is set to "1".

[0042] The resource monitoring unit 110 monitors the resources of the CPU 210 (such as CPU usage rate per Pod) and outputs the number of Pods (Pod_N) currently deployed on the worker node and the total value (CPU_total) of the CPU usage rates of all Pods to the auto-scaling determination unit 120.

[0043] The auto-scaling determination unit 120 substitutes the total value (CPU_total) of the CPU usage rate from the resource monitoring unit 110 and the upper limit value (CPU_th) of the CPU usage rate of each Pod into Equation (1). Then, the auto-scaling determination unit 120 calculates an appropriate number of Pods (Pod_M) for continuing the application processing (rounding up the decimal part). The auto-scaling determination unit 120 outputs the calculated number of Pods (Pod_M) to the resource allocation unit 130 as the number of deployments after the change. The auto-scaling determination unit 120 is an example of a process number change unit that changes the number of deployments of Pods executed by the CPU 210 according to the change in the load of the CPU 210. Pod_M = CPU_total / CPU_th ‥(1)

[0044] For example, during the execution of application processing, when the load on the CPU 210 increases, the auto-scaling determination unit 120 determines to increase the number of Pods, and when the load on the CPU 210 decreases, the auto-scaling determination unit 120 determines to decrease the number of Pods. Note that the increase or decrease in the number of Pods is performed between the minimum number of Pods (minReplicas) and the maximum number of Pods (maxReplicas).

[0045] Based on the configuration information of the CPU 210 held in the storage unit 140, the resource allocation unit 130 performs various settings such as the deployment of Pods to worker nodes. For example, the resource allocation unit 130 causes the core allocation unit 132 to perform the process of allocating logical cores to each Pod. The resource allocation unit 130 stores the logical core allocation results for each Pod by the core allocation unit 132 in the storage unit 150.

[0046] Based on the number of Pods (Pod_M) calculated by the auto-scaling determination unit 120, the core allocation unit 132 calculates the number of logical cores to be allocated to each of the Pods deployed on the worker nodes. For example, the core allocation unit 132 uses the total number of logical cores L (Core_total) in the CPU 210, the number of logical cores N that make up the physical cores, and the number of Pods (Pod_M) from the auto-scaling determination unit 120 to calculate the number of logical cores to be allocated to each Pod. Then, the core allocation unit 132 issues an instruction to the worker node to allocate the calculated number of logical cores to each Pod. The total number of logical cores L (Core_total) is the total number of logical cores L that can be allocated to the Pods, and in FIG. 4, it is 16.

[0047] For example, when the core allocation unit 132 increases the number of Pods deployed on the worker node based on the increase in the load on the CPU 210, the core allocation unit 132 decreases the number of logical cores L allocated to each Pod. When the core allocation unit 132 decreases the number of Pods deployed on the worker node based on the decrease in the load on the CPU 210, the core allocation unit 132 increases the number of logical cores L allocated to each Pod. Hereinafter, the number of deployed Pods is also referred to as the number of Pods.

[0048] The resource management device 100 performs the process of increasing or decreasing the number of Pods deployed to the CPU 210 and the process of allocating the logical cores L to each Pod according to the following procedure. As a preliminary preparation, the order of the physical cores P (FIG. 4) allocated to a plurality of Pods determined by the operator (for example, in ascending order of the physical core numbers) is stored in the storage unit 140 etc. of the resource management device 100.

[0049] (Step 1) The core allocation unit 132 calculates the number of logical cores L to be allocated to each Pod according to the number of Pods (Pod_M) calculated by the auto-scaling determination unit 120. Step 1 includes Step 1-1, Step 1-2, and Step 1-3. In Step 1-1, it is determined whether the total number of logical cores L for executing the application is divisible by the required number of cores of the logical cores L. The required number of cores of the logical cores L is obtained by multiplying the number of logical cores L required to realize the processing performance of one Pod (required number of logical cores L) by the number of Pods (Pod_M). For example, when the maximum processing performance per Pod is 200% in terms of CPU usage rate, it can be realized with 2 logical cores L. Therefore, the required number of logical cores L per Pod is "2".

[0050] In Step 1-2, when the total number of logical cores L is divisible by the required number of cores, the number of logical cores L to be allocated to each Pod is calculated. In Step 1-3, when the total number of logical cores L is not divisible by the required number of cores, the number of logical cores L to be allocated to each Pod is calculated. Examples of Step 1-1, Step 1-2, and Step 1-3 are described with reference to FIGS. 7 to 9.

[0051] (Step 2) The core allocation unit 132 determines the numbers of the physical cores P to be allocated to the Pods according to the number of logical cores L to be allocated to each Pod determined in Step 1. An example of Step 2 is described with reference to FIG. 10.

[0052] FIG. 4 shows an example of the configuration of the CPU 210 in FIG. 3. For example, the CPU 210 has eight physical cores P (P1 - P8), and two logical cores L are generated for each physical core P. That is, the CPU 210 includes 16 logical cores L (L0 - L15). Therefore, the total number of logical cores L is 16. For example, logical cores L0 - L7 are generated for each of physical cores P1 - P8, and logical cores L8 - L15 are generated for each of physical cores P1 - P8.

[0053] For each logical core L, the CPU usage rate at the maximum load is 100%, and the CPU usage rate at the minimum load is 0%. Since the physical core P includes two logical cores L, the CPU usage rate at the maximum load of the physical core P is 200%. Since the CPU 210 includes 16 logical cores L, the CPU usage rate at the maximum load of the CPU 210 is 1600%. Hereinafter, it is assumed that the CPU usage rate changes due to the execution of the application and does not change due to the execution of the OS (Operating System) other than the application except for migration.

[0054] The above-described various parameters used in the resource management by the resource management device 100 are shown below. The numerical values in parentheses indicate the values used in this embodiment. Request: The requested value of the resources (CPU, memory, etc.) used by the Pod CPU_th: The upper limit value of the CPU usage rate of each Pod (200%) minReplicas: The minimum number of Pods (1) maxReplicas: The maximum number of Pods (8) Core_total: The total number of logical cores L in the CPU 210 (16) N: The number of logical cores L that make up each physical core P by the hyperthreading technology (2) CPU_total: The total value of the CPU usage rates of all the currently deployed Pods Pod_N: The number of deployed Pods Pod_M: The newly calculated number of Pods (the number of deployments after the change)

[0055] In this embodiment, an example of using Kubernetes to manage the resources of worker nodes is described. However, the resources of worker nodes may also be managed using the task scheduler in the Linux (registered trademark) kernel. When using the task scheduler in the Linux kernel, the Pods to be controlled and the number of Pods may be replaced with processes and the number of processes, respectively. Then, the logical core L can be specified by the settings of cgroups in the Linux kernel and assigned to the processes.

[0056] In the task scheduler in the Linux kernel, for example, the number of deployed Pods (Pod_N) is replaced with the number of deployed processes. The minimum number of Pods (minReplicas) is replaced with the minimum number of processes, and the maximum number of Pods (maxReplicas) is replaced with the maximum number of processes. The newly calculated number of Pods (Pod_M) is replaced with the newly calculated number of processes. The number of logical cores assigned to a Pod is replaced with the number of logical cores assigned to a process, and the number of physical cores assigned to a Pod is replaced with the number of physical cores assigned to a process.

[0057] FIG. 5 shows an example of the frequency control of the physical core P in FIG. 4. Each physical core P sets the operating frequency to φ1 when the load of the physical core P is less than the threshold, and sets the operating frequency to φ2 higher than φ1 when the load of the physical core P is equal to or higher than the threshold. The power consumption is greater when the operating frequency is higher. Also, the rate of increase in power consumption in response to an increase in load when the operating frequency is φ2 is higher than the rate of increase in power consumption in response to an increase in load when the operating frequency is φ1. This is because the power consumption is proportional to the cube of the operating frequency.

[0058] FIG. 6 shows an example of the change in the number of Pods that increases or decreases according to the load of the CPU 210 by the auto-scale determination unit 120 in FIG. 3. The numerical value loaded at the end of the Pod indicates the identification number of the Pod.

[0059] Each time the total CPU usage value (CPU_total) increases by a preset specified value, the auto-scaling determination unit 120 calculates a number of Pods (Pod_M) that is one more than the current number of Pods (Pod_N). Each time the total CPU usage value (CPU_total) decreases by the specified value, the auto-scaling determination unit 120 calculates a number of Pods (Pod_M) that is one less than the current number of Pods (Pod_N). For example, the specified value is 200%, which is the maximum CPU usage of two logical cores L, and represents the processing performance of one Pod. In other words, the processing performance of one Pod is set to the maximum processing performance of two logical cores L.

[0060] For example, when the CPU usage of CPU 210 exceeds 200%, the resource allocation unit 130 increases the number of Pods from 1 to 2, and when the CPU usage of CPU 210 exceeds 400%, the resource allocation unit 130 increases the number of Pods from 2 to 3. Similarly, the resource allocation unit 130 increases the number of Pods by 1 each time the CPU usage of CPU 210 increases by 200%. The maximum CPU usage of CPU 210 is 1600%. The number of logical cores L allocated to each Pod is shown in FIG. 7.

[0061] FIG. 7 shows an example of a method for calculating the number of logical cores allocated to each Pod implemented by the core allocation unit 132 in FIG. 3. That is, FIG. 7 shows an example of a resource management method of the resource management device 100. For example, the calculation process shown in FIG. 7 may be executed by a resource management program executed by the CPU of the resource management device 100. Hereinafter, a procedure for calculating the number of logical cores allocated to each Pod by the core allocation unit 132 is shown.

[0062] (Step 1-1) The core allocation unit 132 divides the total number of logical cores L, which is 16, by "the number of logical cores L required by all Pods" according to equation (2) to obtain the quotient and the remainder. Then, the core allocation unit 132 calculates the number of logical cores L to be allocated to each Pod using the quotient and the remainder obtained by equation (2). "The number of logical cores L required by all Pods" is obtained according to equation (3). In equation (3), "CPU_th÷100" is the required number of logical cores L per Pod (="2"). (Total number of logical cores L)÷(Number of logical cores L required by all Pods) ‥(2) "Number of logical cores L required by all Pods" = CPU_th÷100×Pod_M ‥(3)

[0063] In this embodiment, "the number of logical cores L required by all Pods" is the value obtained by multiplying the number of logical cores required by each Pod, which is "2", by the number of Pods (Pod_M). "The number of logical cores L required by all Pods" is the number of logical cores L required to realize the processing performance of the number of Pods (Pod_M) calculated by the auto-scaling determination unit 120, and is an example of the required number of cores. For example, "the number of logical cores L required by all Pods" is "6" when the number of Pods is "3", and "10" when the number of Pods is "5".

[0064] (Step 1-2) When equation (2) is divisible, the core allocation unit 132 allocates to each Pod the number of logical cores obtained by "quotient×(required number of logical cores L per Pod "2")". At this time, the core allocation unit 132 does not specify the numbers of the logical cores L to be allocated to each Pod.

[0065] (Step 1-3) When equation (2) is not divisible, the core allocation unit 132 allocates to each Pod the number of logical cores obtained by "quotient×(required number of logical cores L per Pod "2")" (Step 1-3(a) in FIGS. 8 and 9). Next, the core allocation unit 132 sequentially allocates logical cores L in units of 2 to the Pods using a method such as round-robin until there is no remainder (Step 1-3(b) in FIGS. 8 and 9).

[0066] FIG. 8 shows an example of a method for allocating logical cores L to each Pod when the total number of logical cores L in FIG. 7 is not divisible by the number of Pods (Pod_M). The allocation shown in FIG. 8 is performed by the core allocation unit 132 according to the above-described steps 1-3. Note that which logical core L is allocated to each Pod will be described with reference to FIG. 10.

[0067] When the number of Pods (Pod_M) is "3", first, the core allocation unit 132 performs the above-described step 1-1 before steps 1-3. Then, the core allocation unit 132 divides the total number of logical cores L, Core_total = "16", by the required number of cores = "6", obtaining a quotient of "2" and a remainder of "4". The required number of cores is the product of the number of logical cores "2" per physical core P and the newly calculated number of Pods (Pod_M) "3" (2 × 3 = 6).

[0068] Next, in step 1-3(a), the core allocation unit 132 sequentially allocates the number of logical cores "4", which is represented by the value obtained by multiplying the quotient "2" by the required number "2", to each Pod. Next, in step 1-3(b), the core allocation unit 132 sequentially allocates the 4 logical cores L corresponding to the remainder "4" to Pod1 and Pod2 with higher numbers in units of 2. As a result, 6 logical cores L are allocated to each of Pod1 and Pod2, and 4 logical cores L are allocated to Pod3.

[0069] When the number of Pods (Pod_M) is "5", first, the core allocation unit 132 performs the above-described step 1-1 before steps 1-3. Then, the core allocation unit 132 divides the total number of logical cores L, Core_total = "16", by the required number of cores = "10", obtaining a quotient of "1" and a remainder of "6". The required number of cores is the product of the number of logical cores "2" per physical core P and the newly calculated number of Pods (Pod_M) "5" (2 × 5 = 10).

[0070] Next, in step 1-3(a), the core allocation unit 132 sequentially allocates the number of logical cores "2", which is the value obtained by multiplying the quotient "1" by the required number "2", to each Pod. Next, in step 1-3(b), the core allocation unit 132 sequentially allocates six logical cores L corresponding to the remainder "6" to the Pods with higher numbers, Pod1, Pod2, and Pod3, in units of two. As a result, four logical cores L are allocated to each of Pod1, Pod2, and Pod3, and two logical cores L are allocated to Pod4 and Pod5.

[0071] FIG. 9 shows another example of a method for allocating logical cores L to each Pod when the total number of logical cores L is not divisible by the number of Pods (Pod_M) in FIG. 7. The allocation shown in FIG. 9 is performed by the core allocation unit 132 according to the above-described step 1-3, similar to FIG. 8. Note that which logical core L is allocated to each Pod is described in FIG. 10.

[0072] When the number of Pods (Pod_M) is "6", first, the core allocation unit 132 performs the above-described step 1-1 before step 1-3. Then, the core allocation unit 132 divides the total number of logical cores Core_total = "16" by the required number of cores = "10" to obtain a quotient "1" and a remainder "4". The required number of cores is the product of the number of logical cores "2" per physical core P and the newly calculated number of Pods (Pod_M) "6" (2×6 = 12).

[0073] Next, in step 1-3(a), the core allocation unit 132 sequentially allocates the number of logical cores "2", which is the value obtained by multiplying the quotient "1" by the required number "2", to each Pod. Next, in step 1-3(b), the core allocation unit 132 sequentially allocates four logical cores L corresponding to the remainder "4" to the Pods with higher numbers, Pod1 and Pod2, in units of two. As a result, four logical cores L are allocated to each of Pod1 and Pod2, and two logical cores L are allocated to Pods 3 to 6.

[0074] When the number of Pods (Pod_M) is "7", first, the core allocation unit 132 performs the above-described step 1-1 before steps 1-3. Then, the core allocation unit 132 divides the total number of logical cores Core_total = "16" by the required number of cores = "14" to obtain a quotient of "1" and a remainder of "2". The required number of cores is the product of the number of logical cores "2" per physical core P and the newly calculated number of Pods (Pod_M) "7" (2 × 7 = 14).

[0075] Next, in step 1-3(a), the core allocation unit 132 sequentially allocates the number of logical cores "2", which is indicated by the value obtained by multiplying the quotient "1" by the required number "2", to each Pod. Next, in step 1-3(b), the core allocation unit 132 allocates the two logical cores L corresponding to the remainder "2" to Pod1 with the higher number in units of two. As a result, 4 logical cores L are allocated to Pod1, and 2 logical cores L are allocated to each of Pod2 to Pod7.

[0076] FIG. 10 shows an example of the allocation result of the logical cores L to each Pod by the core allocation unit 132 in FIG. 3. FIG. 10 shows the logical cores L allocated to each Pod according to the procedure described in FIGS. 7 to 9.

[0077] The allocation of the logical cores L to each Pod is performed by sequentially allocating the logical cores L associated with the physical core P according to the predetermined order of the physical cores P in ascending order of the Pod numbers. The order of the physical cores P is determined in advance by the operator according to step 1 described in FIG. 3.

[0078] In the example shown in FIG. 10, the order of the physical cores P is in ascending order of the physical core numbers (in the order from P1 to P8). For example, to the physical core n (where n is any one of 1 to 8), the logical core n - 1 and the logical core n + 7 are associated. When the allocation of the logical cores L to the Pods is insufficient for one physical core P, the logical cores L associated with the next physical core P are sequentially allocated to the Pods. The allocation result is held in the storage unit 150 in FIG. 3.

[0079] For example, when the newly calculated number of Pods (Pod_M) is 4 and 4 logical cores L are assigned to each Pod, the logical cores L0, L8, L1, and L9 corresponding to physical core numbers 1 and 2 are assigned to Pod1. The logical cores L2, L10, L3, and L11 corresponding to physical core numbers 3 and 4 are assigned to Pod2. The logical cores L4, L12, L5, and L13 corresponding to physical core numbers 5 and 6 are assigned to Pod3. The logical cores L6, L14, L7, and L15 corresponding to physical core numbers 7 and 8 are assigned to Pod4.

[0080] FIG. 11 shows an example of the increase and decrease in the number of Pods implemented by the resource management device 100 in FIG. 3 according to the change in CPU usage rate and the allocation of logical cores L. In FIG. 9, for the sake of simplicity of explanation, an example in which the CPU usage rate changes between 400%, 800%, 1200%, and 1600% is shown. The resource management device 100 in FIG. 3 increases the number of logical cores L assigned to each Pod as the CPU usage rate is lower, and decreases the number of logical cores L assigned to each Pod as the CPU usage rate is higher.

[0081] When the CPU usage rate is 400%, 8 logical cores L are assigned to each of the 2 Pods 1 - Pod2, and each logical core L operates at an average CPU usage rate of 25%. When the CPU usage rate is 800%, 4 logical cores L are assigned to each of the 4 Pods 1 - Pod4, and each logical core L operates at an average CPU usage rate of 50%.

[0082] When the CPU usage rate is 1200%, 4 logical cores L are assigned to each of the 2 Pods 1 - Pod2, and 2 logical cores L are assigned to each of the 4 Pods 3 - Pod6. Each logical core L of Pods 1 - Pod2 operates at an average CPU usage rate of 50%, and each logical core L of Pods 3 - Pod6 operates at an average CPU usage rate of 100%. When the logical core CPU usage rate is 1600%, 2 logical cores L are assigned to each of the 8 Pods 1 - Pod8, and each logical core L operates at an average CPU usage rate of 100%.

[0083] When the CPU utilization rate of CPU 210 is 1200% and 1600%, since there are logical cores L with a CPU utilization rate of 100%, when there is a bias in the CPU utilization rate, migration may be executed on a per-Pod basis. However, since two high-load logical cores L are assigned to one Pod, even when migration is executed, the migration is only executed between two logical cores L. Therefore, for example, compared with the case where migration is executed among 16 logical cores L, the processing load of migration can be reduced, and a decrease in the processing performance of the application due to migration can be suppressed.

[0084] Also, the smaller the CPU utilization rate of CPU 210, the more logical cores L are assigned to each Pod to disperse the CPU utilization rate of each logical core L, so that the CPU utilization rate of each physical core P can be dispersed. As a result, since the load on physical core P is suppressed from increasing during low load, for example, it is possible to suppress the operating frequency of physical core P from switching from φ1 to φ2 in FIG. 5. As a result, it is possible to suppress an increase in power consumption due to the concentration of load on a specific physical core P when the CPU utilization rate is low.

[0085] FIG. 12 shows an example of the increase and decrease in the number of Pods and the allocation of logical cores L implemented by another resource management device in response to changes in the CPU utilization rate. Similar to FIG. 11 in FIG. 12, an example in which the CPU utilization rate changes between 400%, 800%, 1200%, and 1600% is shown. For example, FIG. 12 shows an example when Kubernetes is used.

[0086] The default algorithm of Kubernetes disperses logical cores L as much as possible for each Pod and allocates many logical cores L. Therefore, regardless of the CPU utilization rate, 16 logical cores L are allocated to each Pod. In other words, each logical core L is allocated to a plurality of Pods in a duplicate manner.

[0087] When the CPU usage rate is 400%, for the 16 logical cores L, the CPU usage rate per Pod is 12.5%, and they operate with an average CPU usage rate of 25%. When the CPU usage rate is 800%, for the 16 logical cores L, the CPU usage rate per Pod is 12.5%, and they operate with an average CPU usage rate of 50%. When the CPU usage rate is 1200%, the CPU usage rate per Pod is 12.5%, and the 16 logical cores L operate with an average CPU usage rate of 75%.

[0088] When the CPU usage rate is 1600%, for the 16 logical cores L, the CPU usage rate per Pod is 12.5%, and they operate with an average CPU usage rate of 100%. When the CPU usage rate is high, migration may be executed, and the migration may be executed among the 16 logical cores L. In this case, the processing load of the migration becomes large, and the processing performance of the application deteriorates due to the migration.

[0089] FIG. 13 shows another example of the increase and decrease in the number of Pods implemented according to the change in the CPU usage rate and the allocation of the logical cores L by another resource management device. The example shown in FIG. 13 was studied by the inventor and is not publicly known. Similar to FIG. 11, examples of changes in the CPU usage rate among 400%, 800%, 1200% and 1600% are shown in FIG. 13.

[0090] The algorithm for allocating the logical cores L shown in FIG. 13 allocates 2 pre-specified logical cores L per Pod regardless of the CPU usage rate. Therefore, when the CPU usage rate of the CPU 210 is high, the migration is executed between 2 logical cores L as in FIG. 11, and the decrease in the processing performance of the application due to the migration can be suppressed.

[0091] On the other hand, regardless of the CPU usage rate of the CPU 210, each logical core L operates at an average CPU usage rate of 100%, and the operating frequency of the physical core P that operates is set to φ2 shown in FIG. 5, for example. As described above, since the power consumption is proportional to the cube of the operating frequency, even when the CPU usage rate of the CPU 210 is low, the power consumption of the CPU 210 increases significantly compared to the case where the operating frequency is set to φ1.

[0092] FIG. 14 shows an example of the processing performance and power consumption of the CPU 210 in the logical core L allocation algorithm shown in FIGS. 11 to 13. In each of the three lines of the graph showing the relationship between the CPU usage rate and the processing performance and the three lines of the graph showing the relationship between the CPU usage rate and the power consumption, two or three adjacent parallel lines actually overlap, but are shifted for easy identification.

[0093] In the method of allocating the logical core L when Kubernetes corresponding to FIG. 12 is used, the number of logical cores L that are the migration targets when the CPU usage rate is high is larger than the method of allocating the logical core L corresponding to FIGS. 11 and 13. For this reason, in FIG. 12, when the CPU usage rate is high, the processing load for migration increases, and the processing performance of the application decreases by the amount of the migration processing load.

[0094] In the method of allocating the logical core L corresponding to FIG. 13, regardless of the CPU usage rate, the operating frequency of the CPU 210 is always set high. For this reason, in FIG. 13, except when the CPU usage rate is maximum, the power consumption of the CPU 210 is larger than the characteristics of FIGS. 11 and 12.

[0095] On the other hand, in the method of allocating the logical core L by the resource management device 100 corresponding to FIG. 11, only two logical cores L are allocated for each Pod when the CPU usage rate is high. For this reason, in FIG. 11, the processing load for migration at high load can be reduced, and the decrease in the processing performance of the application can be suppressed.

[0096] Also, in the method of allocating the logical core L by the resource management device 100 corresponding to FIG. 11, when the CPU usage rate is low, the number of logical cores L allocated to each Pod is increased to disperse the load of each logical core L. Therefore, in FIG. 11, it is possible to suppress the increase in the load of the physical core P when the CPU usage rate is low, and it is possible to suppress the switching of the operating frequency of the physical core P to the higher side. Therefore, it is possible to suppress the occurrence of a problem that the power consumption increases when the CPU usage rate is low.

[0097] FIG. 15 shows an example of the method of allocating the logical core L to the Pod by the resource management device 100 of FIG. 3. That is, FIG. 15 shows an example of the resource management method of the resource management device 100. For example, the flow shown in FIG. 15 may be realized by a resource management program executed by the CPU of the resource management device 100. For example, the flow shown in FIG. 15 is implemented by the auto-scale determination unit 120 and the resource allocation unit 130 of FIG. 3.

[0098] First, in step S10, the auto-scale determination unit 120 acquires the current number of Pods (Pod_N) acquired by the resource monitoring unit 110. The resource allocation unit 130 acquires the upper limit value (CPU_th) of the CPU usage rate of each Pod included in the definition file created by the operator and the total number of logical cores L (Core_total) held as configuration information in the storage unit 140. For example, in Kubernetes, Core_total can be acquired by the "$ kubectl top pod" command.

[0099] Next, in step S20, the auto-scale determination unit 120 acquires the total value (CPU_total) of the CPU usage rates of all the Pods acquired by the resource monitoring unit 110.

[0100] Next, in step S30, the auto-scale determination unit 120 substitutes the total CPU usage value CPU_total and the upper limit value of the CPU usage of each Pod (CPU_th) into the above formula (1) to calculate the currently required number of Pods (Pod_M) according to the current CPU usage of the CPU 210.

[0101] Next, in step S40, the resource allocation unit 130 compares the current number of Pods (Pod_N) with the newly calculated number of Pods (Pod_M). If the current number of Pods (Pod_N) is less than the newly calculated number of Pods (Pod_M), the resource allocation unit 130 implements step S50 to increase the number of Pods. If the current number of Pods (Pod_N) is greater than the newly calculated number of Pods (Pod_M), the resource allocation unit 130 implements step S70 to decrease the number of Pods. If the current number of Pods (Pod_N) is equal to the newly calculated number of Pods (Pod_M), the resource allocation unit 130 returns to the process of step S20 without changing the number of Pods.

[0102] In step S50, the resource allocation unit 130 increases the number of Pods. Next, in step S60, the resource allocation unit 130 decreases the number of logical cores allocated to one Pod and returns to the process of step S20.

[0103] In step S70, the resource allocation unit 130 decreases the number of Pods. Next, in step S80, the resource allocation unit 130 increases the number of logical cores allocated to one Pod and returns to the process of step S20. By repeating the above processes, the increase and decrease process of the number of Pods shown in FIGS. 6 to 11 and the change process of the allocation of the logical core L are implemented.

[0104] FIG. 16 shows an example of the hardware configuration of the resource management apparatus 100 in FIG. 3. The resource management apparatus 100 includes a CPU 161, a ROM (Read Only Memory) 162, a RAM (Random Access Memory) 163, and a communication interface section 164. The resource management apparatus 100 also includes an input interface section 165, an output interface section 166, an input / output interface section 167, a media interface section 168, and a bus 169. The CPU 161, ROM 162, RAM 163, communication interface section 164, input interface section 165, output interface section 166, input / output interface section 167, and media interface section 168 are interconnected via the bus 169.

[0105] The CPU 161 executes various programs such as an OS and a resource management program. The ROM 162 stores a basic program and various parameters that are executed by the CPU 161 when the resource management apparatus 100 is started up. The RAM 163 stores various programs executed by the CPU 161 and data used by the programs.

[0106] The communication interface section 164 is connected to another server or another storage device via a network, for example. An input device 171 such as a mouse and a keyboard is connected to the input interface section 165. An output device 172 such as a display is connected to the output interface section 166. The input device 171 and the output device 172 correspond to the terminal 400 (console) in FIG. 3.

[0107] An input / output device 173 such as an HDD or an SSD is connected to the input / output interface section 167. A recordable medium 174 readable by a computer such as a USB (Universal Serial Bus) memory, a CD-ROM (Compact Disc Read Only Memory), or a DVD (Digital Versatile Disc) is detachably connected to the media interface section 168.

[0108] For example, various programs such as a resource management program may be recorded on a recording medium 174, transferred from the recording medium 174 to a RAM 163 or the like via a media interface unit 168, and executed by a CPU 161. Also, various programs such as a resource management program may be held in an input / output device 173, transferred from the input / output device 173 to the RAM 163 via an input / output interface unit 167, and executed by the CPU 161. Further, various programs such as a resource management program may be transferred from a storage device connected to a network to the RAM 163 or the like via a communication interface unit 164 and executed by the CPU 161.

[0109] The physical server 200 (worker node) or cluster in FIG. 3 may be connected to an input / output interface unit 167 as an input / output device 173. In this case, the input / output interface unit 167 may have a PCIe interface. Also, the physical server 200 (worker node) or cluster may be deployed on a network and connected to a communication interface unit 164. In this case, the physical server 200 (worker node) or cluster may be constructed as a cloud.

[0110] Note that the hardware configuration of the resource management device 10 shown in FIG. 1 may have the same configuration as that in FIG. 16. Also, the hardware configuration of the worker node in FIG. 3 may have the same configuration as that in FIG. 16.

[0111] As described above, also in this embodiment, the same effects as those of the above-described embodiment can be obtained. For example, when the number of Pods is increased in response to an increase in the CPU usage rate of the CPU 210, the core allocation unit 132 decreases the number of logical cores L allocated to each of the Pods. When the number of Pods is decreased in response to a decrease in the CPU usage rate of the CPU 210, the core allocation unit 132 increases the number of logical cores L allocated to each of the Pods. Also, the core allocation unit 132 allocates each of the plurality of logical cores L to one Pod and does not allocate them to other Pods.

[0112] Therefore, the higher the CPU usage rate of the CPU 210, the fewer the number of logical cores L allocated to each Pod. As a result, when the CPU 210 managed by the resource management device 100 is in a high-load state, the frequency of occurrence of migration can be made lower than that of the distributed resource management method, and a decrease in the processing performance of the application can be suppressed.

[0113] Also, the lower the CPU usage rate of the CPU 210, the more the number of logical cores L allocated to each Pod, and the CPU usage rates of each logical core L and each physical core P can be dispersed. Thereby, since an increase in the load of the physical core P during low load is suppressed, even when the CPU 210 performs frequency control according to the load, it is possible to suppress switching to a higher operating frequency during low load. Therefore, it is possible to suppress an increase in the power consumption of the CPU 210 due to an increase in the operating frequency in a low-load state. As a result, it is possible to suppress an increase in the power consumption of the processor during low load while suppressing a decrease in the processing performance of the application during high load.

[0114] Furthermore, in this embodiment, when the total number of logical cores L is divisible by the number of logical cores L required by all Pods (required core number), the core allocation unit 132 allocates to each Pod the number of logical cores obtained by "quotient × (required number of logical cores L per Pod "2")". When the total number of logical cores L is not divisible by the required core number, the core allocation unit 132 allocates to each Pod the number of logical cores obtained by "quotient × (required number of logical cores L per Pod "2")", and sequentially allocates logical cores L to the Pods in units of two until there is no remainder. Thereby, regardless of the number of logical cores L generated in the physical core P, the total number of logical cores L, and the number of Pods to be deployed, an appropriate number of logical cores L can be allocated to each Pod using a common algorithm.

[0115] FIG. 17 shows an example of the change in the number of Pods that increase or decrease according to the CPU load in another embodiment. The resource management apparatus of this embodiment has the same configuration and functions as the resource management apparatus 100 in FIG. 3, except that the functions of the auto-scaling determination unit 120 and the resource allocation unit 130 in FIG. 3 are different. Therefore, in the following description, the elements of the resource management apparatus 100 in FIG. 3 are used.

[0116] Similar to FIG. 3, the resource management apparatus 100 is installed in the system 300 together with the CPU 210 and manages the resources of the CPU 210 using Kubernetes (K8S). Note that the resource management apparatus 100 may manage the resources of the CPU 210 using a task scheduler in the Linux kernel.

[0117] In this embodiment, the CPU 210 has 12 physical cores P (P1 - P12 in FIG. 18). The number (N) of logical cores L that make up each physical core P is "2" due to hyperthreading technology. Therefore, two logical cores L that are allocated to the Pod are generated for each physical core P, and the CPU 210 includes 24 logical cores L (L0 - L23 in FIG. 18).

[0118] In this embodiment, two types of Pods (Pod - A, Pod - B) that each execute an application are deployed on the CPU. Hereinafter, for simplicity of explanation, it is assumed that the auto - scaling determination unit 120 calculates the same number of Pods (Pod_M) of Pod - A and Pod - B for each other. Therefore, as shown in FIG. 17, the resource allocation unit 130 increases or decreases the same number of Pod - A and Pod - B. Note that the auto - scaling determination unit 120 may calculate different numbers of Pods (Pod_M) for Pod - A and Pod - B for each other. Also, since Pod - A and Pod - B each execute an application, the directions of increase and decrease in the number of Pods may be opposite to each other.

[0119] The minimum number of Pods (minReplicas) for Pod-A and Pod-B is "1", and the maximum number of Pods (maxReplicas) for Pod-A and Pod-B is "4". The upper limit value (CPU_th) of the CPU usage rate for each Pod-A is 200%, and the upper limit value (CPU_th) of the CPU usage rate for each Pod-B is 400%. Therefore, the number of logical cores (required number) required for each Pod-A is "2", and the number of logical cores (required number) required for each Pod-B is "4". The total number (Core_total) of logical cores L in CPU210 is 24. Therefore, the CPU usage rate at the maximum load of CPU210 is 2400%.

[0120] FIG. 18 shows an example of a method for calculating the number of logical cores to be allocated to each Pod, which is implemented by the core allocation unit 132 of the resource management device 100 that increases or decreases the number of Pods as shown in FIG. 17. That is, FIG. 18 shows an example of the resource management method of the resource management device 100. For example, the calculation process shown in FIG. 18 may be executed by a resource management program executed by the CPU of the resource management device 100. The core allocation unit 132 increases Pod-A and Pod-B by one each, and decreases Pod-A and Pod-B by one each.

[0121] The resource management device 100 performs the process of increasing or decreasing the number of Pods of Pod-A and Pod-B deployed in CPU210 and the process of allocating logical cores L to each of Pod-A and Pod-B according to the following procedure. As a preliminary preparation, the order of physical cores P (for example, in ascending order of physical core numbers) allocated to a plurality of Pods, which is determined in advance by the operator, is stored in the storage unit 140 etc. of the resource management device 100.

[0122] (Step 1-1) The core allocation unit 132 divides the total number of logical cores L, which is 24 according to Equation (4), by "the number of logical cores L required by all Pod-A and Pod-B" to obtain the quotient and remainder. Then, the core allocation unit 132 uses the quotient and remainder obtained in Equation (4) to calculate the number of logical cores L to be allocated to each of Pod-A and Pod-B. "The number of logical cores L required by all Pod-A and Pod-B" is an example of the required number of cores. "The number of logical cores L required by all Pod-A and Pod-B" is obtained according to Equation (5). Note that the required number, which is the upper limit value (CPU_th) of the CPU usage rate in Equation (5), is different for each of Pod-A and Pod-B. (Total number of required logical cores L)÷(Number of logical cores L required by all Pod-A and Pod-B) ‥(4) "Number of logical cores L required by all Pod-A and Pod-B" = CPU_th÷100×Pod_M ‥(5)

[0123] In this embodiment, "the number of logical cores L required by all Pod-A and Pod-B" is the sum of the value obtained by multiplying the required number of logical cores L, which is "2", for each Pod-A by the number of Pods (Pod_M) of Pod-A and the value obtained by multiplying the required number of logical cores L, which is "4", for each Pod-B by the number of Pods (Pod_M) of Pod-B. For example, when the number of Pods (Pod_M) of each of Pod-A and Pod-B is "1", it is "6", and when the number of Pods (Pod_M) of each of Pod-A and Pod-B is "3", it is "18".

[0124] (Step 1-2) When Equation (4) is divisible, the core allocation unit 132 allocates the number of logical cores obtained by "quotient × (required number of logical cores L for each Pod-A, which is '2')" to each Pod-A, and allocates the number of logical cores obtained by "quotient × (required number of logical cores L for each Pod-B, which is '4')" to each Pod-B. At this time, the core allocation unit 132 does not specify the numbers of the logical cores L to be allocated to each of Pod-A and Pod-B.

[0125] (Step 1-3) When Equation (4) is not divisible, the core allocation unit 132 allocates the number of logical cores obtained by "quotient × (required number of logical cores L per Pod-A '2')" to each Pod-A (Step 1-3(a) in Fig. 19). Also, it allocates the number of logical cores obtained by "quotient × (required number of logical cores L per Pod-B '4')" to each Pod-B (Step 1-3(b) in Fig. 19).

[0126] Furthermore, the core allocation unit 132 sequentially allocates the number of logical cores L indicated by the remainder to Pod-A and Pod-B in units of 2, which is the minimum required number of logical cores L, using a method such as round-robin. At this time, the core allocation unit 132 weights Pod-A and Pod-B at "1:2" and allocates 2 logical cores to each of 1 Pod-A and 2 Pod-Bs (Step 1-3(c) in Fig. 19). That is, the core allocation unit 132 changes the allocation ratio of the number of logical cores L corresponding to the remainder to Pod-A and Pod-B according to the weighting of Pod-A and Pod-b.

[0127] Fig. 19 shows an example of the method of allocating logical cores L to each Pod when the total number of logical cores L is not divisible by the number of Pods (Pod_M) in Fig. 18. In Fig. 19, an example where the number of Pods (Pod_M) is "3" is shown.

[0128] When the number of Pods (Pod_M) is "3", first, in Step 1-1 described above before Step 1-3, the core allocation unit 132 divides the total number of logical cores Core_total = "24", which is the total number of logical cores L, by the required number of logical cores L (="18"), which is the required core number. Thereby, a quotient "1" and a remainder "6" are obtained.

[0129] Next, in Step 1-3(a), the core allocation unit 132 sequentially allocates the number of logical cores "2", which is indicated by the value obtained by multiplying the quotient "1" by the required number "2", to each Pod-A. Also, in Step 1-3(b), the core allocation unit 132 sequentially allocates the number of logical cores "4", which is indicated by the value obtained by multiplying the quotient "1" by the required number "4", to each Pod-B.

[0130] Next, in step 1-3(c), the core allocation unit 132 allocates six logical cores L corresponding to the remainder "6" to Pod-A1, Pod-B1, and Pod-B2 with higher numbers in units of two. As a result, four logical cores L are allocated to Pod-A1, and two logical cores L are allocated to each of Pod-A2 and Pod-A3. Also, six logical cores L are allocated to each of Pod-B1 and Pod-B2, and four logical cores L are allocated to Pod-B3.

[0131] FIG. 20 shows an example of the result of allocating logical cores to each of Pod-A and Pod-B by the core allocation unit 132 of the resource management device 100 that increases or decreases the number of pods as shown in FIG. 17. In FIG. 20, reference sign A indicates Pod-A, and reference sign B indicates Pod-B. The numbers appended after reference signs A and B indicate the pod numbers.

[0132] The allocation of logical cores L to each of Pod-A and Pod-B is performed by sequentially allocating the logical cores L associated with the physical cores P in the order of Pod-A and Pod-B according to the predetermined order of the physical cores P in ascending order of the pod numbers. The order of the physical cores P is determined in advance by the operator.

[0133] In the example shown in FIG. 20, the order of the physical cores P is in ascending order of the physical core numbers (in the order from P1 to P12). For example, to physical core n (where n is any of 1 to 12), logical core n-1 and logical core n+11 are allocated. When the allocation of logical cores L is insufficient for one physical core P, it is sequentially allocated from the logical cores L associated with the next physical core P. The allocation result is held in the storage unit 150 of FIG. 3.

[0134] For example, when there are two Pods (Pod_M) to be deployed in each of Pod-A and Pod-B, the logical cores L0, L12, L1, L13 corresponding to physical core numbers 1 and 2 are assigned to Pod-A1. The logical cores L2, L14, L3, L15 corresponding to physical core numbers 3 and 4 are assigned to Pod-A2. The logical cores L4, L16, L5, L17, L6, L18, L7, L19 corresponding to physical core numbers 5, 6, 7, and 8 are assigned to Pod-B1. The logical cores L8, L20, L9, L21, L10, L22, L11, L23 corresponding to physical core numbers 9, 10, 11, and 12 are assigned to Pod-B2.

[0135] As described above, also in this embodiment, the same effects as those of the above-described embodiment can be obtained. For example, even when a plurality of types of Pods are deployed, when the CPU 210 managed by the resource management device 100 is in a high-load state, the frequency of occurrence of migration can be reduced, and a decrease in the processing performance of the application can be suppressed.

[0136] Even when the CPU 210 performs frequency control according to the load, it is possible to suppress the switching of the operating frequency to the higher side during low load. Therefore, it is possible to suppress an increase in the power consumption of the CPU 210 due to an increase in the operating frequency in the low-load state. As a result, it is possible to suppress a decrease in the processing performance of the application during high load and an increase in the power consumption of the processor during low load.

[0137] Also, regardless of the number of logical cores L generated in the physical core P, the total number of logical cores L, and the number of Pod-A and Pod-B deployed, an appropriate number of logical cores L can be assigned to each of Pod-A and Pod-B using a common algorithm.

[0138] The features and advantages of the embodiments will become apparent from the above detailed description. It is intended that the claims cover the features and advantages of the embodiments as described above, without departing from the spirit and scope of the claims. Also, those skilled in the art should be able to readily conceive of any improvements and modifications. Therefore, it is not intended to limit the scope of the inventive embodiments to those described above, and it is also possible to rely on appropriate improvements and equivalents included in the scope disclosed in the embodiments.

Explanation of Signs

[0139] 10 Resource management device 11 Process number change unit 12 Core allocation unit 20 Processor 21 Core 30 System 31 Bus 100 Resource management device 110 Resource monitoring unit 120 Autoscale determination unit 132 Core allocation unit 130 Resource allocation unit 140 Storage unit 150 Storage unit 161 CPU 162 ROM 163 RAM 164 Communication interface unit 165 Input interface unit 166 Output interface unit 167 Input / output interface unit 168 Media interface unit 169 Bus 171 Input device 172 Output device 173 Input / output device 174 Recording medium 200 Physical server 210 CPU 300 System 310 Bus 400 terminal L logic core P physical core

Claims

1. A resource management device that assigns cores to a process executed by a processor including a plurality of cores, a process number changing unit that changes the number of deployments of the process executed by the processor according to a change in the load amount of the processor, a core allocation unit that decreases the number of cores assigned to each of the processes when the number of deployments increases according to the increase in the load amount, and increases the number of cores assigned to each of the processes when the number of deployments decreases according to the decrease in the load amount; A resource management device having the above.

2. The core is a plurality of logical cores included in each of a plurality of physical cores mounted on the processor, The core allocation unit allocates a plurality of the logical cores included in the physical core to one of the processes and does not allocate them to other processes. The resource management device according to Claim 1.

3. The processing performance of one of the processes is set to the maximum processing performance of a predetermined number of the logical cores, The process number changing unit changes the number of deployments of the process executed by the processor according to a change in the load amount of the processor, When the total number of logical cores allocable to the process is divisible by the required number of cores that is the number of logical cores capable of realizing the processing performance of the process with the changed number of deployments, the core allocation unit allocates to each of the processes a number of logical cores obtained by multiplying the quotient by the predetermined number. The resource management device according to Claim 2.

4. When the total number of the logical cores is not divisible by the required number of cores, the core allocation unit allocates to each of the processes a number of logical cores obtained by multiplying the quotient by the predetermined number, and further sequentially allocates the remainder to the processes by the predetermined number each. The resource management device according to Claim 3.

5. The processor is capable of executing a plurality of types of the processes, The required number of logical cores for each process is different for each of the plurality of types of processes, The process number changing unit changes the number of deployments of each of the plurality of types of processes executed by the processor according to a change in the load amount of the processor. When the total number of the logical cores that can be allocated to the plurality of types of the processes is divisible by the required number of cores which is the number of logical cores capable of realizing the processing performance of the plurality of types of the processes after the change, for each of the plurality of types of the processes, the logical cores in the number obtained by multiplying the quotient by the required number are allocated to each of the processes. The resource management device according to claim 2.

6. When the total number of the logical cores is not divisible by the required number of cores, for each of the plurality of types of the processes, the logical cores in the number obtained by multiplying the quotient by the required number are allocated to each of the processes, and further, the remainder is sequentially allocated to the processes by the minimum required number among the plurality of required numbers. The resource management device according to claim 5.

7. When the total number of the logical cores is not divisible by the required number of cores, the core allocation unit changes the allocation ratio of the remaining logical cores allocated to the plurality of types of the processes according to the weighting of the plurality of types of the processes. The resource management device according to claim 6.

8. A resource management method by a resource management device that allocates cores to processes executed by a processor including a plurality of cores, changing the number of deployments of the processes executed by the processor according to a change in the load amount of the processor, when the number of deployments increases according to an increase in the load amount, decreasing the number of cores allocated to each of the processes, when the number of deployments decreases according to a decrease in the load amount, increasing the number of cores allocated to each of the processes. Resource management method.

9. A resource management program executed by a resource management device that allocates cores to processes executed by a processor including a plurality of cores, changing the number of deployments of the processes executed by the processor according to a change in the load amount of the processor, when the number of deployments increases according to an increase in the load amount, decreasing the number of cores allocated to each of the processes, when the number of deployments decreases according to a decrease in the load amount, increasing the number of cores allocated to each of the processes. A resource management program for causing the resource management device to execute processing.

Images