Management device, management method, and management program

Abstract

To improve accuracy in determining whether an execution environment is in an idle state.SOLUTION: A management device 101 acquires, for each virtual machine included in idle state candidate virtual machines 102-104, communication information d1-d3 that can identify communication destinations that have communicated with each virtual machine within a predetermined period (for example, the most recent week). Based on the acquired communication information d1-d3, the management device 101 identifies communication destinations "xx.xxx" and "yy.yyy" that have communicated with a predetermined percentage (for example, 90%) or more of virtual machines among the idle state candidate virtual machines 102-104. The management device 101 determines that virtual machines that have communicated only with the identified communication destinations "xx.xxx" and "yy.yyy" within the predetermined period among the idle state candidate virtual machines 102-104 are in an idle state.SELECTED DRAWING: Figure 1

Description

[Technical Field]

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

[0002] In recent years, a new type of cloud called private cloud has emerged, where companies and organizations build cloud environments within their own company and provide them to limited users, such as internal departments and group companies. When building an in-house cloud environment, possessing excessive resources is not desirable from the perspective of cost reduction, so operation with the minimum necessary resources is required. For example, among the virtual machines provided, it is necessary to reduce power consumption by stopping idle virtual machines.

[0003] Prior art includes, for example, a technology for leveling the load of virtual machines. Also, in a VM placement management system, there is a technology for provisioning physical machines in a virtual machine system based on physical configuration graph information, a virtual machine-physical machine correspondence table, a logical network-physical network correspondence table, and inter-VM communication relationship graph information. There is also a technology for determining which virtual machines and data areas, among those communicating with virtual machines, should be transferred in order to suppress an increase in communication volume between the virtual machines and the destination base of the terminal that communicates with the virtual machines, and for determining the virtual machines and data areas to be transferred. [Prior art documents] [Patent documents]

[0004] [Patent Document 1] Japanese Patent Application Laid-Open No. 2014-167713 [Patent Document 2] International Publication No. 2017 / 056238 [Patent Document 3] Japanese Patent Application Laid-Open No. 2018-147344 Summary of the Invention [Problem to be solved by the invention]

[0005] However, with conventional techniques, it is difficult to accurately determine which virtual machines (execution environments) are idle among the virtual machines provided.

[0006] In one aspect, the present invention aims to improve the accuracy of determining whether an execution environment is in an idle state. [Means for solving the problem]

[0007] In one embodiment, a management device is provided that has a control unit that acquires, for each execution environment included in one or more execution environments that are candidates for an idle state, communication information that can identify communication destinations that have communicated with each execution environment within a predetermined period of time, identifies communication destinations that have communicated with a predetermined percentage or more of the one or more execution environments based on the acquired communication information, and determines that an execution environment among the one or more execution environments that has communicated only with the identified communication destinations within the predetermined period is in an idle state. [Effects of the Invention]

[0008] Advantageous Effects of Invention According to one aspect of the present invention, it is possible to improve the accuracy of determining whether an execution environment is in an idle state. [Brief explanation of the drawings]

[0009] [Figure 1] FIG. 1 is an explanatory diagram illustrating an example of a management method according to an embodiment. [Figure 2] FIG. 2 is an explanatory diagram showing an example of the system configuration of the information processing system 200. As shown in FIG. [Figure 3] FIG. 3 is a block diagram showing an example of the hardware configuration of the idle VM determining device 201. As shown in FIG. [Figure 4] FIG. 4 is an explanatory diagram of an example of the contents of the VM list. [Figure 5] FIG. 5 is an explanatory diagram of an example of the contents of the idle VM candidate list. [Figure 6] FIG. 6 is an explanatory diagram of an example of the contents stored in the idle VM candidate packet table. [Figure 7] FIG. 7 is a block diagram showing an example of the functional configuration of the idle VM determining device 201. As shown in FIG. [Figure 8] FIG. 8 is an explanatory diagram showing an example of the connection destination list. [Figure 9] FIG. 9 is an explanatory diagram showing an example of a packet information list of VM1. [Figure 10] FIG. 10 is an explanatory diagram showing an example of a packet information list of VM3. [Figure 11] FIG. 11 is an explanatory diagram illustrating an example of an idle VM list. [Figure 12] FIG. 12 is a flowchart (part 1) illustrating an example of a management procedure of the idle VM determining device 201. [Figure 13] FIG. 13 is a second flowchart illustrating an example of the management procedure of the idle VM determining device 201. [Figure 14] FIG. 14 is a flowchart (part 3) illustrating an example of the management procedure of the idle VM determining device 201. [Figure 15] FIG. 15 is an explanatory diagram showing a specific example of server data. [Figure 16] FIG. 16 is an explanatory diagram illustrating a specific example of VM data. [Figure 17] FIG. 17 is an explanatory diagram showing a specific example of performance data. [Figure 18] FIG. 18 is an explanatory diagram showing a specific example of the aggregated performance data. [Figure 19] FIG. 19 is an explanatory diagram showing an example of the priority setting rules. [Figure 20] FIG. 20 is an explanatory diagram (part 1) showing an example of the procedure data to be generated. [Figure 21] FIG. 21 is an explanatory diagram (part 2) showing an example of generated procedure data. [Figure 22] FIG. 22 is an explanatory diagram (part 3) showing an example of generated procedure data. DETAILED DESCRIPTION OF THE INVENTION

[0010] DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS Hereinafter, with reference to the accompanying drawings, a management apparatus, a management method, and a management program according to embodiments of the present invention will be described in detail.

[0011] (Embodiment) 1 is an explanatory diagram showing an example of a management method according to an embodiment. In FIG. 1, a management device 101 is a computer that determines an execution environment in an idle state. Here, the execution environment is an environment for executing programs and software (such as an OS (Operating System), applications, etc.).

[0012] The execution environment may be, for example, a virtual machine (VM). A virtual machine is a virtual computer that runs in an environment constructed by dividing the hardware resources of a physical computer. The execution environment may also be a container. A container corresponds to a user space that is isolated from others and is created by dividing the kernel of an OS internally, and runs as one of the OS processes. The execution environment may also be the physical server itself.

[0013] Each execution environment is deployed based on, for example, a template. The template includes an OS and applications. Execution environments deployed using the same template share a common connection destination for, for example, updating the OS or applying security rules. Execution environments are provided to users, for example, and used for business processing, computational processing, and the like.

[0014] An idle state is a state in which an environment is available but not currently executing a process. Examples of processes include operational processes and computational processes executed in response to commands. Even when an environment is idle, it consumes power. From an energy conservation perspective, it is preferable to shut down idle environments whenever possible.

[0015] For example, when building a private cloud, it is important to operate it with minimal resources. However, among the virtual machines (execution environments) provided, there are virtual machines (idle state) that are not being used and occupy resources but are not stopped. For this reason, it is necessary to stop idle virtual machines to reduce power consumption.

[0016] Here, there is a conventional technique in which a virtual machine that does not execute processing is deployed separately from the virtual machine provided to the user, and performance data between the virtual machine that does not execute processing and the virtual machine being provided is compared to determine whether the virtual machine being provided is in an idle state. Performance data includes, for example, CPU (Central Processing Unit) usage, disk I / O data volume, and network data transfer volume. For example, Japanese Patent Application Laid-Open No. 2014-191368 can be referred to as an example of the conventional technique.

[0017] However, conventional techniques may not be able to accurately determine whether an execution environment such as a virtual machine is idle. For example, in recent years, development has increasingly involved the use of "virtual machines or services that actually perform processing" and "virtual machines that instruct the virtual machines or services that actually perform processing to execute processing."

[0018] This type of configuration is used, for example, when software development is carried out by introducing CI (Continuous Integration) / CD (Continuous Delivery) tools. The "virtual machine that commands the virtual machine or service that actually performs the processing to execute the processing" commands the execution of the processing, and the performance data characteristics are different from those of the "virtual machine or service that actually performs the processing."

[0019] On the other hand, commands to execute processes are expected to be issued infrequently, for example, once a day. Therefore, the performance data of "a virtual machine that commands the virtual machines or services that actually perform the processes to execute processes" is often similar to the performance data of a virtual machine in an idle state. For this reason, conventional technologies may erroneously determine that "a virtual machine that commands the virtual machines or services that actually perform the processes to execute processes" is in an idle state.

[0020] "Virtual machines that issue commands to virtual machines and services that actually perform processing" are virtual machines that should always be running. However, if "virtual machines that issue commands to virtual machines and services that actually perform processing" are determined to be idle, they may be stopped to reduce power consumption. If "virtual machines that issue commands to virtual machines and services that actually perform processing" are stopped, the processing that should be executed will not be carried out, resulting in problems such as service outages.

