Resource management program, resource management method, and resource management device

Abstract

To reduce the power consumed in a preliminary processor.SOLUTION: A management server classifies preliminary containers A1b-C1b such that, of the preliminary containers A1b-C1b, the preliminary containers used at the same timing are not classified into the same group. For example, the management server classifies the preliminary containers A1b-C1b such that the preliminary containers for the same service are not classified into the same group. The management server allocates resources to the preliminary containers in the groups G1-G3 in an overlapping manner so as to share the resources between the classified preliminary containers in the groups G1-G3. For example, the management server allocates one CPU and one GPU to the preliminary containers A1b, B1b in the group G1 in an overlapping manner so as to share the resources between the preliminary containers A1b, B1b in the group G1.SELECTED DRAWING: Figure 6

Description

Technical Field

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

Background Art

[0002] Conventionally, there is a disaggregated system that pools various ICT (Information and Communication Technology) resources across servers and dynamically allocates and uses resources according to applications. In this system, for example, when the performance of an application fails to meet requirements, resources are enhanced to ensure processing performance.

[0003] As a prior art, in a state where the system is operating, a physical CPU core occupied by a virtual CPU core of an active virtual machine is allocated, and a shared physical CPU core is allocated to a virtual CPU core of a standby virtual machine. Further, there is a technique in which the state of the VM is pre-transitioned to a standby state between the stopped state and the startup state, and when a processing request is received from a user, the state of the processing unit is transitioned from the standby state to the startup state using the specific setting information of the user and information regarding the state of the processing unit in the standby state.

Prior Art Documents

Patent Documents

[0004]

Patent Document 1

Patent Document 2

Summary of the Invention

Problems to be Solved by the Invention

[0005] However, conventional technologies have a problem in that, in order to shorten the time required to increase resources, backup containers for running applications are prepared in advance, but the standby power of the ICT resources allocated to these backup containers increases power consumption.

[0006] In one aspect, the present invention aims to reduce the power consumption of the pre-processing device. [Means for solving the problem]

[0007] In one embodiment, a resource management program is provided that, based on information representing the characteristics of each of the multiple processing units involved in providing one or more services, classifies the backup backup processing units corresponding to each of the multiple processing units so that backup processing units used at the same time do not belong to the same group, and allocates resources redundantly to the backup processing units within the classified groups so that resources are shared among the backup processing units within the groups. [Effects of the Invention]

[0008] According to one aspect of the present invention, it has the effect of reducing the power consumption of the pre-treatment device. [Brief explanation of the drawing]

[0009] [Figure 1] Figure 1 is an explanatory diagram showing one embodiment of the resource management method according to the embodiment. [Figure 2] Figure 2 is an explanatory diagram showing an example of the system configuration of the information processing system 200. [Figure 3] Figure 3 is a block diagram showing an example of the hardware configuration of the management server 201. [Figure 4] Figure 4 is an explanatory diagram showing an example of a service in operation. [Figure 5] Figure 5 is a block diagram showing an example of the functional configuration of the management server 201. [Figure 6]FIG. 6 is an explanatory diagram showing an operation example of the management server 201. [Figure 7] FIG. 7 is a flowchart showing an example of a resource management processing procedure of the management server 201. [Figure 8] FIG. 8 is an explanatory diagram showing a comparison example of the addition speed of containers. [Figure 9] FIG. 9 is an explanatory diagram showing a comparison example of the number of secured ICT resources. [Figure 10] FIG. 10 is an explanatory diagram showing a comparison example of power consumption. [Figure 11] FIG. 11 is an explanatory diagram showing an example of a service to be deployed. [Figure 12] FIG. 12 is an explanatory diagram (part 1) showing a specific example of application performance / resource information. [Figure 13] FIG. 13 is an explanatory diagram showing a specific example of the service configuration information 1300. [Figure 14] FIG. 14 is an explanatory diagram showing a transition example of the stored content of the resource allocation status information 1400. [Figure 15A] FIG. 15A is an explanatory diagram (part 1) showing a transition example of the stored content of the container management information 1500. [Figure 15B] FIG. 15B is an explanatory diagram (part 2) showing a transition example of the stored content of the container management information 1500. [Figure 15C] FIG. 15C is an explanatory diagram (part 3) showing a transition example of the stored content of the container management information 1500. [Figure 16] FIG. 16 is an explanatory diagram (part 1) showing the usage state of the resources according to Example 1. [Figure 17] FIG. 17 is an explanatory diagram (part 2) showing the usage state of the resources according to Example 1. [Figure 18] FIG. 18 is an explanatory diagram (part 3) showing the usage state of the resources according to Example 1. [Figure 19] FIG. 19 is an explanatory diagram showing a first classification example of spare containers. [Figure 20] FIG. 20 is an explanatory diagram showing an example of a container configuration and a spare container configuration. [Figure 21] Figure 21 is a flowchart showing an example of the specific processing procedure of the resource management process of the management server 201. [Figure 22] Figure 22 is a flowchart showing an example of the specific processing procedure of the preliminary container configuration determination process. [Figure 23] Figure 23 is a flowchart showing an example of the specific processing procedure of the first grouping process. [Figure 24] Figure 24 is a flowchart showing an example of the resource enhancement processing procedure of the management server 201. [Figure 25] Figure 25 is an explanatory diagram showing a specific example of the service configuration information 2500. [Figure 26] Figure 26 is an explanatory diagram showing a transition example of the stored content of the container management information 2600. [Figure 27A] Figure 27A is an explanatory diagram (part 1) showing a second classification example of the preliminary container. [Figure 27B] Figure 27B is an explanatory diagram (part 2) showing a second classification example of the preliminary container. [Figure 28] Figure 28 is an explanatory diagram showing the usage state of resources according to Example 2. [Figure 29] Figure 29 is a flowchart showing an example of the specific processing procedure of the second grouping process. [Figure 30] Figure 30 is an explanatory diagram showing a specific example of the service configuration information 3000. [Figure 31] Figure 31 is an explanatory diagram (part 2) showing a specific example of the application performance / resource information. [Figure 32] Figure 32 is an explanatory diagram showing a transition example of the stored content of the container management information 3200. [Figure 33] Figure 33 is an explanatory diagram showing a third classification example of the preliminary container. [Figure 34] Figure 34 is an explanatory diagram showing the usage state of resources according to Example 3. [Figure 35] Figure 35 is a flowchart showing an example of the specific processing procedure of the third grouping process. [Figure 36] Figure 36 is an explanatory diagram showing a specific example of resource limit information 3600. [Figure 37] Figure 37 is an explanatory diagram showing an example of the changes in the stored contents of the container management information 3700. [Figure 38] Figure 38 is an explanatory diagram showing a fourth classification example of the spare containers. [Figure 39] Figure 39 is an explanatory diagram showing the resource usage status according to Example 4. [Figure 40] Figure 40 is a flowchart (part 1) showing an example of the specific processing steps for the fourth grouping process. [Figure 41] Figure 41 is a flowchart (part 2) showing an example of the specific processing steps for the fourth grouping process. [Modes for carrying out the invention]

[0010] Embodiments of the resource management program, resource management method, and resource management device according to the present invention will be described in detail below with reference to the drawings.

[0011] (Embodiment) Figure 1 is an explanatory diagram showing one embodiment of the resource management method according to the embodiment. In Figure 1, the resource management device 101 is a computer that manages resources to be allocated to backup processing devices corresponding to each of the multiple processing devices for providing one or more services. The services are provided by one or more applications.

[0012] A processing unit runs applications to provide services. These processing units are, for example, containers or virtual machines. A container is created by internally partitioning the OS (Operating System) kernel, representing an isolated user space, and operates as one of the OS processes.

[0013] A virtual machine is a virtual computer that operates in an execution environment built by dividing the hardware resources of a physical computer. The processing unit may be a physical server. A backup processing unit is a processing unit that is added to the service, for example, when resources are increased in response to performance shortages.

[0014] Resources include ICT resources such as CPU (Central Processing Unit), memory, storage, and accelerators. Accelerators include, for example, GPU (Graphics Processing Unit), FPGA (Field Programmable Gate Array), and smart NIC (Network Interface Card).

[0015] In a disaggregated system, for example, if a service's performance falls below the requirements, resources are increased to ensure processing performance. For instance, if the traffic or load on a service exceeds a threshold, new containers or virtual machines (VMs) are added to the service.

[0016] On the other hand, when increasing resources, if new containers are created each time, the process of adding containers takes time. For example, adding a container to a disaggregated system requires powering on the ICT resources and configuring the connection to the container (for example, linking the container to the ICT resources), which takes time.

[0017] Therefore, in order to shorten the time required to increase resources, one approach is to prepare backup containers in advance to run the applications that provide the service. For example, when deploying containers for service provision, it is possible to secure ICT resources for backup containers in advance to match the service, power them on, and configure the connections, so that when additional containers are needed, the backup containers that were prepared in advance can be added to the service.

[0018] However, this method has a problem in that standby power is generated for ICT resources allocated to backup containers, etc., increasing the power consumption of the backup containers, etc. For example, if one ICT resource is allocated to each of 10 backup containers, 10 ICT resources will be kept on standby. Also, the probability of all backup containers being used at the same time is low, so it is not efficient to power on all ICT resources and keep them on standby.

[0019] Therefore, in this embodiment, a resource management method is described that reduces the amount of power consumed by spare containers, etc., by reducing the number of resources that are powered on and prepared in advance. Here, an example of processing by the resource management device 101 is described.

[0020] In the example in Figure 1, the services currently in operation are designated as "Services A, B, and C". The processing units responsible for providing Service A are designated as "Processing Units A1a, A2a, and A3a". The processing units responsible for providing Service B are designated as "Processing Units B1a and B2a". The processing unit responsible for providing Service C is designated as "Processing Unit C1a".

[0021] Furthermore, the resources used by processing unit A1a are set to "CPU:1, GPU:1". Note that "CPU:1" refers to one CPU, and "GPU:1" refers to one GPU. The resources used by processing unit A2a are set to "CPU:1". The resources used by processing unit A3a are set to "CPU:2". The resources used by processing unit B1a are set to "CPU:1, GPU:1". The resources used by processing unit B2a are set to "CPU:1". The resources used by processing unit C1a are set to "CPU:2".

[0022] Furthermore, we assume the case where "pre-processing devices A1b, A2b, A3b, B1b, B2b, C1b" are generated as backup pre-processing devices corresponding to processing devices A1a, A2a, A3a, B1a, B2a, C1a for providing services A, B, and C.

[0023] In this case, the resource management device 101 classifies the spare spare processing devices A1b to C1b based on the characteristic information 110 such that spare spare processing devices used at the same time do not belong to the same group.

[0024] Here, the feature information 110 represents the characteristics of each of the processing units A1a to C1a involved in the provision of services A, B, and C. For example, the feature information 110 indicates which of services A, B, and C each of the processing units A1a to C1a is involved in providing.

[0025] When a particular service becomes highly popular, it is highly likely that resource enhancement will be required for all containers (processing units) involved in providing that service. For this reason, the resource management device 101 may, for example, classify the backup processing units A1b to C1b based on characteristic information 110, such that backup processing units corresponding to the same processing unit providing the same service do not belong to the same group.

[0026] In the example in Figure 1, processing units A1a, A2a, and A3a are processing units for providing service A. The backup processing units corresponding to processing units A1a, A2a, and A3a for providing service A are backup processing units A1b, A2b, and A3b. Also, processing units B1a and B2a are processing units for providing service B. The backup processing units corresponding to processing units B1a and B2a for providing service B are backup processing units B1b and B2b. Furthermore, processing unit C1a is a processing unit for providing service C. The backup processing unit corresponding to processing unit C1a for providing service C is backup processing unit C1b.

[0027] Therefore, based on the characteristic information 110, the resource management device 101 classifies the backup processing units A1b, A2b, and A3b that correspond to the processing units A1a, A2a, and A3a that provide service A, so that they do not belong to the same group. Furthermore, based on the characteristic information 110, the resource management device 101 classifies the backup processing units A1b, B2b, and A3b that correspond to the processing units B1a and B2a that provide service B, so that they do not belong to the same group.

[0028] Here, we assume that among the backup processing units A1b to C1b, processing units A1b and B1b are classified into group G1, processing units A2b and B2b are classified into group G2, and processing units A3b and C1b are classified into group G3.

[0029] Next, the resource management device 101 allocates resources redundantly to the pre-processors within the classified groups G1 to G3 so that resources are shared among them. Here, each pre-processor A1b to C1b is allocated the same amount of resources as those used by each pre-processor A1a to C1a.

[0030] For example, the auxiliary processing unit A1b is allocated the same amount of resources as processing unit A1a: "CPU: 1, GPU: 1". The auxiliary processing unit B1b is allocated the same amount of resources as processing unit B1a: "CPU: 1, GPU: 1". In this case, the auxiliary processing units A1b and B1b within group G1 are allocated resources so that they share the same resources with each other. In group G1, auxiliary processing units A1b and B1b share one CPU. Also, in group G1, auxiliary processing units A1b and B1b share one GPU.

[0031] Furthermore, the backup processor A2b is allocated the same amount of resources ("CPU:1") as processor A2a. The backup processor B2b is allocated the same amount of resources ("CPU:1") as processor B2a. In this case, the backup processors A2b and B2b within group G2 are allocated resources so that they share the same resources among themselves. In group G2, one CPU is shared between backup processors A2b and B2b.

[0032] Furthermore, the backup processor A3b is allocated the same amount of resources ("CPU:2") as processor A3a. The backup processor C1b is allocated the same amount of resources ("CPU:2") as processor C1a. In this case, the backup processors A3b and C1b within group G3 are allocated resources so that they share the same resources among themselves. In group G3, two CPUs are shared between backup processors A3b and C1b.

[0033] Thus, the resource management device 101 can group backup processing units so that those likely to be used at the same time use different resources (ICT resources). In other words, the resource management device 101 can group backup processing units that are unlikely to be used at the same time together, so that they share the same resources. This allows the resource management device 101 to quickly increase resources when the current configuration cannot meet performance requirements, and also reduces power consumption by minimizing the number of resources that need to be powered on in advance.

[0034] In the example shown in Figure 1, the resource management device 101 can limit the number of resources allocated to four CPUs and one GPU. On the other hand, if resources are not shared among the backup processing units and resources are allocated to each backup processing unit, eight CPUs and two GPUs would be required. Therefore, the resource management device 101 can reduce the power consumption by the equivalent of four CPUs and one GPU compared to the case where resources are allocated to each backup processing unit. In addition, backup processing units classified in the same group are unlikely to be needed at the same time, making resource contention less likely among additional containers. Therefore, the resource management device 101 can quickly increase resources when the current configuration cannot meet performance requirements.

[0035] (Example of system configuration for information processing system 200) Next, we will describe an example of the system configuration of the information processing system 200, which includes the resource management device 101 shown in Figure 1. Here, we will explain using the example of applying the resource management device 101 shown in Figure 1 to the management server 201 within the information processing system 200. The information processing system 200 is applied, for example, to a disaggregated system.

[0036] In the following explanation, we will use "containers" as an example of processing equipment used in providing services. We will also use "backup containers" as an example of backup processing equipment.

[0037] Figure 2 is an explanatory diagram showing an example of the system configuration of the information processing system 200. In Figure 2, the information processing system 200 includes a management server 201, multiple operation servers 202, and a container management device 203. In the information processing system 200, the management server 201, operation servers 202, and container management device 203 are connected via a wired or wireless network 210. The network 210 is, for example, the Internet, a LAN (Local Area Network), or a WAN (Wide Area Network).

[0038] Here, the management server 201 is a computer that manages the resources to be allocated to backup containers corresponding to each of the multiple containers providing one or more services. The containers and backup containers are run, for example, by the operation server 202. The resources allocated to the containers and backup containers are provided, for example, by the operation server 202.

[0039] The operational server 202 is a computer capable of running containers (including backup containers). The operational server 202 may also be capable of running virtual machines (including backup virtual machines). Furthermore, the operational server 202 may be a computer that provides resources (ICT resources) to be allocated to containers via the network 210.

[0040] The container management device 203 is a computer that manages containers (including backup containers). For example, the container management device 203 deploys containers and backup containers on the operation server 202 according to the control of the management server 201.

[0041] In this example, the management server 201 and the container management device 203 are provided as separate entities, but this is not the only option. For example, the container management device 203 may be implemented by the management server 201. Alternatively, the container management device 203 may be implemented by one of the operation servers 202 among the multiple operation servers 202.

[0042] (Example hardware configuration for management server 201) Next, we will describe an example of the hardware configuration for management server 201.

[0043] Figure 3 is a block diagram showing an example of the hardware configuration of the management server 201. In Figure 3, the management server 201 includes a CPU 301, memory 302, disk drive 303, disk 304, communication interface 305, portable recording medium interface 306, and portable recording medium 307. Each component is connected by a bus 300.

[0044] Here, the CPU 301 is responsible for the overall control of the management server 201. The CPU 301 may have multiple cores. The memory 302 includes, for example, ROM (Read Only Memory), RAM (Random Access Memory), and flash ROM. Specifically, for example, the flash ROM stores the OS program, the ROM stores the application program, and the RAM is used as the work area for the CPU 301. Programs stored in memory 302 are loaded into the CPU 301, causing the CPU 301 to execute the coded processes.

[0045] The disk drive 303 controls the reading and writing of data to the disk 304 according to the control of the CPU 301. The disk 304 stores the data written under the control of the disk drive 303. Examples of disks 304 include magnetic disks and optical disks.

[0046] The communication interface 305 is connected to the network 210 via a communication line, and through the network 210, it is connected to an external computer (for example, the operation server 202 and container management device 203 shown in Figure 2). The communication interface 305 manages the interface between the network 210 and the inside of the device, and controls the input and output of data from the external computer. The communication interface 305 can be, for example, a modem or a LAN adapter.

[0047] The portable recording medium interface 306 controls the reading and writing of data to the portable recording medium 307 according to the control of the CPU 301. The portable recording medium 307 stores the data written under the control of the portable recording medium interface 306. Examples of portable recording media 307 include CD (Compact Disc)-ROM, DVD (Digital Versatile Disk), and USB (Universal Serial Bus) memory.

[0048] Furthermore, the management server 201 may have, in addition to the components described above, an input device, a display, etc. Also, the management server 201 does not have to have, for example, the portable recording medium I / F 306 and the portable recording medium 307 among the components described above. In addition, the operation server 202 and the container management device 203 shown in Figure 2 can be realized with the same hardware configuration as the management server 201. However, the operation server 202 has, in addition to the components described above, various ICT resources (GPU, FPGA, etc.) that can be allocated to containers, etc.

[0049] (An example of a service) Next, using Figure 4, we will explain the services provided in the information processing system 200 (see Figure 2). Here, the resources that can be allocated to a container (including spare containers) are referred to as "CPU" and "GPU". The CPUs that can be allocated to a container (including spare containers) are referred to as "CPU1 to CPU16", and the GPUs that can be allocated to a container (including spare containers) are referred to as "GPU1 to GPU10". Note that the "#" in CPU# is a number (identifier) ​​that uniquely identifies the CPU. The "#" in GPU# is an identifier that uniquely identifies the GPU.

[0050] Figure 4 is an explanatory diagram showing an example of a service in operation. In Figure 4, services A, B, and C are examples of services in operation. Service A is a three-tiered service that includes applications A1, A2, and A3. In Figure 4, A1a represents the container that runs application A1. A2a represents the container that runs application A2. A3a represents the container that runs application A3.

[0051] Containers A1a, A2a, and A3a are containers that provide service A. Here, the resources required to run application A1 are "CPU: 1, GPU: 1". Container A1a is allocated CPU1 and GPU1. The resources required to run application A2 are "CPU: 1". Container A2a is allocated CPU2. The resources required to run application A3 are "CPU: 2". Container A3a is allocated CPU3 and CPU4.

[0052] Service B is a two-tiered service that includes applications B1 and B2. In Figure 4, B1a represents the container that runs application B1. B2a represents the container that runs application B2. Containers B1a and B2a are the containers that provide Service B. Here, the resources required to run application B1 are "CPU: 1, GPU: 1". Container B1a is allocated CPU 5 and GPU 2. Also, the resources required to run application B2 are "CPU: 1". Container B2a is allocated CPU 6.

[0053] Service C is a single-tier service that includes application C1. In Figure 4, C1a represents the container that runs application C1. Container C1a is the container responsible for providing service C. Here, the resources required to run application C1 are "CPU: 2". Container C1a is allocated CPU7 and CPU8.

[0054] (Example of functional configuration for management server 201) Next, we will describe an example of the functional configuration of the management server 201.

[0055] Figure 5 is a block diagram showing an example of the functional configuration of the management server 201. In Figure 5, the management server 201 includes a reception unit 501, a first calculation unit 502, a power management unit 503, a deployment unit 504, a second calculation unit 505, and a load monitoring unit 506. The reception unit 501 to the load monitoring unit 506 function as a control unit 500, and specifically, they realize their functions by having the CPU 301 execute a program stored in a storage device such as the memory 302, disk 304, or portable recording medium 307 shown in Figure 3, or by using a communication interface 305. The processing results of each functional unit are stored in a storage device such as the memory 302 or disk 304.

[0056] The reception unit 501 receives the performance requirements for the service. A service is a one- or multi-tiered service provided by one or more applications. For example, service A shown in Figure 4 is a three-tiered service provided by applications A1 to A3. The performance requirements represent the performance required to provide the service. The performance requirements are expressed, for example, by the performance requirements of each application in each tier that provides the service.

[0057] Specifically, for example, the reception unit 501 receives performance requests related to the service by receiving them from a client terminal (not shown). The client terminal is a computer used by a user of the service provider. Alternatively, the reception unit 501 may also receive performance requests related to the service through user input using an input device (not shown).

[0058] The first calculation unit 502 calculates the container configuration for providing the service. Here, the container configuration represents the containers for providing the service. The container configuration shows, for example, the containers at each stage necessary to provide the service. Each container at each stage executes the application at that stage.

[0059] Specifically, for example, the first calculation unit 502 calculates the container configuration for providing the service based on the requested performance and application performance / resource information for the received service. The application performance / resource information indicates the performance and required resources for each application to provide the service. The required resources are the amount of resources needed to run the application.

[0060] For example, let's say the service is a facial recognition service that analyzes camera footage to recognize faces. In this case, the applications needed to provide the service would include, for example, an application for compressing data (images), an application for performing AI (Artificial Intelligence) analysis, and an application for visualization.

[0061] Application performance / resource information may be obtained, for example, from a client terminal (not shown), or from user input using an input device (not shown). Specific examples of application performance / resource information will be described later, for example, using Figure 12. The calculated container configuration is stored in service configuration information 1300, for example, as shown in Figure 13, described later.

[0062] Furthermore, the first calculation unit 502 allocates resources to the containers providing the service. These resources are, for example, ICT resources such as CPU, memory, storage, and accelerators. Specifically, for example, the first calculation unit 502 refers to resource allocation status information and allocates available resources to each container in the calculated container configuration.

[0063] Here, resource allocation information is information that identifies the allocation status of each resource that can be allocated to a container (including spare containers). The amount of resources to allocate to a container (required resources) is determined, for example, from application performance / resource information. For example, the required resources for container A1a providing service A shown in Figure 4 are "CPU: 1, GPU: 1".

[0064] The contents of the stored resource allocation status information will be described later, for example, using Figure 14. The resource allocation results for each container are stored in the container management information 1500, for example, as shown in Figure 15A later.

[0065] The power management unit 503 powers on the resources assigned to the containers. Resources that can be assigned to containers (including spare containers) are powered off when unassigned, for example, to reduce power consumption. Specifically, for example, the power management unit 503 sends a power-on instruction to the operation server 202 that has resources assigned to the containers.

[0066] As a result, power is turned on to the resources allocated to the containers on the operational server 202. Power-on instructions are given, for example, by sending a command to the operational server 202 or by calling the API (Application Programming Interface) of the PCIe (Peripheral Component Interconnect Express) switch.

[0067] The deployment unit 504 deploys the containers for providing the service. Specifically, for example, the deployment unit 504 requests the container management device 203 shown in Figure 2 to configure the connection settings for the resources assigned to each container and to deploy (start) each container. At this time, the deployment unit 504 may also configure settings such as traffic distribution.

[0068] Requests to the container management device 203 are made, for example, by calling the API of existing container management software. As a result, the containers responsible for providing the service are started. Once the containers are deployed, the container management information 1500 is updated, for example, as shown in Figure 15A below.

[0069] For example, when containers A1a, A2a, and A3a, which provide service A as shown in Figure 4, are started, service A begins operation. Similarly, when containers B1a and B2a, which provide service B, are started, service B begins operation. And when container C1a, which provides service C, is started, service C begins operation.

[0070] The second calculation unit 505 calculates a backup container configuration for service provision based on the calculated container configuration. Here, the backup container configuration represents the backup containers corresponding to the containers for service provision. The backup container configuration shows, for example, the backup containers for each stage that are prepared (generated) when providing the service. Each backup container runs the application for each stage.

[0071] Specifically, for example, the second calculation unit 505 refers to the calculated container configuration and calculates a backup container configuration that includes backup containers with the same performance as the containers running the applications at each stage of the service. The number of backup containers at each stage is, for example, one. However, the number of backup containers at each stage may be the same as the number of containers at each stage.

[0072] The calculated backup container configuration is stored, for example, in container management information 1500.

[0073] Furthermore, the second calculation unit 505 classifies the spare spare containers corresponding to each of the multiple containers so that spare containers used at the same time do not belong to the same group. Here, the multiple containers are multiple containers related to the provision of one or more services. One or more services are, for example, services A, B, and C shown in Figure 4.

[0074] Specifically, for example, the second calculation unit 505 classifies spare containers based on feature information representing the characteristics of each of the multiple containers. Here, the feature information is, for example, information indicating which of the one or more services each of the multiple containers is related to. The feature information may be obtained, for example, from a client terminal (not shown), or from user input using an input device (not shown).

[0075] For example, when a particular service experiences a surge in popularity, it is highly likely that resource enhancements will be required for all containers involved in providing that service. Therefore, the second calculation unit 505, taking the service configuration into consideration, classifies the spare containers that are relatively likely to be used at the same time into different groups.

[0076] To explain in more detail, for example, the second calculation unit 505 classifies the spare spare containers based on characteristic information so that spare containers corresponding to containers providing the same service do not belong to the same group (corresponding to Embodiment 1 described later).

[0077] Furthermore, the characteristic information may also be information representing the load status of each of the multiple containers. The load status of a container may be represented, for example, by the data transfer rate (Mbps). For example, a container with insufficient processing performance is likely to require resource enhancement soon. For this reason, the second calculation unit 505 classifies spare containers that are likely to be used at the same time into different groups, taking into account the processing performance margin of the containers.