[0021] Therefore, in this embodiment, a management method for improving the accuracy of determining whether an execution environment is in an idle state will be described. Here, an example of processing by management device 101 (corresponding to the following processing (1) to (3)) will be described.

[0022] In the following description, unless otherwise specified, a "virtual machine" will be used as an example of the execution environment for determining the idle state.

[0023] (1) The management apparatus 101 acquires communication information for each virtual machine included in one or more virtual machines that are candidates for an idle state, the communication information being capable of identifying a communication destination that has communicated with each virtual machine within a predetermined period. Here, the virtual machines that are candidates for an idle state are virtual machines that are candidates for an idle state.

[0024] The one or more virtual machines that are candidates for the idle state are, for example, one or more virtual machines whose performance data is similar to that of a virtual machine in the idle state. The virtual machines that are candidates for the idle state are identified, for example, from among the virtual machines that are provided to users. The virtual machines that are candidates for the idle state may be identified using existing technology (for example, Japanese Patent Application Laid-Open No. 2014-191368).

[0025] Specifically, for example, virtual machines that are candidates for the idle state are identified by comparing information about the operation of the virtual machine being provided with information about the operation of a virtual machine (not shown) that is not executing processing. Information about the operation of the virtual machine includes, for example, CPU usage, memory usage, I / O data volume of a disk device, data transfer volume over a network, etc. However, virtual machines that are candidates for the idle state may also be manually designated by, for example, a system administrator.

[0026] The predetermined period can be set arbitrarily, for example, to a period of about one week to one month in the past. The communication information may be, for example, packet information transmitted from each virtual machine within the predetermined period, or may be packet information received by each virtual machine. Furthermore, the communication information may be both packet information transmitted from each virtual machine and packet information received by each virtual machine within the predetermined period.

[0027] In the example of FIG. 1, virtual machines provided to users are referred to as "virtual machines 102-107." One or more virtual machines that are candidates for idle state are referred to as "virtual machines 102-104 (enclosed in a dotted line in FIG. 1)." The virtual machines 102-104 that are candidates for idle state are identified from among the virtual machines 102-107, for example, by comparing information about the operation of each virtual machine 102-107 with information about the operation of a virtual machine (not shown) that is not executing processing. The virtual machines 105-107 correspond to, for example, "virtual machines or services that actually perform processing."

[0028] In this case, the management apparatus 101 acquires communication information d1 to d3 of each of the virtual machines 102 to 104 that are idle state candidates. The communication information d1 is information that can identify a communication destination that has communicated with the virtual machine 102 within a predetermined period of time. The communication information d2 is information that can identify a communication destination that has communicated with the virtual machine 103 within a predetermined period of time. The communication information d3 is information that can identify a communication destination that has communicated with the virtual machine 104 within a predetermined period of time.

[0029] The virtual machines 102 to 104 that are candidates for an idle state may include not only "virtual machines in an idle state" but also "virtual machines that actually perform processing or virtual machines that issue instructions to execute processing to services."

[0030] (2) Based on the acquired communication information d1 to d3, the management device 101 identifies communication destinations that have communicated with a predetermined percentage or more of the idle state candidate virtual machines 102 to 104. The predetermined percentage can be set arbitrarily, for example, to about 90%.

[0031] Here, "idle virtual machines" do communicate for OS updates, security rule application, etc., but because they are not executing any processes, other communications generally do not take place. Also, because the virtual machines provided are created by duplicating templates, the communication destinations for OS updates, security rule application, etc. are the same.

[0032] Therefore, it can be said that the communication destination of an "idle virtual machine" is basically the same. On the other hand, the communication destination of a "virtual machine that issues commands to execute processes to virtual machines or services that actually execute processes" differs from that of an "idle virtual machine" because it issues commands to execute processes.

[0033] In the example of FIG. 1, from the communication information d1 of the virtual machine 102, which is an idle state candidate, the communication destinations "xx.xxx," "yy.yyy," "xx.xxx," and "yy.yyy" are identified in the order in which the virtual machine 102 communicated within a predetermined period. Also, from the communication information d2 of the virtual machine 103, which is an idle state candidate, the communication destinations "yy.yyy," "xx.xxx," and "yy.yyy" are identified in the order in which the virtual machine 103 communicated within a predetermined period. Also, from the communication information d3 of the virtual machine 104, which is an idle state candidate, the communication destinations "xx.xxx," "zz.zzz," "yy.yyy," and "xx.xxx" are identified in the order in which the virtual machine 104 communicated within a predetermined period.

[0034] For example, the management device 101 creates communication ratio information 110 based on the acquired communication information d1 to d3. The communication ratio information 110 indicates the ratio of virtual machines that communicated with each communication destination among the idle state candidate virtual machines 102 to 104. Since the communication destination "xx.xxx" communicates with all of the idle state candidate virtual machines 102 to 104, the ratio is "100% (= 3 / 3 × 100)".

[0035] Similarly, the communication destination "yy.yyy" communicates with all of the idle state candidate virtual machines 102 to 104, so the percentage is "100% (= 3 / 3 x 100)." On the other hand, the communication destination "zz.zzz" communicates with only virtual machine 104 of the idle state candidate virtual machines 102 to 104, so the percentage is "33% (= 1 / 3 x 100)."

[0036] Here, the predetermined percentage is assumed to be "90%." In this case, the management device 101 refers to the communication percentage information 110 and identifies the communication destinations "xx.xxx" and "yy.yyy" that communicate with 90% or more of the virtual machines 102 to 104 that are candidates for idle state. Since the communication destinations "xx.xxx" and "yy.yyy" communicate with all the virtual machines, they can be said to be communication destinations when updating the OS, applying security rules, etc.

[0037] (3) The management apparatus 101 determines that, among the virtual machines 102 to 104 that are candidates for an idle state, the virtual machines that have communicated only with the identified communication destinations "xx.xxx" and "yy.yyy" within a predetermined period are in an idle state.

[0038] Here, according to communication information d1, virtual machine 102 communicates only with communication destinations "xx.xxx" and "yy.yyy" within a predetermined period. Also, according to communication information d2, virtual machine 103 communicates only with communication destinations "xx.xxx" and "yy.yyy" within a predetermined period. Meanwhile, according to communication information d3, virtual machine 104 communicates not only with communication destinations "xx.xxx" and "yy.yyy" but also with communication destination "zz.zzz" within a predetermined period.

[0039] For this reason, the management device 101 determines that the virtual machines 102 and 103 are in an idle state. The virtual machine 104 communicates not only with the communication destinations "xx.xxx" and "yy.yyy" but also with the communication destination "zz.zzz", and may be "a virtual machine that issues commands to execute processing to virtual machines or services that actually perform processing." The management device 101 does not determine that the virtual machine 104 is in an idle state.

[0040] In this way, the management device 101 can improve the accuracy of determining which virtual machines (execution environments) are in an idle state. For example, the management device 101 can identify common communication destinations to connect to for performing OS updates, application of security rules, etc., from the communication destinations of each of the virtual machines 102 to 104 that are candidates for an idle state.

[0041] The virtual machines (virtual machines 102 and 103) that communicate only with a common communication destination are virtual machines that only perform communications related to operation management such as adding OS functions, correcting defects, strengthening security, etc. Therefore, the management device 101 can determine that the virtual machines that communicate only with a common communication destination are in an idle state.

[0042] This allows the management device 101 to prevent erroneous determination that "a virtual machine that commands a virtual machine or service that actually performs processing to execute a process" is in an idle state. In the example of FIG. 1, the virtual machine 104 that is communicating with destinations other than the common destination can be said to be "a virtual machine that commands a virtual machine or service that actually performs processing to execute a process." The management device 101 can distinguish "a virtual machine that commands a virtual machine or service that actually performs processing to execute a process," which could not be distinguished by conventional technology because the performance data was similar.

[0043] (System configuration example of information processing system 200) Next, a system configuration example of an information processing system 200 including the management device 101 shown in Fig. 1 will be described. Here, the case where the management device 101 shown in Fig. 1 is applied to an idle VM determination device 201 in the information processing system 200 will be described as an example. The information processing system 200 is applied to, for example, a service that provides a private cloud system.

[0044] 2 is an explanatory diagram illustrating an example of a system configuration of an information processing system 200. In FIG. 2, the information processing system 200 includes an idle VM determining device 201, a plurality of processing devices 202, and a packet capturing device 203. In the information processing system 200, the idle VM determining device 201, the processing devices 202, and the packet capturing device 203 are connected via a wired or wireless network 210. The network 210 may be, for example, the Internet, a local area network (LAN), or a wide area network (WAN).