[0078] To explain in more detail, for example, the second calculation unit 505 may classify the spare spare containers based on characteristic information such that spare containers corresponding to containers whose processing performance margin is below a threshold do not belong to the same group (corresponding to Embodiment 2 described later). The processing performance margin is represented, for example, by the difference between the application's performance and the current load (load state). The current load is identified, for example, from performance requirements or measured values. The threshold can be set arbitrarily.

[0079] Furthermore, the second calculation unit 505 may classify the spare spare containers based on characteristic information such that spare spare containers corresponding to containers with a relatively low margin of processing performance relative to the performance requirements do not belong to the same group. Containers with a relatively low margin are, for example, a predetermined number of containers from among several containers, starting with the lowest margin. The predetermined number can be set arbitrarily.

[0080] Furthermore, the characteristic information may also be information representing the demand trends of the services corresponding to each of the multiple containers. For example, services with similar demand trends are likely to have overlapping peaks and therefore likely to require resource enhancement at the same time. For this reason, the second calculation unit 505 considers the demand trends of the services and classifies spare containers that are likely to be used at the same time into different groups.

[0081] More specifically, the second calculation unit 505 may, for example, classify the spare spare containers based on characteristic information such that spare spare containers corresponding to containers providing services with the same demand trend do not form the same group (corresponding to Embodiment 3 described later). The demand trend for a service may be determined, for example, from the content of the service.

[0082] For example, if services A and B are online games, both tend to experience increased load at night. In this case, the second calculation unit 505 may, for example, separate the groups of spare containers for service A and service B. Alternatively, if service C is an enterprise system and service D is a video distribution system, service C tends to experience high load during the day, while service D tends to experience high load at night. In this case, the second calculation unit 505 may, for example, group the spare containers for service C and service D together.

[0083] Furthermore, from the perspective of power consumption and cost, it may be desirable to limit the amount of resources allocated to backup containers. In this case, the second calculation unit 505 may classify backup containers based on resource limit information and characteristic information. Resource limit information is information that represents the upper limit of the amount of resources that can be allocated to backup containers. Resource limit information may be obtained, for example, from a client terminal (not shown), or from user input using an input device (not shown).

[0084] Specifically, for example, the second calculation unit 505 may classify the spare spare containers so that the amount of resources allocated to the spare spare containers does not exceed the upper limit, and so that spare spare containers used at the same time do not belong to the same group (corresponding to Embodiment 4 described later).

[0085] More specifically, the second calculation unit 505 may classify the backup backup containers so as not to exceed the upper limit in terms of the amount of resources allocated to the backup backup containers, and so as not to group backup backup containers that correspond to containers providing the same service together.

[0086] Furthermore, the second calculation unit 505 may classify the backup backup containers so as not to exceed the upper limit in terms of the amount of resources allocated to the backup backup containers, and so as not to group together backup backup containers that correspond to containers whose processing performance margin is below a threshold.

[0087] Furthermore, the second calculation unit 505 may classify the spare spare containers so as not to exceed the upper limit in terms of the amount of resources allocated to the spare spare containers, and so as not to group together spare spare containers that correspond to containers providing services with the same demand trend.

[0088] Furthermore, the second calculation unit 505 allocates resources redundantly to the spare containers within the classified group so that resources are shared among the spare containers within the group. The amount of resources (required resources) allocated to the spare containers is, for example, the same as the container corresponding to the spare container.

[0089] Specifically, for example, the second calculation unit 505 calculates the required resource amount for each group from the amount of resources (required resources) to be allocated to the spare containers within the classified group. The required resource amount for a group is the amount of resources required to allocate resources redundantly to the spare containers within the group.

[0090] The second calculation unit 505 then allocates resources to the spare containers within a group, overlapping resources, based on the calculated required resource amount for each group, so that resources are shared among the spare containers within the group. In this process, the second calculation unit 505 allocates available resources to the spare containers within a group, for example, by referring to resource allocation status information. Any existing technology may be used as the method for sharing resources among spare containers.

[0091] The power management unit 503 powers on the resources allocated to the backup container. Specifically, for example, the power management unit 503 sends a power-on instruction to the operation server 202, which has the resources allocated to the backup container. As a result, the operation server 202 powers on the resources allocated to the backup container.

[0092] The deployment unit 504 deploys backup containers corresponding to the containers used to provide the service. Specifically, for example, the deployment unit 504 requests the container management device 203 to configure the connection settings for the resources assigned to each backup container and to deploy (start) each backup container. At this time, the deployment unit 504 may also configure settings such as traffic distribution.

[0093] As a result, a backup container corresponding to the container providing the service is started. When the backup container is deployed, for example, container management information 1500 is updated.

[0094] Furthermore, the power management unit 503 may set the power supply of resources other than those already allocated to the container (including spare containers) to a power saving mode. A power saving mode is a mode in which resources are placed in a low-power or low-performance state in order to reduce power consumption.

[0095] Specifically, for example, the power management unit 503 sends a power mode change instruction to the operational server 202, which has resources other than those already allocated. The power mode change instruction instructs the system to set the power mode of resources other than those already allocated to power saving mode.

[0096] As a result, resources other than those already allocated are set to power-saving mode on the operational server 202. This allows the power management unit 503 to shorten the time it takes to transition to the normal state when powering on resources allocated to containers (including spare containers) compared to the case of a power outage.

[0097] The load monitoring unit 506 monitors the load on the containers providing the service and determines whether or not to increase the resources. Specifically, for example, the load monitoring unit 506 may decide to increase the resources for a container if the amount of traffic to that container exceeds a predetermined amount. The predetermined amount can be set arbitrarily.

[0098] The first calculation unit 502, when it determines that resources should be increased for the containers providing the service, identifies a spare container to be added to the service from among the spare containers. The first calculation unit 502 then adds the identified spare container to the service. The first calculation unit 502 also updates the container configuration so that the added spare container occupies the resources shared with other spare containers in the same group.

[0099] The power management unit 503 turns off the power to resources allocated only to other spare containers in the same group as the added spare container. Specifically, for example, the power management unit 503 sends a power-off instruction to the operation server 202, which has resources allocated only to other spare containers. As a result, the power to resources allocated only to other spare containers is turned off on the operation server 202.

[0100] Furthermore, the functional units of the management server 201 described above (reception unit 501 to load monitoring unit 506) may be implemented by multiple computers within the information processing system 200 (for example, the management server 201 and the container management device 203).

[0101] (Example of operation of management server 201) Using Figure 6, we will explain an example of the operation of the management server 201 when generating backup containers corresponding to the containers used to provide a service. Here, we will use services A, B, and C shown in Figure 4 as examples of services.

[0102] Figure 6 is an explanatory diagram showing an example of the operation of the management server 201. In Figure 6, the second calculation unit 505 calculates the spare container configuration for providing each service A, B, and C based on the container configuration for providing each service A, B, and C.

[0103] Here, the second calculation unit 505 generates backup containers A1b, A2b, A3b, B1b, B2b, and C1b, which correspond to the containers A1a, A2a, A3a, B1a, B2a, and C1a (see Figure 4) for providing each of the services A, B, and C.

[0104] Next, the second calculation unit 505 classifies the spare containers A1b to C1b so that spare containers used at the same time do not belong to the same group. Specifically, for example, the second calculation unit 505 classifies the spare containers A1b to C1b so that spare containers for the same service do not belong to the same group.

[0105] Here, spare containers A1b and B1b are classified into group G1, spare containers A2b and B2b into group G2, and spare containers A3b and C1b into group G3.

[0106] This allows the second calculation unit 505 to group spare containers for the same service that are likely to have overlapping resource enhancement timings. For example, spare containers A1b, A2b, and A3b for service A are classified into different groups. Also, spare containers B1b and B2b for service A are classified into different groups.

[0107] The second calculation unit 505 then allocates resources redundantly to the spare containers within the classified groups G1 to G3 so that resources are shared among the spare containers within those groups. The amount of resources (required resources) allocated to each spare container A1b to C1b is, for example, the same as the corresponding containers A1a to C1a for each spare container A1b to C1b.

[0108] For example, the second calculation unit 505 allocates one CPU and one GPU to the spare containers A1b and B1b in group G1 so that they are shared between the spare containers A1b and B1b in group G1. The second calculation unit 505 also allocates one CPU to the spare containers A2b and B2b in group G2 so that they are shared between the spare containers A2b and B2b in group G2. The second calculation unit 505 also allocates two CPUs to the spare containers A3b and C1b in group G3 so that they are shared between the spare containers A3b and C1b in group G3.

[0109] In this way, the management server 201 can group spare containers so that spare containers that are likely to be used at the same time use different ICT resources. This allows the management server 201 to reduce the number of ICT resources that need to be powered on in advance and thus reduce power consumption.

[0110] (Resource management processing procedure for management server 201) Next, the resource management processing procedure of the management server 201 will be described. The resource management processing of the management server 201 is performed, for example, when generating backup containers corresponding to each of the multiple containers involved in providing one or more services.

[0111] Figure 7 is a flowchart showing an example of the resource management processing procedure of the management server 201. In Figure 7, the management server 201 calculates a backup container configuration for providing one or more services based on the container configuration for providing one or more services (step S701).

[0112] Next, the management server 201 classifies the backup containers based on the calculated backup container configuration so that backup containers used at the same time do not belong to the same group (step S702). The backup containers are backup containers corresponding to each of the multiple containers involved in providing one or more services.

[0113] Then, the management server 201 calculates the required resources for each group from the amount of resources to be allocated to the spare containers within the classified group (required resources) (step S703). Next, based on the calculated required resources for each group, the management server 201 allocates resources redundantly to the spare containers within the group so that resources are shared among the spare containers within the group (step S704). Then, the management server 201 completes the series of processes according to this flowchart.

[0114] This allows the management server 201 to group spare containers so that spare containers that are likely to be used at the same time use different resources.

[0115] (Comparison example of container addition speed, number of ICT resources allocated, and power consumption) Next, using Figures 8 to 10, we will explain a comparison of container addition speed, number of ICT resources allocated, and power consumption for each method. Here, Method 1 is a method that starts, connects, and adds containers and ICT resources when resource enhancement is needed. Method 2 is a method that prepares spare containers and ICT resources corresponding to each container in advance, and adds containers when resource enhancement is needed. This method corresponds to the resource management method described here.

[0116] Figure 8 is an explanatory diagram illustrating a comparison of container addition speeds. In Figure 8, graphs 801 to 803 represent the length of time required for adding containers to provide the service in response to resource enhancement requests, depending on the method used. In Figure 8, "Power On" indicates the time required to power on the ICT resource. "Connection" indicates the time required to configure the connection of the ICT resource. "Startup" indicates the time required to start up the container. "Add" indicates the time required to add the container.

[0117] Graphs 801-803 show that this method reduces the time required to add containers compared to other method 1.

[0118] Figure 9 is an explanatory diagram showing a comparison of the number of ICT resources allocated. In Figure 9, graphs 901 to 903 represent the number of ICT resources allocated before container addition (vertical: number of ICT resources allocated, horizontal: method). Graphs 904 to 906 represent the number of ICT resources allocated after container addition (vertical: number of ICT resources allocated, horizontal: method).

[0119] In Figure 9, A1 indicates the number of ICT resources used to run application A1 (see Figure 4). A2 indicates the number of ICT resources used to run application A2 (see Figure 4). A3 indicates the number of ICT resources used to run application A3 (see Figure 4). B1 indicates the number of ICT resources used to run application B1 (see Figure 4). B2 indicates the number of ICT resources used to run application B2 (see Figure 4). C1 indicates the number of ICT resources used to run application C1 (see Figure 4). Reserve indicates the number of ICT resources used for the reserve container.

[0120] According to graphs 901-906, this method reduces the number of ICT resources by 5 (25%: 10 for service + 10 for backup → 10 for service + 5 for backup) compared to other method 2.

[0121] Figure 10 is an explanatory diagram showing a comparative example of power consumption. In Figure 10, graphs 1001 to 1003 represent the power consumption before adding a container (vertical: magnitude of power consumption, horizontal: method). Graphs 1004 to 1006 represent the power consumption after adding a container (vertical: magnitude of power consumption, horizontal: method). After the addition, power consumption increases because one spare container is brought from spare to operational mode.

[0122] In Figure 10, A1 represents the power consumption incurred during the execution of application A1 (see Figure 4). A2 represents the power consumption incurred during the execution of application A2 (see Figure 4). A3 represents the power consumption incurred during the execution of application A3 (see Figure 4). B1 represents the power consumption incurred during the execution of application B1 (see Figure 4). B2 represents the power consumption incurred during the execution of application B2 (see Figure 4). C1 represents the power consumption incurred during the execution of application C1 (see Figure 4). Reserve represents the power consumption incurred by the reserve container.

[0123] According to graphs 1001-1006, this method reduces power consumption by 1.5 (12% before addition, 14% after addition) compared to other method 2.

[0124] As described above, according to the management server 201 (resource management device 101) of this embodiment, it is possible to classify the spare spare containers based on characteristic information so that spare spare containers used at the same time do not belong to the same group. The characteristic information is information that represents the characteristics of each of the multiple containers related to the provision of one or more services. The spare spare containers include spare containers corresponding to each of the multiple containers. Furthermore, according to the management server 201, it is possible to allocate resources redundantly to the spare containers within the classified group so that resources are shared among the spare containers within that group. The resources are, for example, ICT resources such as CPU, memory, storage, and accelerators.