[0045] Here, the idle VM determination device 201 is a computer that determines whether a virtual machine (execution environment) is idle. Here, a "virtual machine" is used as an example of the execution environment for determining whether the execution environment is idle, but the execution environment is not limited to this. For example, the idle VM determination device 201 may determine whether a container is idle, or whether a processing device 202 (physical server) is idle. The idle VM determination device 201 is, for example, a physical server.

[0046] The processing device 202 is a computer capable of executing a virtual machine. The processing device 202 may also be capable of executing a container. The processing device 202 creates a virtual machine (or a container) on its own device, for example, by duplicating a template created in advance.

[0047] The template includes an OS and applications. VMs (or containers) created using the same template share a common connection destination for OS updates, security rule application, and the like. The processing device 202 also has a function for managing the virtual machines (or containers) running on its own device. The processing device 202 is, for example, a physical server.

[0048] In the following description, multiple virtual machines operating on the processing device 202 may be referred to as "VM1 to VMn" (n: a natural number equal to or greater than 2). Also, any one of the virtual machines VM1 to VMn may be referred to as "VMi" (i=1, 2, ..., n).

[0049] The packet capture device 203 is a computer that captures packet information transmitted from each VMi. The packet capture device 203 may capture packet information received by each VMi. Specifically, for example, the packet capture device 203 utilizes a mirroring function of a switch (not shown) to capture packet information of each VMi flowing through the network 210.

[0050] Although the idle VM determination device 201 and the processing device 202 are provided separately here, this is not limiting. For example, the idle VM determination device 201 may be realized by the processing device 202 or a dedicated VM on the processing device 202. Although not shown in the drawings, the information processing system 200 also includes a computer (administration terminal) used by a system administrator and a computer (user terminal) used by a user of the VMi.

[0051] (Example of Hardware Configuration of Idle VM Determining Device 201) Next, an example of the hardware configuration of the idle VM determining device 201 will be described.

[0052] 3 is a block diagram showing an example of the hardware configuration of the idle VM determination device 201. In FIG. 3, the idle VM determination device 201 includes a CPU 301, a memory 302, a disk drive 303, a disk 304, a communication I / F (Interface) 305, a portable recording medium I / F 306, and a portable recording medium 307. The components are connected to each other via a bus 300.

[0053] Here, the CPU 301 controls the entire idle VM determination device 201. The CPU 301 may have multiple cores. The memory 302 includes, for example, a read-only memory (ROM) and a random access memory (RAM). A program stored in the memory 302 is loaded into the CPU 301, causing the CPU 301 to execute coded processing.

[0054] The disk drive 303 controls reading / writing of data from / to the disk 304 under the control of the CPU 301. The disk 304 stores data written under the control of the disk drive 303. The disk 304 is, for example, a magnetic disk, an optical disk, or the like.

[0055] The communication I / F 305 is connected to the network 210 via a communication line, and is connected to an external computer (for example, the processing device 202, packet capturing device 203, and VM1 to #n shown in FIG. 2) via the network 210. The communication I / F 305 serves as an interface between the network 210 and the inside of the device, and controls input and output of data from and to the external computer. The communication I / F 305 is, for example, a modem or a LAN adapter.

[0056] The portable recording medium I / F 306 controls reading and writing of data from and to the portable recording medium 307 under the control of the CPU 301. The portable recording medium 307 stores data written under the control of the portable recording medium I / F 306. The portable recording medium 307 is, for example, a CD (Compact Disc)-ROM, a DVD (Digital Versatile Disk), or a USB (Universal Serial Bus) memory.

[0057] In addition to the above-described components, the idle VM determination device 201 may also include, for example, an input device and a display. Furthermore, the idle VM determination device 201 may not necessarily include, for example, the portable recording medium I / F 306 and the portable recording medium 307. The processing device 202 and the packet acquisition device 203 shown in FIG. 2 can also be realized by the same hardware configuration as the idle VM determination device 201.

[0058] (Memory contents of VM list 400) 4, the contents of the VM list 400 stored in the idle VM determination device 201 will be described. The VM list 400 is stored in a storage device such as the memory 302 or the disk 304. The VM list 400 may be created for each processing device 202, for example.

[0059] 4 is an explanatory diagram showing an example of the contents of a VM list. In FIG. 4, a VM list 400 shows the VM name and IP address of the VM i provided. Here, the VM name indicates the name of the VM i. The IP address indicates the IP address that identifies the VM i.

[0060] The provider of the VMi is the system administrator of the information processing system 200 (for example, a private cloud system), and the recipient of the VMi is the user of the VMi.

[0061] (Memory contents of the list of 500 idol VM candidates) Next, the contents of the idle VM candidate list 500 stored in the idle VM determination device 201 will be described with reference to FIG. 5. The idle VM candidate list 500 is stored in a storage device such as the memory 302 or the disk 304. The idle VM candidate list 500 may be created for each processing device 202, for example.

[0062] FIG. 5 is an explanatory diagram showing an example of the contents of an idle VM candidate list. In FIG. 5, the idle VM candidate list 500 shows the VM names and IP addresses of idle state candidate VMs. Here, the VM name indicates the name of the idle state candidate VM. The IP address indicates the IP address that identifies the idle state candidate VM. In the example of FIG. 5, the idle state candidate VMs are "VM1, VM2, VM3."

[0063] (Storage contents of the idle VM candidate packet table 600) Next, the contents stored in the idle VM candidate packet table 600 of the idle VM determining device 201 will be described with reference to Fig. 6. The idle VM candidate packet table 600 is stored in a storage device such as the memory 302 or the disk 304. The idle VM candidate packet table 600 may be created for each processing device 202, for example.

[0064] 6 is an explanatory diagram showing an example of the contents of an idle VM candidate packet table. In FIG. 6, an idle VM candidate packet table 600 stores packet information (for example, packet information 600-1 to 600-5) of idle state candidate VMs. The packet information includes a date and time, a source IP address, and a destination IP address.

[0065] Here, the date and time indicates the date and time when the packet was transmitted from the idle state candidate VM. The source IP address indicates the IP address of the idle state candidate VM, which is the source of the packet. The destination IP address indicates the IP address to which the packet transmitted from the idle state candidate VM is destined.

[0066] For example, the packet information 600-1 includes the date and time "2023 / 4 / 28 9:00", the source IP address "10.100.100.101", and the destination IP address "10.100.100.104" of a packet transmitted from VM1, which is an idle state candidate.

[0067] (Example of Functional Configuration of Idle VM Determining Device 201) Next, an example of the functional configuration of the idle VM determining device 201 will be described.

[0068] 7 is a block diagram showing an example of the functional configuration of the idle VM determination device 201. In FIG. 7, the idle VM determination device 201 includes an acquisition unit 701, an identification unit 702, a determination unit 703, a stopping unit 704, and an output unit 705. The acquisition unit 701 to the output unit 705 are functions of the control unit 700, and specifically, the functions are realized by causing the CPU 301 to execute a program stored in a storage device such as the memory 302, the disk 304, or the portable recording medium 307 shown in FIG. 3, or by the communication I / F 305. The processing results of each functional unit are stored in a storage device such as the memory 302 or the disk 304.

[0069] The acquiring unit 701 acquires performance data of a first VM (execution environment) deployed in a system and performance data of VMs other than the first VM deployed in the system. Here, the system is a computer system in which an execution environment (VM, container) is constructed, such as the processing device 202 shown in FIG. 2.

[0070] The first VM is a VM that does not execute any processing (idle state). The first VM is different from a VM provided to a user and is deployed to obtain performance data of a VM in an idle state. The first VM may be deployed to the processing device 202 by the idle VM determination device 201, for example, or may be deployed to the processing device 202 by a computer different from the idle VM determination device 201. VMs other than the first VM are, for example, VM1 to VMn (see FIG. 2) that operate on the processing device 202.

[0071] The performance data of the first VM is information related to the operation of the first VM. The performance data of the VMs other than the first VM is information related to the operation of the VMs other than the first VM. The performance data includes, for example, CPU usage, memory usage, I / O data volume of a disk device, data transfer volume on a network, etc.

[0072] Specifically, for example, the acquiring unit 701 may acquire performance data of the first VM at fixed time intervals during a predetermined period T1 and performance data of VMs other than the first VM by receiving the data from the processing device 202. The predetermined period T1 can be set arbitrarily, for example, to a period of about one week to one month. The fixed period can be set arbitrarily, for example, to a period of about one minute to one hour.

[0073] In the following description, the first VM may be referred to as an "idle VM." Also, assuming that an idle VM (first VM) is placed in the processing device 202, VMs other than the idle VM (first VM) may be referred to as "VM1 to VMn." VM1 to VMn are identified, for example, from a VM list 400 as shown in FIG. 4.

[0074] The identifying unit 702 compares the acquired performance data of the idle VM with the performance data of VM1 to VMn to identify one or more VMs that are idle state candidates from among VM1 to VMn. Specifically, for example, the identifying unit 702 calculates a threshold value for determining whether or not a VM is an idle state candidate from the performance data of the idle VM.

[0075] The identifying unit 702 then identifies one or more VMs as idle state candidates by determining whether the numerical values ​​included in the performance data of VM1 to VMn exceed the calculated threshold. The threshold may be calculated, for example, by multiplying the numerical value related to the performance of the idle VM in the predetermined period T1 by a coefficient smaller than 1 (for example, 0.9). Alternatively, the threshold may be calculated by directly using the numerical value related to the performance of the idle VM in the predetermined period T1.

[0076] Performance-related values ​​include, for example, CPU usage, memory usage, I / O data volume of a disk device, data transfer volume over a network, etc. Performance-related values ​​may be, for example, average values ​​over a predetermined period T1, or values ​​at each point in time within the predetermined period T1 (for example, every minute to every hour).

[0077] To explain in more detail, for example, the identification unit 702 may identify, among VM1 to VMn, a VM whose CPU usage rate, memory usage, I / O data volume of the disk device, and data transfer volume on the network (average value or value at each point in time) during a predetermined period T1 are below a threshold as a VM that is a candidate for an idle state.

[0078] Furthermore, the identifying unit 702 may identify, among VM1 to VMn, a VM whose CPU usage rate, memory usage, disk I / O data volume, and network data transfer volume are equal to or less than a threshold value during a predetermined period T1, as a VM that is a candidate for an idle state. Note that which numerical value included in the performance data is compared with the threshold value can be arbitrarily set.

[0079] Information (VM name, IP address) of the identified idle state candidate VM is stored in, for example, an idle VM candidate list 500 as shown in FIG.

[0080] In the following description, "one or more VMs that are candidates for idle state" may be simply referred to as "VMs that are candidates for idle state."

[0081] Furthermore, the acquiring unit 701 acquires, for each VMi included in the idle state candidate VMs, communication information that can identify a communication destination that has communicated with each VMi within a predetermined period T2. The predetermined period T2 can be set arbitrarily, for example, to a period of about one week to one month in the past. The predetermined period T2 may be the same period as the predetermined period T1, or may be a period different from the predetermined period T1.

[0082] Specifically, for example, the acquiring unit 701 identifies the VMs of the identified idle state candidates by referring to the idle VM candidate list 500. Then, the acquiring unit 701 acquires packet information of each VM of the idle state candidates during the predetermined period T2 from the packet acquiring device 203 shown in Fig. 2. The packet information of each VM of the idle state candidates during the predetermined period T2 is packet information in which the date and time are included in the predetermined period T2 and the IP address of each VM of the idle state candidate is set as the source IP address.

[0083] The acquired packet information is stored in, for example, an idle VM candidate packet table 600 as shown in FIG.

[0084] Furthermore, the identifying unit 702 identifies communication destinations that have communicated with VMs that account for a predetermined percentage α or more of the idle state candidate VMs, based on the acquired communication information. Specifically, for example, the identifying unit 702 refers to the idle VM candidate packet table 600 to identify communication destinations that have communicated with at least any VMi of the idle state candidate VMs.

[0085] Next, the identifying unit 702 refers to the idle VM candidate packet table 600 and calculates, for each identified communication destination, a ratio indicating how many VMs among the idle state candidate VMs have communicated. Then, the identifying unit 702 identifies communication destinations for which the calculated ratio is equal to or greater than a predetermined ratio α.

[0086] In the following description, a communication destination that has communicated with a predetermined percentage α or more of VMs among the idle state candidate VMs may be referred to as a “common connection destination.” An example of identifying a common connection destination will be described later with reference to FIG.

[0087] The determination unit 703 determines that, among the VMs of the idle state candidates, a VM that has communicated only with the identified common connection destination within a predetermined period T2 is in the idle state. Specifically, for example, the determination unit 703 refers to the idle VM candidate packet table 600 and, for each VMi included in the VMs of the idle state candidates, identifies a communication destination with which each VMi has communicated within the predetermined period T2. Then, the determination unit 703 determines, among the VMs of the idle state candidates, a VM whose identified communication destination is only a common connection destination as in the idle state.

[0088] Furthermore, the determining unit 703 may determine that a VM that has communicated with a communication destination other than the common connection destination within a predetermined period T2 among the VMs in the idle state candidates is a specific VM that commands other VMs to execute processing. The specific VM corresponds to, for example, "a virtual machine that commands a virtual machine or service that actually executes processing to execute processing."

[0089] An example of determining whether a VM is in an idle state or a specific VM will be described later with reference to FIGS. 9 and 10. FIG.

[0090] The stopping unit 704 performs control to stop the operation of a VM determined to be in an idle state. Specifically, for example, the stopping unit 704 transmits a stop request for the VM determined to be in an idle state to the processing device 202 on which the VM is running. The stop request includes information (for example, a VM name, an IP address) that can identify the VM determined to be in an idle state.

[0091] When the processing device 202 receives a shutdown request from the idle VM determination device 201, the processing device 202 shuts down the VM identified in the shutdown request. Specifically, for example, the processing device 202 stops the supply of power to the VM identified in the shutdown request. After stopping the supply of power to the VM identified in the shutdown request, the processing device 202 may also release hardware resources allocated to the VM.

[0092] The output unit 705 outputs information that can identify a VM determined to be in an idle state. The output format of the output unit 705 may be, for example, storage in a storage device such as the memory 302 or the disk 304, transmission to another computer via the communication I / F 305, display on a display (not shown), or printout on a printer (not shown).

[0093] Specifically, for example, the output unit 705 may transmit the idle VM list to a management terminal (not shown) used by a system administrator. Here, the idle VM list indicates information that can identify each VM determined to be in an idle state. The information that can identify each VM is, for example, the VM name or IP address of each VM.

[0094] This allows the system administrator to take action such as stopping a VM determined to be in an idle state by referring to the idle VM list. A specific example of the idle VM list will be described later with reference to FIG. 11.

[0095] The output unit 705 may also transmit an idle state notification to a user terminal (not shown) used by a user of the VM determined to be in an idle state. Here, the idle state notification notifies that the VM being used is in an idle state, and includes information that can identify each VM determined to be in an idle state.

[0096] This allows users to know that there are idle VMs among the VMs they are using, and they can take action such as reviewing the number of VMs they are using or running additional new processes.

[0097] Furthermore, the output unit 705 may output information indicating the determined specific VM. Specifically, for example, the output unit 705 may transmit a specific VM notification to a management terminal (not shown) used by a system administrator. The specific VM notification includes, for example, the VM name and IP address of the specific VM.

[0098] This allows a system administrator to, for example, refer to a specific VM notification to identify "a virtual machine that commands a virtual machine or service that actually performs processing to execute a process." This allows the system administrator to prevent mistakes such as accidentally stopping "a virtual machine that commands a virtual machine or service that actually performs processing to execute a process."

[0099] The functional units (acquisition unit 701 to output unit 705) of the idle VM determination device 201 may be implemented by, for example, multiple computers (for example, the idle VM determination device 201 and the processing device 202) in the information processing system 200. In this case, communication between the functional units of different computers is performed by, for example, transmission and reception between the functional units via the network 210.

[0100] (Example of Operation of Idle VM Determining Device 201) 8 to 11, an example of the operation of the idle VM determining device 201 will be described. Here, the description will be given taking as an example the VMs of idle state candidates "VM1 to VM3" identified from the idle VM candidate list 500 shown in FIG.

[0101] First, an example of identifying a common connection destination will be described with reference to Fig. 8. Here, it is assumed that the predetermined period T2 is "2023 / 4 / 28 9:00 to 2023 / 5 / 28 9:00", and packet information of each of the idle state candidates VM1 to VM3 during the predetermined period T2 is stored in the idle VM candidate packet table 600 shown in Fig. 6.

[0102] In this case, the idle VM determining device 201 identifies a communication destination with which at least one VMi of the idle state candidates VM1 to VM3 has communicated by referring to the idle VM candidate packet table 600. Information indicating the identified communication destination is stored in, for example, a connection destination list 800 as shown in FIG.

[0103] Fig. 8 is an explanatory diagram showing an example of a connection destination list. In Fig. 8, connection destination list 800 stores IP addresses and connection rates. Here, the IP address is the IP address of a communication destination with which at least one VMi of idle state candidates VM1 to VM3 has communicated. The connection rate indicates the rate of VMs, among idle state candidates VM1 to VM3, that have communicated at least once with a communication destination identified from the IP address.

[0104] 8, the IP addresses "11.111.111.111," "22.222.222.222," "10.100.100.106," "33.333.333.333," and "44.444.444.444" are stored in the connection destination list 800. However, only a portion of the identified communication destinations is shown here.

[0105] Next, the idle VM determining device 201 refers to the idle VM candidate packet table 600 and calculates the connection rate for each IP address in the connection destination list 800. The calculated connection rate for each IP address is stored in the connection destination list 800 in association with the IP address.

[0106] However, in the example of FIG. 8, for ease of explanation, convenient values ​​are shown as connection ratios in the connection destination list 800.

[0107] For example, a connection rate of "100%" is stored in association with the IP address "11.111.111.111." This connection rate of "100%" indicates that all of VM1 to VM3, which are idle state candidates, have communicated with the communication destination of IP address "11.111.111.111."

[0108] Furthermore, a connection rate of "1%" is stored in association with the IP address "33.333.333.333." This connection rate of "1%" indicates that 1% of the idle state candidates VM1 to VM3 communicated with the communication destination of IP address "33.333.333.333."

[0109] The idle VM determining device 201 then refers to the destination list 800 and identifies destinations with a connection rate equal to or greater than a predetermined rate α as common destinations. A common destination is a destination to which almost all of the idle state candidate VMs VM1 to VM3 have transmitted packets within a predetermined period T2. The common destination can be considered to be an OS update server or a security rule server that is connected to update the OS or apply security rules.

[0110] The virtual machines (VM1 to VMn) provided are created, for example, by duplicating a template. For this reason, it is assumed that the communication destination of "idle VMs" will basically be the same. However, it is also possible that users may individually set update destinations for some VMs. Therefore, to provide a buffer, the predetermined percentage α for determining common connection destinations is set to "α=95%."

[0111] In the example of FIG. 8, the communication destinations of the IP addresses "11.111.111.111," "22.222.222.222," and "10.100.100.106," which have a connection rate of 95% or more, are identified as common connection destinations.

[0112] This allows the idle VM determining device 201 to identify a communication destination (common connection destination) to which the idle state candidates VM1 to VM3 commonly connect, such as an OS update server or a security rule server.

[0113] Next, an example of determining whether a VM is in an idle state or a specific VM will be described with reference to FIGS.

[0114] The idle VM determining device 201 refers to the idle VM candidate packet table 600 to create a list of packet information for each of the idle VM candidates VM1 to VM3.

[0115] 9 is an explanatory diagram showing an example of a packet information list of VM 1. In Fig. 9, the packet information list 900 includes a source IP address, a destination IP address, and a common connection destination (circle / x). The source IP address indicates the source IP address identified from the packet information of VM 1, which is an idle VM candidate.

[0116] The destination IP address indicates the destination IP address identified from the packet information of VM1, an idle VM candidate. The common connection destination (○ / ×) indicates whether the destination IP address is a common connection destination. Here, the common connection destination (○) indicates that the destination IP address is a common connection destination. The common connection destination (×) indicates that the destination IP address is not a common connection destination.

[0117] According to the packet information list 900, it is clear that VM1, which is an idle VM candidate, has communicated with a communication destination other than the common connection destination within the predetermined period T2.

[0118] 10 is an explanatory diagram showing an example of a packet information list for VM3. In FIG. 10, the packet information list 1000 includes a source IP address, a destination IP address, and a common connection destination (◯ / X). The packet information list 1000 shows only the destination IP address of the common connection destination (◯). According to the packet information list 1000, it can be seen that VM3, an idle VM candidate, communicated only with the common connection destination within a predetermined period T2.

[0119] Although not shown, the packet information list of VM2, an idle VM candidate, also shows only the destination IP address of the common connection destination (◯), similar to the packet information list 1000.

[0120] The idle VM determination device 201 refers to the packet information list (e.g., packet information lists 900, 1000) of each of the idle VM candidates VM1 to VM3, and determines that among the idle state candidates VM1 to VM3, VM2 and VM3 that have communicated only with common connection destinations within a predetermined period T2 are in the idle state.

[0121] Information about VM2 and VM3 that are determined to be in an idle state is stored in, for example, an idle VM list 1100 as shown in FIG.

[0122] 11 is an explanatory diagram showing an example of an idle VM list. In FIG. 11, an idle VM list 1100 includes a VM name and an IP address. Here, the VM name is the VM name of a VM i determined to be in an idle state. The IP address is the IP address of a VM i determined to be in an idle state.

[0123] The idle VM determination device 201 may perform control to stop the operation of VM2 and VM3 determined to be in an idle state, for example, by referring to the idle VM list 1100. Specifically, for example, the idle VM determination device 201 may refer to the idle VM list 1100 and transmit a request to stop VM2 and VM3 determined to be in an idle state to the processing device 202 on which VM2 and VM3 are running.

[0124] For example, when the processing device 202 receives a shutdown request from the idle VM determination device 201, the processing device 202 stops the supply of power to the VMs VM2 and VM3 identified in the shutdown request. This allows the idle VM determination device 201 to stop the operation of the VMs VM2 and VM3 in the idle state, thereby reducing the power consumption of the processing device 202 (information processing system 200).

[0125] The idle VM determining device 201 may also transmit the idle VM list 1100 to a management terminal (not shown) used by a system administrator. This allows the system administrator to refer to the idle VM list 1100 and take appropriate measures, such as stopping VM2 and VM3 determined to be in an idle state.

[0126] The idle VM determining device 201 may also send a specific VM notification indicating VM1 determined to be a specific VM to a management terminal (not shown) used by a system administrator. This allows the system administrator to identify VM1 as "a virtual machine that issues a command to execute a process to a virtual machine or service that actually executes the process." This allows the system administrator to prevent mistakes such as erroneously stopping VM1, which is a candidate for an idle VM.

[0127] (Management Procedure of Idle VM Determining Device 201) 12 to 14, a management procedure of the idle VM determination device 201 will be described. Here, it is assumed that control statement data including instructions from a system administrator is stored in the idle VM determination device 201. It is also assumed that the system administrator instructs the idle VM determination device 201 to start operating in a reduced power consumption mode.

[0128] The control statement data includes, for example, data specifying the target power (the "PowerLimit=" portion), data specifying the host name, maximum power consumption, and standby power consumption of the physical server (processing device 202) (the "Server=" portion). The control statement data also includes data specifying the most recent and past periods (the "TimeRange=" portion), and data specifying a folder in which performance data is to be stored (the "LogDir=" portion). The control statement data also includes data specifying whether to immediately stop an idle VM (idle VM) when the idle VM is detected (the "Idlestop=" portion), and data specifying the VM name and job priority (the "VM=" portion).

[0129] 12 to 14 are flowcharts illustrating an example of a management procedure of the idle VM determining device 201. In the flowchart of Fig. 12, first, upon receiving an operation start instruction, the idle VM determining device 201 transmits an operation start notification to the user terminal of each VMi (step S1201). The operation start notification indicates the start of operation of the reduced power consumption mode, and is sent by e-mail, for example.

[0130] Next, the idle VM determination device 201 reads the data of the control statement (step S1202), and then transmits an idle VM deployment request to the processing device 202 specified in the data of the control statement, requesting deployment of an idle VM (first VM) (step S1203).

[0131] Note that there may be multiple types of guest OSs, which are OSs of VMs, in the processing device 202. In such a case, the idle VM determining device 201, for example, deploys an idle VM for each OS type in the processing device 202.

[0132] Next, the idle VM determining device 201 determines whether an operation termination condition is satisfied (step S1204). The operation termination condition is, for example, a condition that the current time is the operation termination time. If the operation termination condition is not satisfied (step S1204: No), the idle VM determining device 201 collects server data and VM data from the processing device 202 specified in the control statement data (step S1205).

[0133] The collected server data is stored in a server table 1500 as shown in FIG. 15. The collected VM data is stored, for example, in a VM table 1600 as shown in FIG. 16. Here, it is assumed that VM1 to VM4 are running on host 1 of a certain processing device 202, VM5 to VM7 are running on host 2 of a certain processing device 202, and VM8 to VM10 are running on host 3 of a certain processing device 202. The host is control software for running the VMs. Each VM includes an OS for each virtual system. It is assumed that the amount of physical memory of each physical server (processing device 202) is "32 GB".

[0134] Fig. 15 is an explanatory diagram showing a specific example of server data. In Fig. 15, a server table 1500 stores server data 1500-1 to 1500-3. Each of the server data 1500-1 to 1500-3 includes a host name, maximum power consumption, standby power consumption, processor frequency, the number of virtual CPUs, memory capacity, and data indicating a status.

[0135] The host name is the name of the host of the processing device 202 (physical server). The maximum power consumption is the maximum value of the power consumption of the processing device 202. The standby power is the standby power of the processing device 202. The host name, maximum power consumption, and standby power are acquired from the processing device 202. The processor frequency is the processor frequency of the processing device 202. The number of virtual CPUs is the number of virtual CPUs of the processing device 202. The memory amount is the memory amount of the processing device 202.

[0136] The processor frequency, the number of virtual CPUs, and the memory capacity are acquired, for example, from server management software installed in the processing device 202. The data indicating the status is "run" if the processing device 202 is running, and "stop" if the processing device 202 is not running. The data indicating the status is acquired using existing liveness monitoring technology.

[0137] 16 is an explanatory diagram showing a specific example of VM data. In Fig. 16, a VM table 1600 stores VM data 1600-1 to 1600-10, including a VM name, a host name, the number of allocated virtual CPUs, the allocated memory amount, a job priority, a stop priority, an idle time, and a stop order.

[0138] The VM name is the name of the VMi. The host name is the name of the processing device 202 on which the VMi runs. The allocated virtual CPU count is the number of virtual CPUs allocated to the VMi. The allocated memory amount is the amount of memory allocated to the VMi.

[0139] The business priority indicates the priority of the business process executed by VMi. If the priority is 0, VMi will not be stopped even if it is in an idle state. For example, if the user of VMi and the system administrator have concluded a contract that prevents it from being stopped, the business priority is 0. If the priority value is 1 or higher, VMi may be stopped if it is in an idle state.

[0140] The job priority, stop priority, idle time, and stop order are not set at step S1205, but are set in a later process.

[0141] 12, the idle VM determining device 201 determines whether there is an active server by scanning the status data in the server table 1500 (step S1206). If there is no active server (step S1206: Yes), the idle VM determining device 201 cannot reduce power consumption and therefore returns to step S1204.

[0142] Then, the idle VM determining device 201 executes the process of step S1204 at the next predetermined time. This allows the idle VM determining device 201 to perform the process periodically. On the other hand, if there is an active server (step S1206: No), the idle VM determining device 201 collects performance data (step S1207).

[0143] Fig. 17 is an explanatory diagram showing a specific example of performance data. In Fig. 17, performance data 1700 includes a date and time, a VM name, a CPU usage rate, an I / O data amount, and a data transfer amount on a network. The date and time indicates the date and time when the performance data was acquired.

[0144] The VM name, CPU usage rate, I / O data volume, and data transfer volume indicate the CPU usage rate, I / O data volume, and data transfer volume on the network of the VM i. The performance data is obtained, for example, from server management software installed in the processing device 202.

[0145] Specifically, for example, the idle VM determining device 201 periodically accesses a folder specified by LogDir in the control statement data to collect performance data, and then aggregates the collected performance data for the most recent and past periods.

[0146] Fig. 18 is an explanatory diagram showing a specific example of aggregated performance data. In Fig. 18, an aggregated performance table 1800 stores aggregated performance data (for example, aggregated performance data 1800-1, 1800-2). The aggregated performance data includes average CPU utilization, average I / O data volume, average data transfer volume, idle determination, and idle time for the most recent and past periods.

[0147] The average CPU usage, average I / O data volume, and average data transfer volume indicate the average CPU usage, average I / O data volume, and average data transfer volume of VMi for each period. The idle judgment indicates whether or not it is in an idle state. The idle time indicates the idle time for each period. Run indicates that it is not in an idle state. Idle indicates that it is in an idle state.

[0148] 12, the idle VM determining device 201 calculates a threshold value from the performance data collected for the idle VMs deployed in step S1203 (step S1208). The threshold value is calculated by, for example, using a numerical value related to the performance of the idle VMs in the most recent period (predetermined period T1) as is, or by multiplying the numerical value by a predetermined rate. Note that it is sufficient to perform the process of step S1208 once, and it may be skipped from the second time onward.

[0149] Then, the idle VM determining device 201 compares the performance value of VMi with the threshold calculated in step S1208 to identify VMs that are idle state candidates (step S1209), and proceeds to step S1301 shown in FIG.

[0150] The performance data of VMi includes, for example, CPU utilization, I / O data volume, and network data transfer volume. Specifically, the idle VM determining device 201 determines that a VMi whose CPU utilization, I / O data volume, and network data transfer volume are all equal to or less than a threshold is an idle state candidate VM.

[0151] In the flowchart of FIG. 13, first, the idle VM determination device 201 acquires packet information that can identify the communication destinations that communicated with each VM within a predetermined period T2 for each VM that is an idle state candidate identified in step S1209 shown in FIG. 12 (step S1301).

[0152] Next, the idle VM determination device 201 identifies common connection destinations that have communicated with a predetermined percentage α or more of the idle state candidate VMs based on the acquired packet information of each VM (step S1302).Then, based on the acquired packet information of each VM, the idle VM determination device 201 determines that a VM that has communicated with a communication destination other than the identified common connection destination among the idle state candidate VMs is a specific VM that commands another VM to execute a process (step S1303).

[0153] Next, the idle VM determining device 201 determines that the VMs other than the determined specific VM are in an idle state among the VMs that are idle candidates (step S1304).Then, the idle VM determining device 201 creates an idle VM list that indicates the determined VMs in an idle state (step S1305).

[0154] Next, the idle VM determining device 201 determines whether there is a VM that is currently in an idle state and whether "idlestop=dynamic" is set (step S1306). Whether there is a VM that is currently in an idle state can be determined, for example, from the idle VM list.

[0155] For example, "idlestop=dynamic" is included in the control statement data. If the control statement data includes "idlestop=dynamic", the VM will be stopped immediately when an idle VM is detected. If the control statement data does not include "idlestop=dynamic", the VM will be stopped when it is actually migrated.

[0156] If there is no VM currently in an idle state or "idlestop=dynamic" is not set (step S1306: No), the idle VM determining device 201 proceeds to step S1308.

[0157] On the other hand, if there is a VM that is currently in an idle state and "idlestop=dynamic" is set (step S1306: Yes), the idle VM determination device 201 sends a request to stop the idle VM and a startup guard request to the processing device 202 that executes that VM (step S1307).

[0158] The startup guard request requests execution of the startup guard for the VM. The startup guard is a control to prevent a certain VM from being executed. In response to this, the processing unit 202 executes the startup guard.

[0159] Next, the idle VM determining device 201 calculates the past and recent idle times for each VM, and stores the idle times and data indicating whether or not the VM is in an idle state in the aggregated performance table 1800 shown in Fig. 18 (step S1308). The idle time is the time during which the VM is in an idle state.

[0160] For example, the idle VM determining device 201 may determine that a VM is in an idle state for the most recent period if the idle time ratio is 90% or more, and may determine that a VM is in an idle state for the past period if the idle time ratio was 90% or more for the past period. Note that by determining that a VM is an idle VM if the idle time ratio is 90% or more for the most recent and past periods, it is possible to prevent a VM from being determined to be not an idle VM due to the influence of, for example, a temporary process (such as a virus scan).

[0161] The idle VM determining device 201 then sets the stop priority, the operation priority, and the idle time in the VM table 1600, determines the order in which the VMs are stopped based on the stop priority, the operation priority, and the idle time (step S1309), and proceeds to step S1401 shown in Fig. 14. The determined order in which the VMs are stopped is set in the VM table 1600.

[0162] The priority of the stop is set, for example, in accordance with the priority setting rule shown in Fig. 19. The priority setting rule is stored in a storage device such as the memory 302 or the disk 304.

[0163] Fig. 19 is an explanatory diagram showing an example of a priority setting rule. In Fig. 19, a priority setting rule 1900 indicates the priority of stopping a VM. The priority setting rule 1900 indicates patterns 1 to 4, with the smaller the "#" in pattern #, the higher the priority. Pattern 1 is a pattern in which both the past and recent times have been in an idle state.

[0164] Pattern 2 is a pattern where the user has only been in an idle state recently. Pattern 3 is a pattern where the user has only been in an idle state in the past. Pattern 4 is a pattern where the user has never been in an idle state. The notes indicate the characteristics of the user in each of patterns 1 to 4.

[0165] The priority of a task is determined, for example, using data in a control statement. Specifically, the idle VM determining device 201 sorts the VM table 1600 in descending order using the task priority as the first key, the shutdown priority as the second key, and the idle time as the third key. Then, the idle VM determining device 201 assigns the shutdown order sequentially, starting from the first row.

[0166] 14, first, the idle VM determining device 201 determines whether the current power consumption is equal to or less than the target power consumption specified in the control statement data (step S1401). As the current power consumption, for example, the total power consumption of each processing device 202 acquired by a power sensor is used.

[0167] If the current power consumption is equal to or less than the target power (step S1401: Yes), there is no need to stop any more VMs, and the idle VM determining device 201 returns to step S1204 shown in Fig. 12. Then, the idle VM determining device 201 executes the process of step S1204 at the next predetermined time. This allows the idle VM determining device 201 to perform the process periodically.

[0168] On the other hand, if the current power consumption is greater than the target power (step S1401: No), the idle VM determining device 201 searches for a combination of servers (processing devices 202) whose power consumption is less than the target power (step S1402). In step S1402, the idle VM determining device 201 searches for a combination using, for example, the maximum power consumption value in the server table 1500.

[0169] For example, suppose the data shown in FIG. 15 is stored in the server table 1500, and the current power consumption of the processing device 202 of host 1 is "250 W," the current power consumption of the processing device 202 of host 2 is "255 W," the current power consumption of the processing device 202 of host 3 is "190 W," and the total power consumption is "695 W." Also, assume that the target power is 556 W (a 20% reduction in power consumption). In this case, the following six combinations (i) to (vi) are detected as combinations of servers whose power consumption is below the target power.

[0170] (i) Host 1 and Host 2 (262W + 262W + 16W = 540W < 556W), (ii) Host 1 and Host 3 (262W + 16W + 262W = 540W < 556W), (iii) Host 2 and Host 3 (16W + 262W + 262W = 540W < 556W), (iv) Host 1 (262W + 16W + 16W = 294W < 556W), (v) Host 2 (16W + 262W + 16W = 294W < 556W), (vi) Host 3 (16W + 16W + 262W = 294W < 556W).

[0171] For example, if it is specified that power consumption be reduced by 80% or 100%, there is no applicable combination.

[0172] The idle VM determining device 201 determines whether there is a server combination (step S1403). If there is no server combination (step S1403: Yes), the idle VM determining device 201 generates data on a procedure for powering off all servers or a procedure for cutting off the power supply to all servers (step S1404), and proceeds to step S1411.

[0173] In this way, when there is no server combination, the idle VM determining device 201 can ensure that the power consumption is equal to or less than the target power by cutting off the power supply to all servers. Methods for cutting off the power supply to a server include, for example, turning off the main switch of the server, tripping the breaker in the distribution board, or unplugging the power outlet. For processes that cannot be performed automatically, data indicating the procedure may be output to a display device so that a system administrator can perform the process.

[0174] Here, the procedure data generated in step S1404 will be described with reference to FIG.

[0175] 20 is an explanatory diagram (part 1) showing an example of generated procedure data. In Fig. 20, procedure 2000 includes data indicating a process for stopping VM1, VM2, and VM4 to VM9, and a process for powering off the servers of hosts 1 to 3.

[0176] If there is at least one combination of servers at step S1403 (step S1403: No), the idle VM determining device 201 searches for a combination of VM placements for each combination of servers (step S1405).

[0177] For example, suppose you want to reduce power consumption by 20%. In this case, if idlestop=dynamic is specified and VM3 and VM10 have already been deleted, the following combinations exist:

[0178] VM1, VM2, VM4, and VM8 are running on host 1. Memory usage is 8GB x 4 = 32GB, which is less than the physical memory capacity of 32GB. VM5, VM6, VM7, and VM9 are running on host 2. Memory usage is 8GB x 2 + 4GB x 2 = 24GB, which is less than the physical memory capacity of 32GB. VMs are migrated twice, and the amount of data moved is 8GB (VM8) + 4GB (VM9) = 12GB.

[0179] 14, the idle VM determining device 201 determines whether there is a combination of VM placements (step S1406). For example, if there is even one VM that must be stopped, the idle VM determining device 201 determines that there is no combination of VM placements. If there is at least one combination of VM placements (step S1406: No), the idle VM determining device 201 proceeds to step S1409.

[0180] On the other hand, if there is no combination of VM placements (step S1406: Yes), the idle VM determining device 201 identifies VMs to be stopped according to the stopping order set in the VM table 1600 (step S1407). In step S1407, the idle VM determining device 201 identifies one or more VMs to be stopped, so that the remaining VMs can be placed on any of the processing devices 202 (physical servers).

[0181] The idle VM determining device 201 identifies a combination of placements of VMs other than the VMs identified in step S1407 (step S1408). Then, the idle VM determining device 201 identifies an optimal placement of VMs (step S1409). The optimal placement is a placement that minimizes the number of VM movements and the amount of data movement. For example, the idle VM determining device 201 identifies an optimal placement of VMs from the combinations identified in step S1408.

[0182] Next, the idle VM determining device 201 generates data of a procedure for realizing the identified placement (step S1410).

[0183] Here, the procedure data generated in step S1410 will be described with reference to FIGS.

[0184] 21 is an explanatory diagram (part 2) showing an example of generated procedure data. In FIG. 21, procedure 2100 includes data indicating a process for stopping VM 10, a process for migrating VM 8 and VM 9, and a process for powering off the server of host 3.

[0185] 22 is an explanatory diagram (part 3) showing an example of generated procedure data. In FIG. 22, procedure 2200 includes data indicating a process to stop VM4, VM5, VM8, and VM9, a process to migrate VM6 and VM7, and a process to power off the servers of host 2 and host 3.

[0186] Then, the idle VM determining device 201 executes the procedure for reducing the power consumption to the target power or less in accordance with the generated procedure data (step S1411), and returns to step S1204 shown in FIG.

[0187] If the operation termination condition is satisfied in step S1204 (step S1204: Yes), the idle VM determining device 201 sends a startup guard release request to the processing device 202 to request the release of startup guard for the VM for which startup guard is being executed (step S1210). In response to this, the processing device 202, having received the startup guard release request, releases the startup guard for the VM for which startup guard is being executed.

[0188] The idle VM determination device 201, for example, activates a load balancing mechanism and a power consumption reduction mechanism to resume normal operation (step S1211). The idle VM determination device 201 also transmits an operation end notification to the user terminal of each VMi (step S1212), thereby completing the series of processes according to this flowchart.

[0189] This allows the idle VM determination device 201 to accurately identify idle VMs. The idle VM determination device 201 can also reduce power consumption by, for example, stopping idle VMs. For example, the idle VM determination device 201 can determine the order in which VMs are stopped based on past and recent usage, thereby ensuring fairness among users and satisfying operation for users. The idle VM determination device 201 can also cut peak power consumption by controlling power consumption so that it does not exceed a specified target power.

[0190] As described above, the idle VM determination device 201 according to the embodiment can acquire, for each VMi included in the idle state candidate VMs, communication information that can identify communication destinations that communicated with each VMi within a predetermined period T2. Then, the idle VM determination device 201 can identify common destinations that communicated with a predetermined percentage or more of the idle state candidate VMs based on the acquired communication information, and determine that the VMs that communicated only with the identified common destinations within the predetermined period T2 are in an idle state.

[0191] As a result, the idle VM determination device 201 can improve the accuracy of determining whether a VM is in an idle state by taking into account the communication destinations of each VM i included in the idle state candidate VMs. For example, an idle state VM is characterized in that it basically only performs communication for updating the OS, applying security rules, and the like. In addition, a VM created by replicating a template is characterized in that it shares a common connection destination when performing an OS update, applying security rules, and the like. By utilizing these characteristics, the idle VM determination device 201 can determine, as an idle state, a VM that communicates only with communication destinations (common connection destinations) that most of the idle state candidate VMs communicate with. Therefore, the idle VM determination device 201 can accurately determine whether a VM is in an idle state, even if the idle state candidate VMs include a VM with performance data similar to that of an idle state VM.

[0192] Furthermore, according to the idle VM determination device 201, among the VMs that are candidates for the idle state, a VM that has communicated with a communication destination other than the identified common connection destination within a predetermined period T2 can be determined to be a specific VM that commands other VMs to execute processing.

[0193] This allows the idle VM determination device 201 to prevent erroneous determination that a "virtual machine that issues a processing command to a virtual machine or service that actually performs the processing" whose performance data is similar to that of an idle VM is idle.

[0194] The idle VM determination device 201 can acquire performance data of a first VM deployed in a system that is not executing a process, and performance data of VMs other than the first VM. The system is, for example, a processing device 202 capable of executing VMs. The system may also be an information processing system 200 including the processing device 202. The performance data of the first VM is information about the operation of the first VM, and includes, for example, at least one of the CPU usage rate, memory usage, I / O data volume of a disk device, and data transfer volume over a network of the first VM. The performance data of the VMs other than the first VM is information about the operation of the VMs other than the first VM, and includes, for example, at least one of the CPU usage rate, memory usage, I / O data volume of a disk device, and data transfer volume over a network of the VMs other than the first VM. The idle VM determination device 201 can identify VMs other than the first VM as idle state candidates by comparing the acquired performance data of the first VM with the performance data of the VMs other than the first VM.

[0195] This allows the idle VM determination device 201 to compare performance data obtained from the provided VMs with performance data obtained from a VM that is actually idle (first VM), thereby narrowing down the VMs that are candidates for idle state.

[0196] Furthermore, the idle VM determination device 201 calculates a threshold value for determining whether a VM is an idle state candidate from the performance data of the first VM, and determines whether the numerical values ​​included in the performance data of VMs other than the first VM exceed the calculated threshold value, thereby identifying VMs that are idle state candidates.

[0197] This allows the idle VM determination device 201 to generate thresholds based on performance data obtained from a VM (first VM) that is actually in an idle state, thereby narrowing down idle candidate VMs with high accuracy. Furthermore, the idle VM determination device 201 can automatically set thresholds suited to the actual operating environment, eliminating the need for a system administrator or the like to set thresholds, thereby reducing operational costs.

[0198] Furthermore, the idle VM determining device 201 can control the VM determined to be in an idle state to stop its operation.

[0199] This allows the idle VM determining device 201 to stop the idle VMs and reduce power consumption.

[0200] Furthermore, the idle VM determining device 201 can output information that allows identification of a VM determined to be in an idle state.

[0201] This allows the idle VM determining device 201 to notify a system administrator or the like of the existence of an idle VM. The system administrator can take action, such as stopping the VM determined to be idle.

[0202] For these reasons, the idle VM determination device 201 according to the embodiment can determine which VMs are idle among the VMs provided and stop the operation of those VMs, thereby reducing the power consumption of the entire system.

[0203] In this case, the idle VM determination device 201 can accurately identify "virtual machines that actually perform processes or that instruct services to execute processes" that have performance data similar to that of idle VMs. Therefore, the idle VM determination device 201 can prevent "virtual machines that actually perform processes or that instruct services to execute processes" from being erroneously stopped, thereby avoiding problems such as service outages caused by processes that should be executed not being executed.

[0204] This management method can be applied to, for example, a service that provides a private cloud system. In this case, the idle VM determination device 201 can reduce the resources required for operation and management and cut costs when providing a private cloud in a company or organization.

[0205] The management method described in this embodiment can be realized by executing a prepared program on a computer such as a personal computer or a workstation. This 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 by being read from the recording medium by the computer. This management program may also be distributed via a network such as the Internet.

[0206] In addition, the management device 101 (idle VM determination device 201) described in this embodiment can also be realized by an application-specific IC such as a standard cell or a structured ASIC (Application Specific Integrated Circuit) or a PLD (Programmable Logic Device) such as an FPGA.

[0207] The following additional notes are provided regarding the above-described embodiment.

[0208] (Supplementary Note 1) For each runtime environment included in one or more runtime environments that are candidates for an idle state, communication information that can identify a communication destination that communicated with each runtime environment within a predetermined period is acquired, Identifying communication destinations that communicate with at least a predetermined percentage of the runtime environments among the one or more runtime environments based on the acquired communication information; determining that a runtime environment that has communicated only with the identified communication destination within the predetermined period of time out of the one or more runtime environments is in an idle state; A management device comprising a control unit.

[0209] (Supplementary Note 2) The control unit determining, among the one or more execution environments, an execution environment that has communicated with a communication destination other than the identified communication destination within the predetermined period as a specific execution environment that commands another execution environment to execute a process; 2. The management device according to claim 1,

[0210] (Supplementary Note 3) The control unit acquire information on the operation of a first runtime environment deployed in the system that does not execute a process, and information on the operation of runtime environments other than the first runtime environment; identifying one or more runtime environments as candidates for the idle state from among the runtime environments other than the first runtime environment by comparing the acquired information on the operation of the first runtime environment with information on the operation of runtime environments other than the first runtime environment; 3. The management device according to claim 1 or 2.

[0211] (Supplementary Note 4) The control unit calculating a threshold value for determining whether the first execution environment is a candidate for an idle state from information relating to the operation of the first execution environment; The management device described in Appendix 3 is characterized in that it identifies one or more execution environments that are candidates for the idle state by determining whether a numerical value contained in information regarding the operation of an execution environment other than the first execution environment exceeds the calculated threshold.

[0212] (Supplementary Note 5) The control unit 5. The management device according to any one of claims 1 to 4, wherein the management device controls to stop operation of the runtime environment determined to be in the idle state.

[0213] (Supplementary Note 6) The control unit 6. The management device according to any one of claims 1 to 5, wherein the management device outputs information that can identify the execution environment that has been determined to be in an idle state.

[0214] (Supplementary Note 7) The management device according to any one of Supplementary Notes 1 to 6, wherein each of the one or more runtime environments is a virtual machine.

[0215] (Supplementary Note 8) The management device according to any one of Supplementary Notes 1 to 6, wherein each of the runtime environments included in the one or more runtime environments is a container.

[0216] (Supplementary Note 9) For each runtime environment included in one or more runtime environments in the idle state candidate, communication information capable of identifying a communication destination that communicated with each runtime environment within a predetermined period is acquired; Identifying communication destinations that communicate with at least a predetermined percentage of the runtime environments among the one or more runtime environments based on the acquired communication information; determining that a runtime environment that has communicated only with the identified communication destination within the predetermined period of time out of the one or more runtime environments is in an idle state; A management method characterized in that processing is executed by a computer.

[0217] (Supplementary Note 10) For each runtime environment included in one or more runtime environments in the idle state candidate, communication information capable of identifying a communication destination that communicated with each runtime environment within a predetermined period is acquired; Identifying communication destinations that communicate with at least a predetermined percentage of the runtime environments among the one or more runtime environments based on the acquired communication information; determining that a runtime environment that has communicated only with the identified communication destination within the predetermined period of time out of the one or more runtime environments is in an idle state; A management program that causes a computer to execute a process. [Explanation of symbols]

[0218] 101 Management device 102,103,104,105,106,107 Virtual Machines 110 Communication Rate Information 200 Information Processing Systems 201 Idle VM Detector 202 Processing equipment 203 Packet Capture Device 210 Network 300 Bus 301 CPU 302 memory 303 Disk Drive 304 Disk 305 Communication I / F 306 Portable Recording Media I / F 307 Portable Recording Media 400 VMs in total 500 Idol VM Candidate List 600 Idle VM Candidate Packet Table 700 control section 701 Acquisition Department 702 Specific part 703 Judgment section 704 Stop part 705 Output Section 800 Connection List 900,1000 packet information list 1100 Idol VM List 1500 Server Table 1500-1~1500-3 Server Data 1600 VM tables 1600-1~1600-10 VM data 1700 Performance Data 1800 Aggregate Performance Table 1800-1, 1800-2 Aggregate performance data 1900 Priority Setting Rules 2000,2100,2200 steps

Claims

1. acquiring, for each runtime environment included in one or more runtime environments that are idle state candidates, communication information that can identify a communication destination that has communicated with each runtime environment within a predetermined period of time; Identifying communication destinations that have communicated with at least a predetermined percentage of the runtime environments among the one or more runtime environments based on the acquired communication information; determining that a runtime environment that has communicated only with the identified communication destination within the predetermined period of time out of the one or more runtime environments is in an idle state; A management device comprising a control unit.

2. The control unit determining, among the one or more execution environments, an execution environment that has communicated with a communication destination other than the identified communication destination within the predetermined period as a specific execution environment that commands another execution environment to execute a process; The management device according to claim 1 .

3. The control unit acquiring information on the operation of a first execution environment that is deployed in the system and does not execute a process, and information on the operation of an execution environment other than the first execution environment; identifying one or more runtime environments as candidates for the idle state from among the runtime environments other than the first runtime environment by comparing the acquired information on the operation of the first runtime environment with information on the operation of runtime environments other than the first runtime environment; The management device according to claim 1 .

4. The control unit The management device according to claim 1 , wherein the management device performs control to stop the operation of the runtime environment determined to be in the idle state.

5. 5. The management device according to claim 1, wherein each of the one or more execution environments is a virtual machine.

6. acquiring, for each runtime environment included in one or more runtime environments that are idle state candidates, communication information that can identify a communication destination that has communicated with each runtime environment within a predetermined period of time; Identifying communication destinations that have communicated with at least a predetermined percentage of the runtime environments among the one or more runtime environments based on the acquired communication information; determining that a runtime environment that has communicated only with the identified communication destination within the predetermined period of time out of the one or more runtime environments is in an idle state; A management method characterized in that processing is executed by a computer.

7. acquiring, for each runtime environment included in one or more runtime environments that are idle state candidates, communication information that can identify a communication destination that has communicated with each runtime environment within a predetermined period of time; Identifying communication destinations that have communicated with at least a predetermined percentage of the runtime environments among the one or more runtime environments based on the acquired communication information; determining that a runtime environment that has communicated only with the identified communication destination within the predetermined period of time out of the one or more runtime environments is in an idle state; A management program that causes a computer to execute a process.

Images