[0125] This allows the management server 201 to group spare containers so that those likely to be used at the same time use different resources (ICT resources). This enables the management server 201 to rapidly increase resources and reduce power consumption by decreasing the number of ICT resources that need to be powered on in advance. For example, when resource expansion is needed, the management server 201 can prevent resource contention between containers being added, which would delay the process of adding containers.

[0126] Furthermore, according to the management server 201, based on characteristic information indicating which of the one or more services each container is related to, it is possible to classify the backup backup containers so that backup containers corresponding to the same service are not grouped together.

[0127] This allows the management server 201 to group spare containers for the same service that are likely to have overlapping resource upgrade timings, thus separating them.

[0128] Furthermore, according to the management server 201, based on characteristic information representing the load status of each of the multiple containers, it is possible to classify the backup backup containers so that backup backup containers corresponding to containers whose processing performance margin falls below a threshold are not grouped together.

[0129] This allows the management server 201 to group containers so that backup containers are separated to accommodate containers with insufficient processing power in the current service configuration.

[0130] Furthermore, according to the management server 201, based on characteristic information representing the demand trends of the services corresponding to each of the multiple containers, it is possible to classify the backup backup containers so that backup backup containers corresponding to containers providing services with the same demand trends do not belong to the same group.

[0131] This allows the management server 201 to group services with similar content and demand trends into separate backup containers.

[0132] Furthermore, according to the management server 201, based on resource limit information and characteristic information, it is possible to classify the backup backup containers so that the amount of resources allocated to the backup backup containers does not exceed the limit, and so that backup backup containers used at the same time are not grouped together. The resource limit information represents the upper limit of the amount of resources that can be allocated to the backup backup containers.

[0133] This allows the management server 201 to group backup containers so that backup containers that are likely to be used at the same time use different resources (ICT resources), while keeping the number of backup ICT resources down from the perspective of power consumption and cost.

[0134] Furthermore, according to the management server 201, it can power on resources that are allocated to backup containers within a group, from among the resources that can be allocated to backup containers. Resources that can be allocated to backup containers are powered off (power OFF) when they are not allocated.

[0135] This allows the management server 201 to reduce the power consumption of unallocated ICT resources.

[0136] Furthermore, according to the management server 201, among the resources that can be allocated to the backup container, the power supply of resources other than those already allocated can be set to a power-saving mode (e.g., low power consumption state, low performance state).

[0137] As a result, the management server 201 can reduce the power consumption of unallocated ICT resources, and when powering on resources allocated to the backup container, it can shorten the time it takes to transition to the normal state compared to when there is a power outage.

[0138] Based on these considerations, the management server 201 according to this embodiment makes it possible to build an infrastructure that meets user performance requirements with low power consumption.

[0139] (Example 1) Next, we will describe Example 1 of the management server 201. Example 1 describes a case in which backup containers are classified so that backup containers corresponding to containers providing the same service are not grouped together.

[0140] (Services to be deployed) First, we will explain the services to be deployed using Figure 11.

[0141] Figure 11 is an explanatory diagram showing an example of a service to be deployed. In Figure 11, services A and B are examples of services to be deployed. Service A is a two-tiered service including applications A1 and A2. Service B is a two-tiered service including applications B1 and B2.

[0142] (Specific examples of application performance / resource information) Next, we will explain a specific example of application performance / resource information using Figure 12.

[0143] Figure 12 is an explanatory diagram (part 1) showing a specific example of application performance / resource information. In Figure 12, application performance / resource information 1200 shows the correspondence between the application, its performance, and the required resources (CPU, GPU). In Figure 12, the number of CPUs indicates the number of CPUs with the same performance. The number of GPUs indicates the number of GPUs with the same performance.

[0144] For example, app performance / resource information 1200 indicates that app A1 has a performance of "80Mbps" and requires "CPU: 2, GPU: 0".

[0145] The following describes an example of operation according to Example 1.

[0146] First, the reception unit 501 receives the performance requirements for each service A and B. Here, the performance requirement for service A is set to "40 Mbps," and the performance requirement for service B is set to "50 Mbps."

[0147] Next, the first calculation unit 502 calculates the container configuration for providing each of services A and B. Specifically, for example, the first calculation unit 502 calculates the container configuration for providing service A based on the required performance of "40Mbps" for service A and the application performance / resource information 1200 shown in Figure 12.

[0148] Here, while the required performance of service A is "40Mbps", the performance of application A1, the first stage of service A, is "80Mbps". Therefore, the first calculation unit 502 sets the number of containers in the first stage of service A to "1". Also, while the required performance of service A is "40Mbps", the performance of application A2, the second stage of service A, is "30Mbps". Therefore, the first calculation unit 502 sets the number of containers in the second stage of service A to "2".

[0149] Furthermore, the first calculation unit 502 calculates the container configuration for providing service B based on the required performance of service B, "50Mbps", and the application performance / resource information 1200. Here, the performance of the first stage application B1 of service B is "100Mbps", while the required performance of service B is "50Mbps". For this reason, the first calculation unit 502 sets the number of first-stage containers for service B to "1". Also, the performance of the second stage application B2 of service B is "50Mbps", while the required performance of service B is "50Mbps". For this reason, the first calculation unit 502 sets the number of second-stage containers for service B to "1".

[0150] The calculated container configuration is stored in service configuration information 1300, for example, as shown in Figure 13.

[0151] Figure 13 is an explanatory diagram showing a specific example of service configuration information 1300. In Figure 13, service configuration information 1300 shows the container configuration for providing services A and B. Service configuration information 1300 indicates that in order to provide service A, one container A1a is required to run the first-stage application A1, and two containers A2a and A2b are required to run the second-stage application A2.

[0152] Furthermore, the service configuration information 1300 indicates that in order to provide service B, one container B1a is required to run the first-stage application B1, and one container B2a is required to run the second-stage application B2. Note that A1a, A2a, A2b, B1a, and B2a are identifiers that uniquely identify the containers (including spare containers) assigned by the management server 201.

[0153] For example, container A1a represents the first container running application A1. Container A2a represents the first container running application A2. Container A2b represents the second container running application A2.

[0154] Next, the first calculation unit 502 allocates resources to containers A1a to B2a that provide each of services A and B. Specifically, for example, the first calculation unit 502 refers to the application performance / resource information 1200 to determine the amount of resources (required resources) to be allocated to each container A1a to B2a.

[0155] For example, the resources used in container A1a correspond to the required resources of application A1, which are "CPU: 2, GPU: 0". Similarly, the resources used in container B1a correspond to the required resources of application B1, which are "CPU: 2, GPU: 1".

[0156] The first calculation unit 502 then refers to the resource allocation status information 1400 shown in Figure 14 and allocates the specified amount of available resources to each container A1a to B2a. The contents of the resource allocation status information 1400 will now be explained. Here, the resources that can be allocated to the containers (including spare containers) are "CPU1 to CPU16, GPU1 to GPU10".

[0157] Figure 14 is an explanatory diagram showing an example of the changes in the stored contents of resource allocation status information 1400. In Figure 14, resource allocation status information 1400 shows the allocation status of each resource that can be allocated to a container (including spare containers). Type indicates the type of resource. ON indicates an allocated state. OFF indicates an unallocated state.

[0158] The resource allocation status information 1400 shown in (14-1) indicates that CPU1 to CPU16 and GPU1 to GPU10 are unallocated. The first calculation unit 502, for example, refers to the resource allocation status information 1400 and allocates the unallocated resources to each container A1a to B2a in ascending order of their numbers.

[0159] For example, the first calculation unit 502 assigns CPU1 and CPU2 to container A1a. The first calculation unit 502 assigns CPU3 and GPU1 to container A2a. The first calculation unit 502 assigns CPU4 and GPU2 to container A2b. The first calculation unit 502 assigns CPU5, CPU6 and GPU3 to container B1a. The first calculation unit 502 assigns CPU7 and GPU4 to container B2a.

[0160] As a result, CPU1 to CPU7 and GPU1 to GPU4 are turned ON, as shown in the resource allocation status information 1400 in (14-2). Next, the power management unit 503 turns on the power to the resources allocated to each container A1a to B2a. Then, the deployment unit 504 deploys the containers A1a to B2a for providing each service A and B.

[0161] The operating status of each container A1a to B2a is managed by container management information 1500, for example, as shown in Figures 15A to 15C.

[0162] Figures 15A to 15C are explanatory diagrams showing examples of changes in the stored contents of container management information 1500. In Figures 15A to 15C, container management information 1500 shows the resource allocation results and operating status of each container related to the provision of services A and B. In Figures 15A to 15C, the container ID is the identifier of the container. The CPU number is the identifier of the CPU assigned to the container. The GPU number is the identifier of the GPU assigned to the container. The status indicates the operating status of the container.

[0163] The container management information 1500 shown in (15-1) of Figure 15A displays the resource allocation results and operational status of each container A1a to B2a. The status "Operating" indicates that the container is running.

[0164] Here, using Figures 16 to 18, we will explain the resource usage status allocated to the containers (including backup containers) used to provide services A and B.

[0165] Figures 16 to 18 are explanatory diagrams showing the resource usage status according to Example 1. In Figures 16 to 18, CPU1 to CPU16 and GPU1 to GPU10 in the operational server 202 represent resources that can be allocated to containers (including spare containers). In Figures 16 to 18, the operational server 202 represents one or more operational servers 202. Also, CPU1 to CPU16 are CPUs with the same performance. GPU1 to GPU10 are GPUs with the same performance.

[0166] In the example shown in Figure 16, the resource usage status of containers A1a to B2a is "Power ON (In Use)". The usage status "Power ON (In Use)" indicates that the power has been turned on and the resource is being used for service. In addition, the usage status of resources other than those assigned to containers A1a to B2a is "Power OFF". The usage status "Power OFF" indicates that the power has not been turned on.

[0167] Once the deployment of containers A1a to B2a is complete, services A and B will become available.

[0168] Next, the second calculation unit 505 calculates the backup container configuration for providing services A and B based on the service configuration information 1300 shown in Figure 13. Specifically, for example, the second calculation unit 505 decides to generate backup containers A1b and A2c with the same performance as containers A1a and A2a that execute applications A1 and A2 at each stage of service A.

[0169] Furthermore, the second calculation unit 505 decides to generate backup containers B1b and B2b with the same performance as containers B1a and B2a that execute applications B1 and B2 at each stage of service B. The backup container configuration is stored, for example, in container management information 1500. In the container management information 1500 shown in (15-2) of Figure 15A, backup containers A1b, A2c, B1b, and B2b have been added.

[0170] Next, the second calculation unit 505 classifies the spare containers A1b, A2c, B1b, and B2b based on the service configuration information 1300, such that spare containers corresponding to containers providing the same service do not belong to the same group.

[0171] Here, using Figure 19, we will explain an example of the classification of the reserve containers A1b, A2c, B1b, and B2b.

[0172] Figure 19 is an explanatory diagram showing a first example of the classification of spare containers. In Figure 19, spare containers A1b, A2c, B1b, and B2b are spare containers for providing services A and B. The second calculation unit 505 groups spare containers A1b, A2c, B1b, and B2b in order, for example, so that spare containers for the same service are not grouped together.

[0173] First, the second calculation unit 505 classifies spare container A1b into group G1. Next, the second calculation unit 505 classifies spare container A2c into group G2, which is different from spare container A1b of the same service A. Next, the second calculation unit 505 classifies spare container B1b into group G1. Then, the second calculation unit 505 classifies spare container B2b into group G2, which is different from spare container B1b of the same service B.

[0174] As a result, the second calculation unit 505 can group the spare containers A1b, A2c, B1b, and B2b so that spare containers for the same service do not belong to the same group.

[0175] Next, the second calculation unit 505 allocates resources redundantly to the spare containers within the classified groups G1 and G2 so that resources are shared among the spare containers within those groups. Specifically, for example, first, the second calculation unit 505 calculates the required resource amount for each group G1 and G2 from the amount of resources (required resources) to be allocated to the spare containers within those groups G1 and G2.

[0176] Here, the required resources for the backup container A1b within group G1 are "CPU: 2". The required resources for the backup container B1b within group G1 are "CPU: 2, GPU: 1". Therefore, when sharing resources among the backup containers within group G1, the required resources for group G1 become "CPU: 2, GPU: 1" (see, for example, Figure 19).

[0177] Furthermore, the resource requirements for the backup container A2c within group G2 are "CPU: 1, GPU: 1". The resource requirements for the backup container B2b within group G2 are "CPU: 1, GPU: 1". Therefore, when sharing resources among the backup containers within group G2, the total resource requirements for group G2 become "CPU: 1, GPU: 1" (see, for example, Figure 19).

[0178] Next, the second calculation unit 505 determines the resources to be allocated to groups G1 and G2 based on the required resource amounts for each group. Specifically, for example, the second calculation unit 505 refers to the resource allocation status information 1400 shown in (14-2) of Figure 14 and allocates available resources equal to the required resource amounts to groups G1 and G2.

[0179] Here, CPU8, CPU9, and GPU5 are assigned to group G1. Additionally, CPU10 and GPU6 are assigned to group G2. As a result, as shown in resource allocation information 1400 in (14-3), CPU8-CPU10 are turned ON, and GPU5 and GPU6 are turned ON.

[0180] The second calculation unit 505 then allocates resources redundantly to the spare containers within groups G1 and G2 so that resources are shared among the spare containers within groups G1 and G2. For example, the second calculation unit 505 redundantly allocates the resources allocated to each group G1 and G2 to the spare containers within each group G1 and G2. In this case, if the resources allocated to each group G1 and G2 are greater than the resources required for the spare containers, the second calculation unit 505 selects only the necessary amount of resources.

[0181] Here, CPU8 and CPU9 are assigned to the spare container A1b within group G1 (see, for example, Figure 19). CPU8, CPU9, and GPU5 are assigned to the spare container B1b within group G1 (see, for example, Figure 19). CPU8 and CPU9 are duplicated and assigned to spare containers A1b and B1b.

[0182] Additionally, CPU10 and GPU6 are allocated to the spare container A2c within group G2 (see, for example, Figure 19). CPU10 and GPU6 are also allocated to the spare container B2b within group G2 (see, for example, Figure 19). CPU10 and GPU6 are duplicated and allocated to spare containers A2c and B2b.

[0183] As a result, as shown in (15-3) of Figure 15B, the CPU number and GPU number of the resources assigned to each of the reserve containers A1b, A2c, B1b, and B2b are added to the container management information 1500.

[0184] Next, the power management unit 503 powers on the resources allocated to each of the backup containers A1b, A2c, B1b, and B2b. Then, the deployment unit 504 deploys the backup containers A1b, A2c, B1b, and B2b for providing services A and B. As a result, as shown in (15-4) of Figure 15B, the status of each of the backup containers A1b, A2c, B1b, and B2b in the container management information 1500 is set to "Backup". The status "Backup" indicates that the container is on standby as a backup container.

[0185] Furthermore, as shown in Figure 17, regarding the resource usage status, the resources assigned to the backup containers A1b, A2c, B1b, and B2b will be in the "Power ON (Unused)" state. The "Power ON (Unused)" status indicates that the power is on, but the resource is not being used for service. Resources in the "Power ON (Unused)" state are in a standby state, so they consume more power than resources in the "Power OFF" state, but less power than resources in the "Power ON (In Use)" state.

[0186] Here, we consider a scenario where, due to an increase in traffic volume or other factors, the performance of the first-tier container A1a of service A becomes insufficient, and resource enhancement becomes necessary.

[0187] Figure 20 is an explanatory diagram showing an example of a container configuration and a backup container configuration. In Figure 20, containers A1a, A2a, and A2b for providing service A and containers B1a and B2a for providing service B are shown. Also shown are backup containers A1b and B1b classified as group G1 and backup containers A2c and B2b classified as group G2.

[0188] In this case, the performance of the first-tier container A1a of service A is insufficient. In this case, the first calculation unit 502 identifies a spare container to add to service A from among the spare containers A1b, A2c, B1b, and B2b. Here, spare container A1b is identified as the one corresponding to container A1a, which requires increased resources.

[0189] The first calculation unit 502 then adds the identified backup container A1b to service A. The first calculation unit 502 also updates the container configuration so that the added backup container A1b occupies the resources that are shared with other backup containers B1b within the same group G1.

[0190] More specifically, for example, the first calculation unit 502 requests the deployment unit 504 to configure the connection settings for CPU8 and CPU9 occupied by the spare container A1b, and to delete the other spare container B1b within group G1. At this time, the deployment unit 504 may also configure settings such as changes to traffic distribution.

[0191] Furthermore, the power management unit 503 turns off the power to the resources allocated only to the other spare container B1b within group G1. Specifically, for example, the power management unit 503 sends a power-off command for the GPU5 to the operation server 202 which has a GPU5 allocated only to the other spare container B1b.

[0192] As a result, on the operational server 202, the power to GPU5, which is assigned only to the other backup container B1b, is turned OFF, and GPU5 in the resource allocation status information 1400 is set to OFF. Also, as shown in Figure 18, regarding the resource usage status, the usage status of the resources (CPU8, CPU9) assigned to backup container A1b becomes "Power ON (Used)", and the usage status of GPU5 becomes "Power OFF". Furthermore, as shown in (15-5) of Figure 15C, the status of backup container A1b in the container management information 1500 is set to "Operational". In addition, the CPU number and GPU number of backup container B1b are set to "-(null)", and the status is set to "Deleted".

[0193] As a result, the management server 201 completes the resource enhancement for service A using the backup container A1b. In the example in Figure 20, the backup container A1b in group G1 is added to the first stage of service A, and the resource enhancement is performed. After this, the management server 201 may, for example, re-prepare the backup container B1b that was sharing resources with the backup container A1b, or prepare the backup container A1c for the first stage of service A.

[0194] (Resource management processing procedure for management server 201) Next, we will describe the specific processing procedure for resource management processing of the management server 201 according to Example 1.

[0195] Figure 21 is a flowchart illustrating an example of the specific processing procedure for resource management processing by the management server 201. In the flowchart of Figure 21, first, the management server 201 receives the performance requirements for each service (step S2101). Next, the management server 201 determines the service configuration for each service based on the received performance requirements (step S2102). The service configuration indicates, for example, the number of containers at each stage that satisfy the performance requirements for the service.

[0196] Then, the management server 201 calculates the container configuration required to provide each service based on the determined service configuration and allocates resources to the containers required to provide each service (step S2103). Next, the management server 201 powers on the resources allocated to each container (step S2104).

[0197] Then, the management server 201 deploys the containers, including the resource connection settings (step S2105). Next, the management server 201 adds containers to each service (step S2106). At this time, the management server 201 configures settings such as changes to traffic distribution.

[0198] Next, the management server 201 executes the backup container configuration determination process (step S2107). The specific processing steps for the backup container configuration determination process will be described later using Figure 22. Next, the management server 201 powers on the resources allocated to each backup container (step S2108).

[0199] Then, the management server 201 deploys a backup container, including the resource connection settings (step S2109), and completes the series of processes according to this flowchart. As a result, the management server 201 can add containers for providing each service and deploy backup containers according to the performance requirements of each service.

[0200] Next, using Figure 22, we will explain the specific processing steps for determining the preliminary container configuration in step S2107.

[0201] Figure 22 is a flowchart showing an example of the specific processing steps for determining the backup container configuration. In the flowchart of Figure 22, first, the management server 201 calculates the backup container configuration for providing each service based on the service configuration of each service (step S2201).

[0202] Next, the management server 201 performs the first grouping process based on the calculated spare container configuration (step S2202). The specific processing steps for the first grouping process will be described later using Figure 23. Then, the management server 201 calculates the required resource amount for each group from the required resources of the spare containers within each group (step S2203).

[0203] Next, the management server 201 allocates available resources to each group based on the calculated required resource amount for each group (step S2204). Then, the management server 201 allocates resources redundantly to the spare containers within each group so that resources are shared among the spare containers within each group (step S2205), and returns to the step that called the spare container configuration determination process.

[0204] Next, using Figure 23, we will explain the specific processing procedure for the first grouping process in step S2202.

[0205] Figure 23 is a flowchart showing an example of the specific processing steps for the first grouping process. In the flowchart of Figure 23, first, the management server 201 selects an unselected spare container from the spare containers (step S2301). Next, the management server 201 identifies the service of the selected spare container based on the service configuration information (step S2302).

[0206] Then, the management server 201 determines whether or not there are any unverified groups (step S2303). If there are no unverified groups (step S2303: No), the management server 201 adds the selected spare container to the new group (step S2304) and proceeds to step S2309.

[0207] On the other hand, if there are unconfirmed groups (step S2303: Yes), the management server 201 selects the unconfirmed groups (step S2305). Next, the management server 201 identifies the services of the spare containers within the group (step S2306). Then, the management server 201 determines whether the identified services are the same as the services identified in step S2302 (step S2307).

[0208] If the services are the same (step S2307: Yes), the management server 201 returns to step S2303. On the other hand, if the services are different (step S2307: No), the management server 201 adds the selected spare container to the selected group (step S2308).

[0209] The management server 201 then determines whether there are any unselected spare containers among the spare containers (step S2309). If there are unselected spare containers (step S2309: Yes), the management server 201 returns to step S2301. On the other hand, if there are no unselected spare containers (step S2309: No), the management server 201 returns to the step that called the first grouping process.

[0210] This allows the management server 201 to group the spare containers so that spare containers for the same service are not in the same group.

[0211] (Procedure for increasing the resources of management server 201) Next, we will explain the procedure for increasing the resources of management server 201.

[0212] Figure 24 is a flowchart showing an example of the resource enhancement process for the management server 201. In the flowchart of Figure 24, first, the management server 201 monitors the load on the containers providing the service and decides whether or not to enhance the resources (step S2401).

[0213] At this point, the management server 201 waits until it decides to increase the resources (step S2401: No). If the management server 201 decides to increase the resources (step S2401: Yes), it identifies a spare container to add to the service from among the spare containers (step S2402).

[0214] Next, the management server 201 adds the identified backup container to the service (step S2403). At this time, the management server 201 configures settings such as changes to traffic distribution. Then, the management server 201 identifies other backup containers in the same group as the added backup container (step S2404).

[0215] Next, the management server 201 deletes the other identified backup containers (step S2405). Then, the management server 201 updates the container configuration so that the added backup container occupies the resources shared with the other backup containers in the same group (step S2406).

[0216] Next, the management server 201 turns off the power to unnecessary resources that are allocated only to other spare containers (step S2407). Then, the management server 201 determines whether or not further resource enhancement is needed (step S2408). If resource enhancement is needed (step S2408: Yes), the management server 201 returns to step S2402.

[0217] On the other hand, if resource enhancement is not necessary (step S2408: No), the management server 201 terminates the series of processes according to this flowchart. This allows the management server 201 to use backup containers to enhance resources for the service when performance issues arise due to increased traffic or other reasons.

[0218] As explained above, the management server 201 according to Example 1 allows for the grouping of spare containers for the same service whose resource enhancement timings are likely to overlap. This enables the management server 201 to rapidly enhance resources and reduce power consumption by reducing the number of ICT resources that need to be powered on in advance.

[0219] (Example 2) Next, we will describe Example 2 of the management server 201. In Example 2, we will describe a case in which backup containers are classified so that backup containers corresponding to containers whose processing performance margin falls below a threshold are not grouped together.

[0220] The following describes an example of operation for Example 2. However, the service to be deployed is the same as in Example 1 (see Figure 11). Also, the service deployment and resource enhancement for Example 2 are the same as in Example 1, so the illustrations and explanations are omitted. Here, we will describe an example of operation when preparing a backup container for Example 2.

[0221] First, the load monitoring unit 506 monitors the load on the containers providing services A and B, and records the current load in the service configuration information 2500 as shown in Figure 25.

[0222] Figure 25 is an explanatory diagram showing a specific example of service configuration information 2500. In Figure 25, service configuration information 2500 shows the container configuration for providing services A and B, and the current load. The current load represents the load of each stage container involved in providing services A and B.

[0223] The second calculation unit 505 calculates the backup container configuration for providing services A and B based on the service configuration information 2500 shown in Figure 25. Specifically, for example, the second calculation unit 505 decides to generate backup containers A1b and A2c with the same performance as containers A1a and A2a that execute applications A1 and A2 at each stage of service A.

[0224] Furthermore, the second calculation unit 505 decides to generate backup containers B1b and B2b with the same performance as the containers B1a and B2a that execute the applications B1 and B2 at each stage of service B. The backup container configuration is stored in container management information 2600, for example, as shown in Figure 26.

[0225] Figure 26 is an explanatory diagram showing an example of the changes in the contents of the container management information 2600. In Figure 26, the container management information 2600 shows the resource allocation results and operating status of each container related to the provision of services A and B. In the container management information 2600 shown in (26-1), spare containers A1b, A2c, B1b, and B2b have been added.

[0226] Next, the second calculation unit 505 classifies the spare containers A1b, A2c, B1b, and B2b based on the service configuration information 2500, such that spare containers corresponding to containers whose processing performance margin is below a threshold are not grouped together.

[0227] Here, using Figures 27A and 27B, we will explain examples of the classification of the reserve containers A1b, A2c, B1b, and B2b.

[0228] Figures 27A and 27B are explanatory diagrams showing a second classification example of spare containers. In Figure 27A, containers A1a, A2a, A2b, B1a, and B2a are spare containers for providing services A and B. Also, spare containers A1b, A2c, B1b, and B2b are spare containers for providing services A and B.

[0229] First, the second calculation unit 505 calculates the performance margin of containers A1a, A2a, A2b, B1a, and B2a for each stage of services A and B. Then, the second calculation unit 505 rearranges the spare containers A1b, A2c, B1b, and B2b in descending order of the calculated margin.

[0230] For the first stage of Service A, the current load on container A1a is 40Mbps against a processing capacity of 80Mbps. Therefore, the processing capacity headroom for container A1a in the first stage is 40Mbps. For the second stage of Service A, the current load on containers A2a and A2b is 40Mbps against a processing capacity of 60Mbps (30Mbps x 2). Therefore, the processing capacity headroom for containers A2a and A2b in the second stage is 20Mbps.

[0231] For the first stage of Service B, the current load on container B1a is 50 Mbps against a processing capacity of 100 Mbps. Therefore, the processing capacity headroom for container B1a in the first stage is 50 Mbps. Similarly, for the second stage of Service B, the current load on container B2a is 50 Mbps against a processing capacity of 50 Mbps. Therefore, the processing capacity headroom for container B2a in the second stage is 0 Mbps.

[0232] In this case, when the spare containers A1b, A2c, B1b, and B2b are sorted in order of the smallest processing performance margin for each stage, the spare containers become B2b, A2c, A1b, and B1b. The second calculation unit 505 then groups the sorted spare containers B2b, A2c, A1b, and B1b in order so that spare containers with a processing performance margin below a threshold do not belong to the same group.

[0233] Here, the threshold is set to "30 Mbps". In this case, the spare containers whose processing performance margin is below the threshold are spare containers B2b and A2c.

[0234] First, the second calculation unit 505 classifies spare container B2b into group G1. Next, the second calculation unit 505 classifies spare container A2c into group G2, which is different from spare container B2b. Next, the second calculation unit 505 classifies spare container A1b into group G1. Then, the second calculation unit 505 classifies spare container B1b into group G2.

[0235] As a result, the second calculation unit 505 can group the spare containers A1b, A2c, B1b, and B2b so that spare containers whose processing performance margin is below a threshold are not grouped together.

[0236] Next, the second calculation unit 505 allocates resources redundantly to the spare containers within the classified groups G1 and G2 so that resources are shared among the spare containers within those groups. Specifically, for example, first, the second calculation unit 505 calculates the required resource amount for each group G1 and G2 from the amount of resources (required resources) to be allocated to the spare containers within those groups G1 and G2.

[0237] Here, the required resources for the backup container B2b within group G1 are "CPU: 1, GPU: 1". The required resources for the backup container A1b within group G1 are "CPU: 2". Therefore, when resources are shared among the backup containers within group G1, the required resources for group G1 become "CPU: 2, GPU: 1" (see Figure 27B).

[0238] Furthermore, the resource requirements for the backup container A2c within group G2 are "CPU: 1, GPU: 1". The resource requirements for the backup container B1b within group G2 are "CPU: 2, GPU: 1". Therefore, when sharing resources among the backup containers within group G2, the total resource requirements for group G2 become "CPU: 2, GPU: 1" (see Figure 27B).

[0239] Next, the second calculation unit 505 determines the resources to be allocated to groups G1 and G2 based on the required resource amounts for each group. Specifically, for example, the second calculation unit 505 allocates available resources equal to the required resource amounts to groups G1 and G2. In this case, CPU8, CPU9 and GPU5 are allocated to group G1. Also, CPU10, CPU11 and GPU6 are allocated to group G2.

[0240] The second calculation unit 505 then allocates resources redundantly to the spare containers within groups G1 and G2 so that resources are shared among the spare containers within groups G1 and G2.

[0241] Here, CPU8 and GPU5 are allocated to the spare container B2b within group G1 (see Figure 27B). CPU8 and CPU9 are allocated to the spare container A1b within group G1 (see Figure 27B). CPU8 is duplicated and allocated to spare containers A1b and B2b.

[0242] Additionally, CPU10 and GPU6 are allocated to the spare container A2c within group G2 (see Figure 27B). CPU10, CPU11, and GPU6 are allocated to the spare container B1b within group G2 (see Figure 27B). CPU10 and GPU6 are duplicated and allocated to spare containers A2c and B1b.

[0243] As a result, as shown in (26-2) of Figure 26, the CPU number and GPU number of the resources assigned to each of the reserve containers A1b, A2c, B1b, and B2b are added to the container management information 2600.

[0244] Next, the power management unit 503 powers on the resources allocated to each of the backup containers A1b, A2c, B1b, and B2b. Then, the deployment unit 504 deploys the backup containers A1b, A2c, B1b, and B2b for providing services A and B. As a result, as shown in (26-3) of Figure 26, the status of each of the backup containers A1b, A2c, B1b, and B2b in the container management information 2600 is set to "Backup".

[0245] Here, using Figure 28, we will explain the resource usage status allocated to the containers (including backup containers) used to provide services A and B.

[0246] Figure 28 is an explanatory diagram showing the resource usage status according to Example 2. In Figure 28, CPU1 to CPU16 and GPU1 to GPU10 in the operational server 202 represent resources that can be allocated to containers (including spare containers). Note that in Figure 28, operational server 202 represents one or more operational servers 202.

[0247] In the example shown in Figure 28, the resource usage status of containers A1a to B2a is "Power ON (In Use)". The resource usage status of reserve containers A1b to B2b is "Power ON (Unused)". In addition, the resource usage status of resources other than those assigned to containers A1a to B2a and reserve containers A1b to B2b is "Power OFF".

[0248] (Resource management processing procedure for management server 201) Next, the specific processing procedure for the resource management process of the management server 201 according to Example 2 will be described. However, except for the first grouping process in step S2202 shown in Figure 22, the specific processing procedure for the resource management process of the management server 201 according to Example 1 is the same. For this reason, only the specific processing procedure for the second grouping process, which is executed instead of the first grouping process in step S2202, will be described here.

[0249] Figure 29 is a flowchart illustrating an example of the specific processing procedure for the second grouping process. In the flowchart of Figure 29, first, the management server 201 calculates the margin of processing performance for each stage of the service (step S2901). Next, the management server 201 sorts the spare containers for backup in descending order of the margin of processing performance for each additional stage of the backup container (step S2902).

[0250] Next, the management server 201 determines whether or not a group exists (step S2903). If no group exists (step S2903: No), the management server 201 selects the first available spare container, adds the spare container to a new group (step S2904), and proceeds to step S2909.

[0251] Furthermore, in step S2903, if there is a group (step S2903: Yes), the management server 201 sequentially selects the unselected reserve containers from the sorted reserve containers (step S2905). Next, the management server 201 determines whether the processing performance margin of the selected reserve containers is below a threshold (step S2906).

[0252] If the processing performance margin is below the threshold (step S2906: Yes), the management server 201 proceeds to step S2904. On the other hand, if the processing performance margin is greater than the threshold (step S2906: No), the management server 201 selects an existing group (step S2907).

[0253] Then, the management server 201 adds the selected spare container to the selected group (step S2908). Next, the management server 201 determines whether there are any unselected spare containers among the sorted spare containers (step S2909). If there are unselected spare containers (step S2909: Yes), the process returns to step S2905. On the other hand, if there are no unselected spare containers (step S2909: No), the management server 201 returns to the step that called the second grouping process.

[0254] This allows the management server 201 to group the spare containers so that spare containers corresponding to stages (containers) where the processing performance margin falls below a threshold are not grouped together.

[0255] As described above, according to the management server 201 according to the second embodiment, spare containers for stages with little margin in processing performance in the current service configuration can be grouped so as to be separated. Thereby, the management server 201 can enable rapid resource enhancement and can reduce the power consumption by reducing the number of ICT resources that are powered on and prepared in advance.

[0256] (Embodiment 3) Next, an embodiment 3 of the management server 201 will be described. In the third embodiment, a case will be described in which spare containers are classified so that spare containers corresponding to containers for providing services with the same demand tendency among the spare containers do not become the same group.

[0257] Hereinafter, an operation example according to the third embodiment will be described. However, since the service deployment and resource enhancement according to the third embodiment are the same as those in the first embodiment, illustration and description thereof are omitted. Here, an operation example when preparing the spare container according to the third embodiment will be described.

[0258] In the third embodiment, the services to be deployed are "services A, B, C". Here, the service configuration information indicating the container configuration for providing the services A, B, and C will be described using FIG. 30.

[0259] FIG. 30 is an explanatory diagram showing a specific example of the service configuration information 3000. In FIG. 30, the service configuration information 3000 shows the container configuration and demand tendency for providing each of the services A and B. The service configuration information 3000 indicates that in order to provide service A, one container A1a for executing the first-stage application A1 and two containers A2a and A2b for executing the second-stage application A2 are required. The service configuration information 3000 indicates that the demand tendency of service A is "night type".

[0260] Furthermore, the service configuration information 3000 indicates that in order to provide service B, one container B1a is required to run the first-stage application B1, and one container B2a is required to run the second-stage application B2. The service configuration information 3000 also indicates that the demand trend for service B is "daytime-oriented".

[0261] Furthermore, the service configuration information 3000 indicates that in order to provide service C, one container C1a is required to run the first-stage application C1, and one container C2a is required to run the second-stage application C2. The service configuration information 3000 also indicates that the demand trend for service C is "nighttime".

[0262] Next, we will explain a specific example of application performance / resource information using Figure 31.

[0263] Figure 31 is an explanatory diagram (part 2) showing a specific example of application performance / resource information. In Figure 31, the application performance / resource information 3100 shows the correspondence between the application, its performance, and the required resources (CPU, GPU). For example, the application performance / resource information 3100 shows that the performance of application C1 is "100Mbps" and the required resources for application C1 are "CPU: 1, GPU: 0".

[0264] The following describes an example of operation according to Example 3.

[0265] The second calculation unit 505 calculates the backup container configuration for providing services A, B, and C based on the service configuration information 3000 shown in Figure 30. Specifically, for example, the second calculation unit 505 decides to generate backup containers A1b and A2c with the same performance as containers A1a and A2a that run the applications A1 and A2 at each stage of service A. Here, we assume that one backup container is secured for each application at each stage.

[0266] Furthermore, the second calculation unit 505 decides to generate backup containers B1b and B2b with the same performance as containers B1a and B2a that execute applications B1 and B2 at each stage of service B. The second calculation unit 505 also decides to generate backup containers C1b and C2b with the same performance as containers C1a and C2a that execute applications C1 and C2 at each stage of service C. The backup container configuration is stored in container management information 3200, for example, as shown in Figure 32.

[0267] Figure 32 is an explanatory diagram showing an example of the changes in the contents of the container management information 3200. In Figure 32, the container management information 3200 shows the resource allocation results and operating status of each container related to the provision of services A, B, and C. In the container management information 2600 shown in (32-1), spare containers A1b, A2c, B1b, B2b, C1b, and C2b have been added.

[0268] Next, the second calculation unit 505 classifies the spare containers A1b, A2c, B1b, B2b, C1b, and C2b based on the service configuration information 3000, such that spare containers corresponding to containers providing services with the same demand trend do not belong to the same group.

[0269] Here, using Figure 33, we will explain an example of the classification of the spare containers A1b, A2c, B1b, B2b, C1b, and C2b.

[0270] Figure 33 is an explanatory diagram showing a third classification example of spare containers. In Figure 33, spare containers A1b, A2c, B1b, B2b, C1b, and C2b are spare containers for providing services A, B, and C.

[0271] First, the second calculation unit 505 groups the spare containers A1b, A2c, B1b, B2b, C1b, and C2b in order based on the service configuration information 3000, so that spare containers for services with similar demand trends do not end up in the same group.

[0272] For example, the second calculation unit 505 assigns the spare container A1b to group G1. Next, the demand trend for spare container A2c is the same as that of spare container A1b. Therefore, the second calculation unit 505 assigns spare container A2c to group G2, which is different from spare container A1b.

[0273] Next, the demand trend for spare container B1b is different from that of spare container A1b. Therefore, the second calculation unit 505 assigns spare container B1b to the same group G1 as spare container A1b. Next, the demand trend for spare container B2b is the same as that of spare container B1b. Therefore, the second calculation unit 505 assigns spare container B2b to a different group G2 than that of spare container B1b.

[0274] Next, the demand trend for spare container C1b is the same as that for spare containers A1b and A2c. Therefore, the second calculation unit 505 assigns spare container C1b to group G3, which is different from spare containers A1b and A2c. Next, the demand trend for spare container C2b is the same as that for spare containers A1b, A2c, and C1b. Therefore, the second calculation unit 505 assigns spare container C2b to group G4, which is different from spare containers A1b, A2c, and C1b.

[0275] As a result, the second calculation unit 505 can group the spare containers A1b, A2c, B1b, B2b, C1b, and C2b so that spare containers for services with the same demand trend do not end up in the same group.

[0276] Next, the second calculation unit 505 allocates resources redundantly to the spare containers within the classified groups G1 to G4 so that resources are shared among the spare containers within those groups. Specifically, for example, first, the second calculation unit 505 calculates the required resource amount for each group G1 to G4 from the amount of resources (required resources) to be allocated to the spare containers within the groups G1 to G4.

[0277] Here, the required resources of the standby container A1b in group G1 are "CPU: 2". The required resources of the standby container B1b in group G1 are "CPU: 2, GPU: 1". Therefore, when sharing resources among the standby containers in group G1, the amount of required resources for group G1 is "CPU: 2, GPU: 1" (see Fig. 33).

[0278] Also, the required resources of the standby container A2c in group G2 are "CPU: 1, GPU: 1". The required resources of the standby container B2b in group G2 are "CPU: 1, GPU: 1". Therefore, when sharing resources among the standby containers in group G2, the amount of required resources for group G2 is "CPU: 1, GPU: 1" (see Fig. 33).

[0279] Also, the required resources of the standby container C1b in group G3 are "CPU: 1". Therefore, the amount of required resources for group G3 is "CPU: 1" (see Fig. 33). Also, the required resources of the standby container C2b in group G4 are "CPU: 1, GPU: 1". Therefore, the amount of required resources for group G4 is "CPU: 1, GPU: 1" (see Fig. 33).

[0280] Next, the second calculation unit 505 determines the resources to be allocated to each of the groups G1 to G4 based on the amount of required resources of each of the groups G1 to G4. Specifically, for example, the second calculation unit 505 allocates free resources corresponding to the amount of required resources to the groups G1 to G4. Here, CPU10, CPU11, and GPU6 are allocated to group G1. Also, CPU12 and GPU7 are allocated to group G2. Also, CPU13 is allocated to group G3. Also, CPU14 and GPU8 are allocated to group G4.

[0281] Then, the second calculation unit 505 allocates resources to the standby containers in each of the groups G1 to G4 so as to share resources among the standby containers in each of the groups G1 to G4.

[0282] Here, CPU10 and CPU11 are allocated to the spare container A1b within group G1 (see Figure 33). CPU10, CPU11, and GPU6 are allocated to the spare container B1b within group G1 (see Figure 33). CPU10 and CPU11 are duplicated and allocated to spare containers A1b and B1b.

[0283] Additionally, CPU12 and GPU7 are allocated to the spare container A2c within group G2 (see Figure 33). CPU12 and GPU7 are also allocated to the spare container B2b within group G2 (see Figure 33). CPU12 and GPU7 are duplicated and allocated to spare containers A2c and B2b.

[0284] Additionally, CPU 13 is allocated to the spare container C1b within group G3 (see Figure 33). Furthermore, CPU 14 and GPU 8 are allocated to the spare container C2b within group G4 (see Figure 33).

[0285] As a result, as shown in (32-2) of Figure 32, the CPU number and GPU number of the resources assigned to each of the reserve containers A1b, A2c, B1b, B2b, C1b, and C2b are added to the container management information 3200.

[0286] Next, the power management unit 503 powers on the resources allocated to each of the spare containers A1b, A2c, B1b, B2b, C1b, and C2b. Then, the deployment unit 504 deploys the spare containers A1b, A2c, B1b, B2b, C1b, and C2b for providing each of the services A, B, and C. As a result, as shown in (32-3) of Figure 32, the status of each of the spare containers A1b, A2c, B1b, B2b, C1b, and C2b in the container management information 3200 is set to "Spare".

[0287] Here, using Figure 34, we will explain the resource usage status allocated to the containers (including backup containers) used to provide services A, B, and C.

[0288] Figure 34 is an explanatory diagram showing the resource usage status according to Example 3. In Figure 34, CPU1 to CPU16 and GPU1 to GPU10 in the operational server 202 represent resources that can be allocated to containers (including spare containers). Note that in Figure 34, operational server 202 represents one or more operational servers 202.

[0289] In the example shown in Figure 34, the resource usage status of containers A1a to C2a is "Power ON (In Use)". The resource usage status of reserve containers A1b to C2b is "Power ON (Unused)". In addition, the resource usage status of resources other than those assigned to containers A1a to C2a and reserve containers A1b to C2b is "Power OFF".

[0290] (Resource management processing procedure for management server 201) Next, the specific processing procedure for the resource management process of the management server 201 according to Example 3 will be described. However, except for the first grouping process in step S2202 shown in Figure 22, the specific processing procedure for the resource management process of the management server 201 according to Example 1 is the same. For this reason, only the specific processing procedure for the third grouping process, which is executed instead of the first grouping process in step S2202, will be described here.

[0291] Figure 35 is a flowchart showing an example of the specific processing procedure for the third grouping process. In the flowchart of Figure 35, first, the management server 201 selects the unselected spare containers from the spare containers (step S3501). Next, the management server 201 identifies the demand trend of the selected spare containers based on the service configuration information (step S3502).

[0292] Then, the management server 201 determines whether or not there are any unverified groups (step S3503). If there are no unverified groups (step S3503: No), the management server 201 adds the selected spare container to the new group (step S3504) and proceeds to step S3509.

[0293] On the other hand, if there are unconfirmed groups (step S3503: Yes), the management server 201 selects the unconfirmed groups (step S3505). Next, the management server 201 identifies the demand trends for the services of the spare containers within the group (step S3506). Then, the management server 201 determines whether the identified services have the same demand trends as those identified in step S3502 (step S3507).

[0294] If the demand trends are the same (step S3507: Yes), the management server 201 returns to step S3503. On the other hand, if the demand trends are different (step S3507: No), the management server 201 adds the selected spare container to the selected group (step S3508).

[0295] The management server 201 then determines whether there are any unselected spare containers among the spare containers (step S3509). If there are unselected spare containers (step S3509: Yes), the management server 201 returns to step S3501. On the other hand, if there are no unselected spare containers (step S3509: No), the management server 201 returns to the step that called the third grouping process.

[0296] This allows the management server 201 to group spare containers so that spare containers for services with similar demand trends are not grouped together.

[0297] As explained above, the management server 201 according to Embodiment 3 allows for the grouping of spare containers for services with similar service content and demand trends. This enables the management server 201 to rapidly increase resources and reduce power consumption by reducing the number of ICT resources that need to be powered on in advance.

[0298] (Example 4) Next, we will describe Example 4 of the management server 201. Example 4 describes a case in which backup backup containers are classified so that the amount of resources allocated to backup backup containers does not exceed the upper limit, and backup backup containers used at the same time are not grouped together.

[0299] The following describes an example of operation according to Example 4. However, the container configuration for providing the service to be deployed is the same as in Example 3 (see Figure 30). Also, the service deployment and resource enhancement in Example 4 are the same as in Example 1, so the illustrations and explanations are omitted. Here, we will describe an example of operation when preparing a backup container according to Example 4.

[0300] First, we will explain resource limit information using Figure 36.

[0301] Figure 36 is an explanatory diagram showing a specific example of resource limit information 3600. In Figure 36, resource limit information 3600 represents the upper limit of the amount of resources that can be allocated to the backup container. Here, the upper limit for CPUs that can be allocated to the backup container is 4, and the upper limit for GPUs is 3.

[0302] The following describes an example of operation according to Example 4.

[0303] The second calculation unit 505 calculates the backup container configuration for providing services A, B, and C based on the service configuration information 3000 shown in Figure 30. Specifically, for example, the second calculation unit 505 decides to generate backup containers A1b and A2c with the same performance as containers A1a and A2a that execute applications A1 and A2 at each stage of service A.

[0304] Furthermore, the second calculation unit 505 decides to generate backup containers B1b and B2b with the same performance as containers B1a and B2a that execute applications B1 and B2 at each stage of service B. The second calculation unit 505 also decides to generate backup containers C1b and C2b with the same performance as containers C1a and C2a that execute applications C1 and C2 at each stage of service C. The backup container configuration is stored in container management information 3700, for example, as shown in Figure 37.

[0305] Figure 37 is an explanatory diagram showing an example of the changes in the contents of the container management information 3700. In Figure 37, the container management information 3700 shows the resource allocation results and operating status of each container related to the provision of services A, B, and C. In the container management information 3700 shown in (37-1), spare containers A1b, A2c, B1b, B2b, C1b, and C2b have been added.

[0306] Next, the second calculation unit 505 classifies the reserve containers A1b, A2c, B1b, B2b, C1b, and C2b based on the resource limit information 3600 and the service configuration information 3000. Specifically, for example, the second calculation unit 505 classifies the reserve containers A1b to C2b so that the amount of resources allocated to the reserve containers A1b to C2b does not exceed the limit, and so that reserve containers corresponding to containers providing services with the same demand trend do not belong to the same group.

[0307] Here, using Figure 38, we will explain an example of the classification of the spare containers A1b, A2c, B1b, B2b, C1b, and C2b.

[0308] Figure 38 is an explanatory diagram showing a fourth classification example of spare containers. In Figure 38, spare containers A1b, A2c, B1b, B2b, C1b, and C2b are spare containers for providing services A, B, and C.

[0309] First, the second calculation unit 505 sorts the spare containers A1b to C2b in order of the amount of resources they require, based on the application performance / resource information 3100 shown in Figure 31. For example, let's say the amount of resources required is represented by the number of resources. In this case, spare container B1b requires a total of 3 resources. Also, spare containers A1b, A2c, B2b, and C2b require a total of 2 resources each. And spare container C1b requires a total of 1 resource.

[0310] Next, the second calculation unit 505, based on the service configuration information 3000 shown in Figure 30, groups the sorted spare containers B1b, A1b, A2c, B2b, C2b, and C1b in order so that spare containers for services with the same demand trend do not end up in the same group, provided that the resource amount does not exceed the upper limit.

[0311] For example, the second calculation unit 505 assigns the spare container B1b to group G1. At this point, the total resource amount is "CPU: 2, GPU: 1". Next, the demand trend for spare container A1b is different from that of spare container B1b. Also, even if resources are assigned to spare container A1b in the same way as spare container B1b, the total resource amount will not change. For this reason, the second calculation unit 505 assigns spare container A1b to the same group G1 as spare container B1b. At this point, the total resource amount is "CPU: 2, GPU: 1".

[0312] Next, the demand trend for the backup container A2c is the same as that of the backup container A1b. Also, even if resources are allocated to the backup container A2c without duplication, the total resource amount will not exceed the upper limit. For this reason, the second calculation unit 505 assigns the backup container A2c to a different group G2 than the backup container A1b. At this point, the total resource amount is "CPU: 3, GPU: 2".

[0313] Next, the demand trend for spare container B2b is the same as that of spare container B1b. Also, even if resources are allocated to spare container B2b in the same way as spare container A2c in group G2, the total amount of resources will not change. For this reason, the second calculation unit 505 assigns spare container B2b to a different group G2 than spare container B1b.

[0314] Next, the demand trend for the spare container C2b is the same as that of spare containers A1b and A2c. Also, even if resources are allocated to spare container C2b without overlap, the total resource amount will not exceed the upper limit. For this reason, the second calculation unit 505 assigns spare container C2b to group G3, which is different from spare containers A1b and A2c. At this point, the total resource amount is "CPU: 4, GPU: 3".

[0315] Next, the demand trend for reserve container C1b is the same as that of reserve containers A1b, A2c, and C2b. However, if resources are allocated to reserve container C1b without overlap, the total amount of resources will exceed the upper limit. Therefore, the second calculation unit 505 allocates reserve container C1b to group G1. Here, although the demand trend for reserve container C1b is the same as that of reserve container A1b in group G1, a new group is not created because the required amount of resources exceeds the upper limit.

[0316] The second calculation unit 505 may also allocate the spare container C1b to group G2. Alternatively, the second calculation unit 505 may decide which of the existing groups G1 and G2 to allocate the spare container C1b to, for example, in a way that does not increase the maximum number of containers within groups G1 and G2.

[0317] As a result, the second calculation unit 505 can group the spare containers A1b, A2c, B1b, B2b, C1b, and C2b so that spare containers for services with similar demand trends do not end up in the same group, provided that the amount of resources does not exceed the upper limit.

[0318] Next, the second calculation unit 505 allocates resources redundantly to the spare containers within the classified groups G1 to G3 so that resources are shared among the spare containers within those groups. Specifically, for example, first, the second calculation unit 505 calculates the required resource amount for each group G1 to G3 from the amount of resources (required resources) to be allocated to the spare containers within the groups G1 to G3.

[0319] Here, the required resources for the backup container B1b within group G1 are "CPU: 2, GPU: 1". The required resources for the backup container A1b within group G1 are "CPU: 2". The required resources for the backup container C1b within group G1 are "CPU: 1". Therefore, when sharing resources among the backup containers within group G1, the required resources for group G1 become "CPU: 2, GPU: 1" (see Figure 38).

[0320] Furthermore, the resource requirements for the backup container A2c within group G2 are "CPU: 1, GPU: 1". The resource requirements for the backup container B2b within group G2 are "CPU: 1, GPU: 1". Therefore, when sharing resources among the backup containers within group G2, the total resource requirements for group G2 become "CPU: 1, GPU: 1" (see Figure 38).

[0321] Furthermore, the resource requirements for the backup container C2b within group G3 are "CPU: 1, GPU: 1". Therefore, the total resource requirements for group G3 are "CPU: 1, GPU: 1" (see Figure 38).

[0322] Next, the second calculation unit 505 determines the resources to be allocated to each group G1 to G3 based on the required resource amounts for each group G1 to G3. Specifically, for example, the second calculation unit 505 allocates available resources equal to the required resource amounts to groups G1 to G3. In this case, CPU 10, CPU 11, and GPU 6 are allocated to group G1. CPU 12 and GPU 7 are allocated to group G2. CPU 13 and GPU 8 are allocated to group G3.

[0323] The second calculation unit 505 then allocates resources redundantly to the spare containers within each group G1 to G3 so that resources are shared among the spare containers within each group G1 to G3.

[0324] Here, CPU10, CPU11, and GPU6 are allocated to the spare container B1b within group G1 (see Figure 38). CPU10 and CPU11 are allocated to the spare container A1b within group G1 (see Figure 38). CPU10 is allocated to the spare container C1b within group G1 (see Figure 38). CPU10 is duplicated across spare containers A1b, B1b, and C1b. CPU11 is duplicated across spare containers A1b and B1b.

[0325] Additionally, CPU12 and GPU7 are allocated to the spare container A2c within group G2 (see Figure 38). CPU12 and GPU7 are also allocated to the spare container B2b within group G2 (see Figure 38). CPU12 and GPU7 are duplicated and allocated to spare containers A2c and B2b.

[0326] Additionally, CPU13 and GPU8 are allocated to the spare container C2b within group G3 (see Figure 38).

[0327] As a result, as shown in (37-2) of Figure 37, the CPU number and GPU number of the resources assigned to each of the reserve containers A1b, A2c, B1b, B2b, C1b, and C2b are added to the container management information 3700.

[0328] Next, the power management unit 503 powers on the resources allocated to each of the spare containers A1b, A2c, B1b, B2b, C1b, and C2b. Then, the deployment unit 504 deploys the spare containers A1b, A2c, B1b, B2b, C1b, and C2b for providing each of the services A, B, and C. As a result, as shown in (37-3) of Figure 37, the status of each of the spare containers A1b, A2c, B1b, B2b, C1b, and C2b in the container management information 3700 is set to "Spare".

[0329] Here, using Figure 39, we will explain the resource usage status allocated to the containers (including backup containers) used to provide services A, B, and C.

[0330] Figure 39 is an explanatory diagram showing the resource usage status according to Example 4. In Figure 39, CPU1 to CPU16 and GPU1 to GPU10 in the operational server 202 represent resources that can be allocated to containers (including spare containers). Note that in Figure 39, operational server 202 represents one or more operational servers 202.

[0331] In the example shown in Figure 39, the resource usage status of containers A1a to C2a is "Power ON (In Use)". The resource usage status of reserve containers A1b to C2b is "Power ON (Unused)". In addition, the resource usage status of resources other than those assigned to containers A1a to C2a and reserve containers A1b to C2b is "Power OFF".

[0332] (Resource management processing procedure for management server 201) Next, the specific processing procedure for the resource management process of the management server 201 according to Example 4 will be described. However, except for the first grouping process in step S2202 shown in Figure 22, the specific processing procedure for the resource management process of the management server 201 according to Example 1 is the same. For this reason, only the specific processing procedure for the fourth grouping process, which is executed instead of the first grouping process in step S2202, will be described here.

[0333] Figures 40 and 41 are flowcharts illustrating an example of the specific processing procedure for the fourth grouping process. In the flowchart of Figure 40, first, the management server 201 sorts the spare containers for backup in descending order of required resources (step S4001). Next, the management server 201 sequentially selects the unselected spare containers from the sorted spare containers (step S4002).

[0334] Then, the management server 201 identifies the service demand trends of the selected spare containers based on the service configuration information (step S4003). Next, the management server 201 determines whether or not there are any unverified groups (step S4004). If there are unverified groups (step S4004: Yes), the management server 201 selects the unverified groups (step S4005).

[0335] Next, the management server 201 identifies the demand trends for the services of the spare containers within the group (step S4006). Then, the management server 201 determines whether the identified services have the same demand trends as those identified in step S4003 (step S4007).

[0336] If the demand trends are the same (step S4007: Yes), the management server 201 returns to step S4004. On the other hand, if the demand trends are different (step S4007: No), the management server 201 identifies the increase in resource usage when the selected spare container is added to the selected group (step S4008).

[0337] Then, the management server 201 calculates the total resource amount by adding the calculated increase in resource amount to the current total resource amount (step S4009). Next, the management server 201 refers to the resource limit information to determine whether the calculated total resource amount exceeds the limit (step S4010).

[0338] If the limit is exceeded (step S4010: No), the management server 201 returns to step S4004. On the other hand, if the limit is not exceeded (step S4010: Yes), the management server 201 adds the selected spare container to the selected group (step S4011).

[0339] The management server 201 then determines whether there are any unselected reserve containers among the sorted reserve containers (step S4012). If there are unselected reserve containers (step S4012: Yes), the server returns to step S4002. On the other hand, if there are no unselected reserve containers (step S4012: No), the management server 201 returns to the step that called the fourth grouping process.

[0340] Furthermore, if there are no unconfirmed groups in step S4004 (step S4004: No), the management server 201 proceeds to step S4101 shown in Figure 41.

[0341] In the flowchart of Figure 41, first, the management server 201 identifies the increase in resource usage when the selected spare container is added to the new group (step S4101). Then, the management server 201 calculates the total resource usage by adding the calculated increase in resource usage to the current total resource usage (step S4102).

[0342] Next, the management server 201 refers to the resource limit information and determines whether the calculated total resource amount exceeds the limit (step S4103). If the limit is not exceeded (step S4103: Yes), the management server 201 adds the selected spare container to the new group (step S4104) and returns to step S4012 shown in Figure 40.

[0343] On the other hand, if the upper limit is exceeded (step S4103: No), the management server 201 calculates the increase in resource volume for all groups when the selected spare container is added (step S4105). Then, the management server 201 calculates the total resource volume for each case (step S4106).

[0344] Next, the management server 201 determines whether there are any cases that do not exceed the upper limit based on the total resource amount calculated for each case (step S4107). If there are cases that do not exceed the upper limit (step S4107: Yes), the management server 201 selects one of the groups of cases that do not exceed the upper limit (step S4108).

[0345] Then, the management server 201 adds the selected spare container to the selected group (step S4109) and returns to step S4012 shown in Figure 40. Also, if there are no cases where the upper limit has not been exceeded in step S4107 (step S4107: No), the management server 201 outputs a spare container generation error due to the resource limit (step S4110) and returns to the step that called the fourth group division process. The output destination for the generation error is, for example, the client terminal used by the service provider's user.

[0346] This allows the management server 201 to group spare containers so that spare containers for services with similar demand trends are not grouped together, as long as the amount of resources does not exceed the upper limit.

[0347] As explained above, the management server 201 according to Embodiment 4 allows for grouping of spare containers so that the amount of resources allocated to spare containers does not exceed the upper limit, and so that spare containers for services with similar service content and demand trends are separated. This enables the management server 201 to rapidly increase resources and reduces power consumption by reducing the number of ICT resources that need to be powered on in advance. Embodiments 1 to 4 described above may be combined in a way that is consistent with each other.

[0348] The resource management method described in this embodiment can be implemented by executing a pre-prepared program on a computer such as a personal computer or workstation. This resource management program is recorded on a computer-readable recording medium such as a hard disk, flexible disk, CD-ROM, DVD, or USB memory, and is executed when read from the recording medium by the computer. Furthermore, this resource management program may be distributed via a network such as the Internet.

[0349] Furthermore, the resource management device 101 (management server 201) described in this embodiment can also be implemented using, for example, application-specific ICs such as standard cells and structured ASICs (Application Specific Integrated Circuits), or PLDs (Programmable Logic Devices) such as FPGAs.

[0350] With regard to the embodiments described above, the following additional information is disclosed.

[0351] (Note 1) Based on information representing the characteristics of each of the multiple processing units involved in the provision of one or more services, the backup backup processing units corresponding to each of the multiple processing units are classified such that backup processing units used at the same time do not belong to the same group. To share resources among pre-processors within a classified group, resources are allocated redundantly to pre-processors within the group. A resource management program characterized by having a computer perform the processing.

[0352] (Note 2) The information above represents which of the one or more services each of the plurality of processing devices is a processing device for providing, The aforementioned classification process is, The resource management program according to Appendix 1, characterized in that, based on the aforementioned information, the reserve reserve processing units are classified such that reserve processing units corresponding to processing units for providing the same service do not form the same group.

[0353] (Note 3) The above information represents the load status of each of the multiple processing units, The aforementioned classification process is, The resource management program according to Appendix 1 or 2, characterized by classifying the backup backup processing units such that backup processing units corresponding to those whose processing performance margin is below a threshold are not grouped together, based on the aforementioned information.

[0354] (Note 4) The above information represents the demand trend for the service corresponding to each of the multiple processing devices, The aforementioned classification process is, A resource management program according to any one of the appendices 1 to 3, characterized in that, based on the aforementioned information, the reserve reserve processing devices are classified such that reserve processing devices corresponding to processing devices for providing services with the same demand trend do not belong to the same group.

[0355] (Note 5) The above classification process is A resource management program according to any one of the appendices 1 to 4, characterized in that, based on upper limit information representing the upper limit of the amount of resources that can be allocated to the aforementioned backup backup processing unit, the amount of resources allocated to the aforementioned backup backup processing unit does not exceed the upper limit, and backup backup processing units used at the same time do not belong to the same group.

[0356] (Note 6) The resources that can be allocated to the above-mentioned backup backup processing unit are powered off when not allocated. Of the resources that can be allocated to the aforementioned backup processing unit, power is turned on to the resources allocated to the backup processing unit within the group. A resource management program according to any one of the appendices 1 to 5, characterized in that it causes the computer to perform the processing.

[0357] (Note 7) Of the resources that can be allocated to the backup backup processing unit, set the power supply of resources other than those already allocated to power saving mode. The resource management program according to Appendix 6, characterized in that it causes the computer to perform the processing.

[0358] (Note 8) Each of the above-mentioned multiple processing units is a container or a virtual machine, The aforementioned backup backup processing unit is a backup container or virtual machine. A resource management program characterized by any one of the appendices 1 to 7.

[0359] (Note 9) The resource management program according to any one of Notes 1 to 8, characterized in that the resource includes at least one of a CPU, memory, storage, and accelerator.

[0360] (Note 10) Based on information representing the characteristics of each of the multiple processing units involved in the provision of one or more services, the backup backup processing units corresponding to each of the multiple processing units are classified such that backup processing units used at the same time do not belong to the same group. To share resources among pre-processors within a classified group, resources are allocated redundantly to pre-processors within the group. A resource management method characterized by having a computer perform the processing.

[0361] (Note 11) Based on information representing the characteristics of each of the multiple processing units involved in the provision of one or more services, the backup backup processing units corresponding to each of the multiple processing units are classified such that backup processing units used at the same time do not belong to the same group. To share resources among pre-processors within a classified group, resources are allocated redundantly to pre-processors within the group. A resource management device characterized by having a control unit. [Explanation of Symbols]

[0362] 101 Resource management device 110 Feature Information 200 Information Processing Systems 201 Management Server 202 Operational Server 203 Container Management System 210 Network 300 bus 301 CPU 302 memory 303 Disk Drive 304 disks 305 Communication I / F 306 Portable recording medium interface 307 Portable recording media 500 Control Unit 501 Reception Department 502 First calculation unit 503 Power management section 504 Deployment Department 505 Second calculation unit 506 Load monitoring section 1200,3100 App performance / resource information 1300,2500,3000 Service Configuration Information 1400 Resource allocation status information 1500, 2600, 3200, 3700 Container Management Information 3600 Resource Limit Information

Claims

1. Based on information representing the characteristics of each of the multiple processing units involved in the provision of one or more services, the backup backup processing units corresponding to each of the multiple processing units are classified such that backup processing units used at the same time do not belong to the same group. To share resources among pre-processors within a classified group, resources are allocated redundantly to pre-processors within the group. Let the computer perform the process, The aforementioned information represents the load status of each of the multiple processing units, The aforementioned classification process is, Based on the above information, the backup backup processing units are classified such that backup processing units whose processing performance margin falls below a threshold are not grouped together. A resource management program characterized by the following features.

2. The information described above represents that each of the plurality of processing units is a processing unit related to the provision of one or more of the services described above. The aforementioned classification process is, The resource management program according to claim 1, characterized in that, based on the aforementioned information, the reserve reserve processing units are classified such that reserve processing units corresponding to processing units for providing the same service do not belong to the same group.

3. The information is information representing the demand trend for the service corresponding to each of the plurality of processing devices, The aforementioned classification process is, The resource management program according to claim 1, characterized in that, based on the aforementioned information, the reserve reserve processing devices are classified such that reserve processing devices corresponding to processing devices for providing services with the same demand trend do not belong to the same group.

4. The classification process is, The resource management program according to claim 1, characterized in that, based on upper limit information representing the upper limit of the amount of resources that can be allocated to the aforementioned backup backup processing unit, the amount of resources allocated to the aforementioned backup backup processing unit does not exceed the upper limit, and the backup backup processing units used at the same time do not belong to the same group.

5. The resources that can be allocated to the backup backup processing unit are powered off when they are not allocated, Of the resources that can be allocated to the aforementioned backup processing unit, power is turned on to the resources allocated to the backup processing unit within the group. The resource management program according to claim 1, characterized in that it causes the computer to perform the processing.

6. Based on information representing the characteristics of each of the multiple processing units for providing one or more services, the backup backup processing units corresponding to each of the multiple processing units are classified such that backup processing units used at the same time do not belong to the same group. To share resources among pre-processors within a classified group, resources are allocated redundantly to pre-processors within the group. The computer performs the process, The aforementioned information represents the load status of each of the multiple processing units, The aforementioned classification process is, Based on the above information, the backup backup processing units are classified such that backup processing units whose processing performance margin falls below a threshold are not grouped together. A resource management method characterized by the following:

7. Based on information representing the characteristics of each of the multiple processing units for providing one or more services, the backup backup processing units corresponding to each of the multiple processing units are classified such that backup processing units used at the same time do not belong to the same group. To share resources among pre-processors within a classified group, resources are allocated redundantly to pre-processors within the group. It has a control unit, The aforementioned information represents the load status of each of the multiple processing units, The control unit, Based on the above information, the backup backup processing units are classified such that backup processing units whose processing performance margin falls below a threshold are not grouped together. A resource management device characterized by the following features.

8. Based on information representing the characteristics of each of the multiple processing units for providing one or more services, the backup backup processing units corresponding to each of the multiple processing units are classified such that backup processing units used at the same time do not belong to the same group. To share resources among pre-processors within a classified group, resources are allocated redundantly to pre-processors within the group. Let the computer perform the process, The aforementioned information represents the demand trend for the service corresponding to each of the multiple processing devices, The aforementioned classification process is, Based on the above information, the spare spare processing units are classified such that spare processing units corresponding to processing units for providing services with the same demand trend do not belong to the same group. A resource management program characterized by the following features.

9. Based on information representing the characteristics of each of the multiple processing units for providing one or more services, the backup backup processing units corresponding to each of the multiple processing units are classified such that backup processing units used at the same time do not belong to the same group. To share resources among pre-processors within a classified group, resources are allocated redundantly to pre-processors within the group. It has a control unit, The aforementioned information represents the demand trend for the service corresponding to each of the multiple processing devices, The control unit, Based on the above information, the spare spare processing units are classified such that spare processing units corresponding to processing units for providing services with the same demand trend do not belong to the same group. A resource management device characterized by the following features.

Images