WO2022050197A1 - コンピュータシステムおよびコンピュータプログラム - Google Patents

コンピュータシステムおよびコンピュータプログラム Download PDF

Info

Publication number
WO2022050197A1
WO2022050197A1 PCT/JP2021/031592 JP2021031592W WO2022050197A1 WO 2022050197 A1 WO2022050197 A1 WO 2022050197A1 JP 2021031592 W JP2021031592 W JP 2021031592W WO 2022050197 A1 WO2022050197 A1 WO 2022050197A1
Authority
WO
WIPO (PCT)
Prior art keywords
server
cpu
standby
control unit
management unit
Prior art date
Application number
PCT/JP2021/031592
Other languages
English (en)
French (fr)
Inventor
亮太 壬生
Original Assignee
楽天モバイル株式会社
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 楽天モバイル株式会社 filed Critical 楽天モバイル株式会社
Priority to US17/793,921 priority Critical patent/US20230058193A1/en
Publication of WO2022050197A1 publication Critical patent/WO2022050197A1/ja

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533—Hypervisors; Virtual machine monitors
    • G06F9/45558—Hypervisor-specific management and integration aspects
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533—Hypervisors; Virtual machine monitors
    • G06F9/45558—Hypervisor-specific management and integration aspects
    • G06F2009/4557—Distribution of virtual machine instances; Migration and load balancing
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533—Hypervisors; Virtual machine monitors
    • G06F9/45558—Hypervisor-specific management and integration aspects
    • G06F2009/45595—Network integration; Enabling network access in virtual machine instances
    • Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
    • Y02D—CLIMATE CHANGE MITIGATION TECHNOLOGIES IN INFORMATION AND COMMUNICATION TECHNOLOGIES [ICT], I.E. INFORMATION AND COMMUNICATION TECHNOLOGIES AIMING AT THE REDUCTION OF THEIR OWN ENERGY USE
    • Y02D10/00—Energy efficient computing, e.g. low power processors, power management or thermal management

Definitions

  • This disclosure relates to computer systems and computer programs.
  • the general-purpose servers that are pre-installed in data centers, etc. have the problem of high power consumption because they are supplied with the same amount of power as when the virtual machine software is executed even when waiting for the virtual machine software to be input. ..
  • This disclosure has been made in view of these issues, and one purpose is to provide a technique for suppressing the power consumption of a computer that executes a workload in a virtualized environment.
  • a management unit that manages the execution of a workload on a server and a power mode of a CPU in the server according to a change in the execution mode of the workload on the server. It is equipped with a control unit for changing the above.
  • This computer program provides a computer with a function of managing the execution of workloads on the server and a function of changing the power mode of the CPU on the server according to a change in the execution mode of the workload on the server.
  • IAAS Infrastructure as a Service
  • VM virtual machine software
  • the power mode of the CPU (Central Processing Unit) of the physical server is changed, and specifically, the sleep setting of the CPU is set.
  • the computer system of the embodiment it is possible to reduce the power consumption of a computer that executes a VM on demand in a virtualized environment.
  • the virtualization software "OpenStack” is installed on the physical server, and one or more VMs are executed on the physical server.
  • a container engine “Docker” may be introduced in a physical server, and one or more containers (also referred to as “pods”) may be executed on the physical server.
  • VMs and containers (pods) are also collectively referred to as "workloads.”
  • FIG. 1 shows the configuration of the computer system 10 of the first embodiment.
  • the computer system 10 which can be said to be a data processing system, includes a requester device 12, a cluster management device 14, and a plurality of servers (server 16a, server 16b, server 16c ).
  • server 16a, server 16b, server 16c a plurality of servers (server 16a, server 16b, server 16c ...) are collectively referred to as "server 16".
  • the cluster management device 14 and the server 16 may be installed in the data center and connected by the LAN of the data center. Further, dozens to hundreds of servers 16 may be installed in one data center. Further, the requester device 12 and the cluster management device 14 may be connected via the Internet.
  • FIG. 1 includes a block diagram showing functional blocks of the cluster management device 14 and the server 16.
  • the plurality of functional blocks shown in the block diagram of the present specification can be configured by a circuit block, a memory, and other LSIs in terms of hardware, and in terms of software, the CPU executes a program loaded in the memory. It is realized by doing. Therefore, it is understood by those skilled in the art that these functional blocks can be realized in various forms by hardware only, software only, or a combination thereof, and the present invention is not limited to any of them.
  • the server 16 is an information processing device also called a compute node.
  • the server 16 is a physical server that provides various resources (CPU, memory, storage, etc.) for executing the VM.
  • the server 16 includes a CPU 30, a VM 32, a VM control unit 34, and a CPU control unit 36.
  • the VM control unit 34 and the CPU control unit 36 may be implemented as a computer program, or the computer program may be stored in a storage (not shown) of the server 16.
  • the CPU 30 may exert the functions of the VM control unit 34 and the CPU control unit 36 by reading the computer program into the main memory (not shown) and executing the program.
  • the VM control unit 34 controls the execution of the VM 32 on the server 16. Specifically, the VM control unit 34 realizes a virtual server by causing the CPU 30 to execute the program of the VM 32 according to the instruction from the cluster management device 14. In the embodiment, the VM 32 program is provided by the cluster management device 14. The VM control unit 34 may be realized by utilizing the function of OpenStack.
  • the CPU control unit 36 controls the power mode of the CPU 30 in the server 16.
  • the CPU control unit 36 of the embodiment includes a known BMC (Baseboard Management Controller) function, and receives a remote request for changing the power mode of the CPU 30 via IPMI (Intelligent Platform Management Interface).
  • BMC Baseboard Management Controller
  • IPMI Intelligent Platform Management Interface
  • the CPU control unit 36 sets the power mode of the CPU 30 according to the instruction from the cluster management device 14, (1) the power mode in which the CPU does not shift to the sleep state, in other words, the CPU shifts to the sleep state. It shifts to the power mode (hereinafter, also referred to as "C6 disable") for which it is prohibited. Further, the CPU control unit 36 is a power mode in which the power mode of the CPU 30 is permitted to shift to the sleep state according to an instruction from the cluster management device 14, and (2) a task such as a VM is permitted. The CPU shifts to the power mode (hereinafter, also referred to as "C6 enable”) in which the CPU goes to sleep when the above is not executed.
  • C6 is the deepest sleep state in the C state indicating the power mode of the CPU 30, and the power consumption of the CPU 30 is the smallest. Further, the return from “C6” to the operating state “C0” takes a longer time than the return from other C states, but it is still less than 1 second.
  • the CPU 30 of the server 16 that is not executing the VM is put into the sleep state of C6.
  • the sleep mode (C state) of the CPU 30 in the server 16 that is not executing the VM is not limited to C6. The appropriate sleep mode may be determined by the developer by weighing the power consumption and the return time to C0.
  • the virtual server realized by VM32 executes an application related to the business of a telecommunications carrier.
  • This application may be, for example, a RAN (Radio Access Network) application (vCU, vDU, etc.) of a 5th generation mobile communication system (5G), or an application (AMF, SMF, etc.) of a 5G core network system.
  • a RAN Radio Access Network
  • AMF Access Management Function
  • SMF Ses Mobility Management Function
  • the VM 32 should be executed on the server 16 in the power mode (C6 disabled) in which the CPU does not go to sleep. Is.
  • the requester device 12 is an information processing device that requests the creation or deletion of a VM (in other words, a virtual server).
  • the requester device 12 may be a device operated by a person (PC or the like), or may be a system / device such as an EMS (Element Management System) that automatically executes data processing without human intervention.
  • the requester device 12 sends a VM creation request or a VM deletion request to the cluster management device 14.
  • the VM creation request may include information that specifies the amount of resources for each of the CPU, memory, and storage allocated to the new VM, the type of OS, and the like.
  • the VM deletion request may include identification information of the VM to be deleted.
  • the cluster management device 14 is an information processing device that manages a plurality of servers 16 (also referred to as "clusters"). Although one cluster management device 14 is drawn in FIG. 1, the cluster management device 14 may be made redundant by a plurality of devices.
  • the cluster management device 14 includes a VMDB 20, a physical server DB 22, a VM management unit 24, and a server management unit 26.
  • the VMDB 20 stores the image data (program) of the VM for executing the VM on the server 16. Further, the VMDB 20 stores the identification information of the server 16 in association with the identification information of the VM being executed by the server 16. In other words, the VMDB 20 stores information (VM ID, etc.) about the VM being executed by each of the plurality of servers 16.
  • the VMDB 20 stores data necessary for determining the server 16 to execute the VM from among the plurality of servers 16.
  • the VMDB 20 may store the free capacity of the hardware resources (CPU, memory, storage, etc.) of each server 16.
  • VMDB20 may be realized by utilizing the function of OpenStack.
  • the physical server DB 22 stores the identification information of each of the plurality of servers 16 and the data necessary for communication with each server 16. For example, the physical server DB 22 is necessary to access the BMC (CPU control unit 36) of each server 16 via (1) host name, (2) IP address, and (3) IPMI of each of the plurality of servers 16. Information may be stored.
  • BMC CPU control unit 36
  • the physical server DB 22 stores the operating state of each of the plurality of servers 16, in other words, stores data indicating which of the plurality of operating states each server 16 is.
  • the plurality of operating states include (1) operating state, (2) standby state, and (3) power off state.
  • the operating state is an operating state in which power is supplied (power on state) and the CPU is set to a power mode (C6 disabled) in which the CPU does not shift to the sleep state.
  • the standby state is an operating state in which power is supplied (power on state) and the CPU is set to the power mode (C6 enable) in which the CPU can shift to the sleep state.
  • the power off state is a state in which the power supply is stopped, and can be said to be a power off state.
  • the VM management unit 24 and the server management unit 26 may be implemented as computer programs, and the computer programs may be stored in the storage (not shown) of the cluster management device 14.
  • the CPU of the cluster management device 14 may exert the functions of the VM management unit 24 and the server management unit 26 by reading the computer program into the main memory (not shown) and executing the program.
  • the VM management unit 24 manages the execution of VMs on each of the plurality of servers 16.
  • the VM management unit 24 may be realized by using the function of OpenStack.
  • the VM management unit 24 receives the VM creation request transmitted from the requester device 12, the VM creation request indicates the amount of hardware resources, the VM execution status and the amount of free resources in each server 16 stored in the VMDB 20.
  • a server 16 (hereinafter, also referred to as a “target server”) for executing a VM is determined from a plurality of servers 16 according to the above.
  • the VM management unit 24 transmits the image data of the VM corresponding to the VM creation request to the VM control unit 34 of the target server, and starts the execution of the VM on the target server.
  • the server management unit 26 changes the power mode of the CPU in the server 16 according to the change in the execution mode of the VM in the server 16.
  • the server management unit 26 among the plurality of servers 16 to be managed has the server management unit 26 in the plurality of servers 16 according to the change in the execution mode of the VM in at least one server 16.
  • the power mode of the CPU in at least one server 16 is changed.
  • the server management unit 26 changes the power mode of the CPU in the certain server 16 to the power mode (C6) in which the CPU does not shift to the sleep state. Disable).
  • the server management unit 26 may change the power mode of the CPU in each server 16 by accessing the BMC (CPU control unit 36) of each server 16 via IPMI.
  • the operating state of each of the plurality of servers 16 is set to either an operating state or a standby state. Further, the operating state of the server 16 that is not executing the VM is set to the standby state.
  • FIG. 2 is a flowchart showing the operation of the computer system 10 of the first embodiment.
  • the figure shows the operation when creating a new VM, in other words, when creating a new virtual server.
  • the requester device 12 sends a VM creation request to the cluster management device 14.
  • the server 16 (“target server”) that executes a new VM that meets the VM creation request. Call) is determined (S12).
  • the VM management unit 24 notifies the server management unit 26 of the identification information (for example, the host name, etc.) of the target server.
  • the server management unit 26 refers to the physical server DB 22 and confirms whether or not the target server notified from the VM management unit 24 is in the standby state. If the target server is in the standby state (Y in S14), the server management unit 26 cooperates with the CPU control unit 36 of the target server to set the power mode of the CPU of the target server to C6 disable (S16). In other words, the server management unit 26 shifts the operating state of the target server from the standby state to the operating state. If the target server is in the operating state (N in S14), the process in S16 is skipped. The server management unit 26 notifies the VM management unit 24 that the target server is in the operating state.
  • the VM management unit 24 cooperates with the VM control unit 34 of the target server to start the execution of the VM on the target server (S18).
  • the VM management unit 24 records in the VMDB 20 that a new VM is executed on the target server. If the VM creation request is not accepted (N in S10), the processing after S12 is skipped.
  • the cluster management device 14 repeatedly executes a series of processes shown in FIG.
  • FIG. 3 is also a flowchart showing the operation of the computer system 10 of the first embodiment.
  • the figure shows the operation when the existing VM is deleted, in other words, when the existing virtual server is deleted.
  • the requester device 12 sends a VM deletion request to the cluster management device 14.
  • the VM management unit 24 of the cluster management device 14 receives the VM deletion request transmitted from the requester device 12 (Y in S20), it refers to the VMDB20 and the VM specified in the VM deletion request (“target VM”).
  • target VM The server 16 (referred to as a “target server”) executing the server 16 (referred to as “target server”) is identified (S22).
  • the VM management unit 24 cooperates with the VM control unit 34 of the target server to end the execution of the target VM on the target server (S24).
  • the VM management unit 24 records in the VMDB 20 that the target VM has been deleted from the target server, in other words, deletes the association between the target server and the target VM in the VMDB 20.
  • the VM management unit 24 notifies the server management unit 26 that the target VM has been deleted from the target server.
  • the server management unit 26 refers to the VMDB 20 and counts the number of VMs running on the target server. When the number of running VMs in the target server becomes 0 (Y in S26), the server management unit 26 sets the power mode of the CPU of the target server to C6 enable (S28). In other words, the server management unit 26 shifts the operating state of the target server from the operating state to the standby state.
  • the cluster management device 14 repeatedly executes a series of processes shown in FIG.
  • the power mode of the CPU in the server 16 is changed according to the execution mode of the VM in the server 16 constituting the cluster, in other words, the provision status of the virtual server.
  • the power mode of the server 16 that executes the VM is set to the power mode (C6 disabled) in which the CPU does not shift to the sleep state. This makes it possible to realize a virtual server suitable for application processing in real time (in other words, ultra-low latency).
  • the power consumption of the server 16 (VM unallocated) in which the power mode of the CPU is set to C6 disabled is 234 W
  • the power consumption of the server 16 (VM) in which the power mode of the CPU is set to C6 enabled is 234 W.
  • the power consumption (unallocated) was 140 W. That is, it was confirmed that the power consumption can be reduced by 41% by enabling C6 in the power mode of the CPU in the server 16 to which the VM is not allocated. Dozens to hundreds of servers 16 may be installed in a data center. For example, when 100 servers 16 are C6 enabled, power consumption of 9400 W can be suppressed.
  • FIG. 4 shows the configuration of the computer system 10 of the second embodiment.
  • the VM control unit 34 of the server 16 of the second embodiment has a function of the server management unit 26 of the cluster management device 14 of the first embodiment in addition to the function of the VM control unit 34 of the first embodiment.
  • the VM control unit 34 of the server 16 causes the CPU 30 to execute the program of the VM 32 according to the instruction from the cluster management device 14, and cooperates with the CPU control unit 36 to respond to a change in the VM execution mode in the server 16.
  • the power mode of the CPU 30 in the server 16 is changed.
  • the VM control unit 34 receives the VM execution instruction while the own machine is in the standby state, the VM control unit 34 cooperates with the CPU control unit 36 to shift the power mode of the CPU 30 of the own machine from C6 enable to C6 disable. ..
  • the computer system 10 of the second embodiment also has the same effect as the computer system 10 of the first embodiment.
  • the VM control unit 34 of the server 16 has the function of the server management unit 26 of the cluster management device 14 of the first embodiment, but as a modification, the CPU control unit 36 of the server 16 is the second.
  • the function of the server management unit 26 of the cluster management device 14 of one embodiment may be provided.
  • FIG. 5 shows the configuration of the computer system 10 of the third embodiment.
  • the server 16 of the third embodiment includes a power supply control unit 38 in addition to the functional block of the server 16 of the first embodiment shown in FIG.
  • the power supply control unit 38 controls whether or not power is supplied to the server 16 (that is, power on / off).
  • the operating state of each of the plurality of servers 16 is controlled to one of (1) operating state, (2) standby state, and (3) power off state.
  • the power supply control unit 38 of the third embodiment includes the function of the BMC.
  • the server management unit 26 of the cluster management device 14 accesses the power supply control unit 38 of the server 16 via IPMI, and remotely controls whether or not power is supplied to the server 16 (that is, power on / off).
  • the computer system 10 of the third embodiment includes an administrator terminal 18 operated by an administrator of the computer system 10.
  • the administrator terminal 18 transmits the value of the standby server ratio predetermined by the administrator to the cluster management device 14.
  • the standby server ratio is the ratio of the standby server 16 to the plurality of servers 16 (total number of servers 16 in the cluster). In the embodiment, the standby server ratio is set to 30%, but the standby server ratio may be a value different from 30%.
  • the standby server ratio may be determined to an appropriate value based on the knowledge of the administrator and an experiment using the computer system 10.
  • the server management unit 26 of the cluster management device 14 stores the standby server ratio transmitted from the administrator terminal 18.
  • the server management unit 26 has a plurality of servers 16 in the plurality of servers 16 depending on the change in the execution mode of the VM in at least one server 16 in the plurality of servers 16 and the standby server ratio stored in advance. Change the power mode of the CPU in at least one server.
  • the plurality of servers 16 include the first server in the standby state and the second server in the power off state (power supply stop state), and the VM management unit 24 of the cluster management device 14 is the first server. It is assumed that the execution of VM is decided. In this case, the server management unit 26 of the cluster management device 14 shifts the power mode of the CPU in the first server to the power mode (C6 disabled) in which the CPU does not shift to the sleep state, in other words, operates the first server. Move to the state. The VM management unit 24 causes the first server to execute the VM. The server management unit 26 shifts the second server to the standby state according to the standby server ratio.
  • the server management unit 26 shifts the certain server 16 to either a standby state or a power-off state according to the standby server ratio.
  • the server management unit 26 controls the operating state of the server 16 that has not executed the VM to either the standby state or the power-off state so as to maintain the standby server ratio determined by the administrator. Maintaining the standby server ratio may mean that the deviation between the actual ratio of the standby server 16 to the total number of servers 16 and the standby server ratio is within a predetermined threshold value (for example, within the range of ⁇ 5%). ..
  • FIG. 6 is a flowchart showing the operation of the computer system 10 of the third embodiment. Since the processes of S30 to S38 in the figure are the same as the processes of S10 to S18 in FIG. 2 described in the first embodiment, the description thereof will be omitted.
  • the VM management unit 24 of the cluster management device 14 determines a target server to execute a new VM from the servers 16 in the operating state or the standby state.
  • the standby server ratio here is 30%.
  • the server management unit 26 of the cluster management device 14 refers to the physical server DB 22, and the actual ratio of the standby server 16 to the total number of the managed servers 16 is determined. Check if it matches the standby server ratio. If the standby server ratio is inconsistent (typically, the actual ratio is below the standby server ratio beyond the threshold value, for example, the actual ratio is less than 25%) (N in S40), the server management unit. 26 shifts the server 16 in the power-off state to the standby state (S42). If the actual ratio of the standby server 16 to the total number of managed servers 16 matches the standby server ratio (for example, when the actual ratio is 25% to 35%) (Y in S40), skip S42. do.
  • the server management unit 26 turns on the power of the server 16 (shifts to the power supply state) in cooperation with the power control unit 38 of the server 16 in the power-off state. Further, the server management unit 26 cooperates with the CPU control unit 36 of the server 16 to set the CPU of the server 16 to C6 enable.
  • FIGS. 7 (a) and 7 (b) show an example of the operating state of a plurality of servers.
  • 10 servers 40 (servers 40a to 40j) are installed as a cluster.
  • the server 40 corresponds to the server 16 in FIG.
  • the server management unit 26 of the cluster management device 14 changes the server 40d from the standby state to the operating state. Migrate.
  • the number of servers 40 in the standby state becomes two (server 40e, server 40f), which is inconsistent with the standby server ratio.
  • the server management unit 26 selects one server 40 (here, the server 40 g) from the servers 40 in the power-off state, and puts the server 40 g on standby from the power-off state. Move to the state.
  • the number of servers 40 in the standby state is 3 (server 40e, server 40f, server 40g), and the state consistent with the standby server ratio is maintained.
  • FIG. 8 is also a flowchart showing the operation of the computer system 10 of the third embodiment. Since the processes of S50 to S54 in the figure are the same as the processes of S20 to S24 in FIG. 3 described in the first embodiment, the description thereof will be omitted.
  • the server management unit 26 of the cluster management device 14 matches the standby server ratio when the power of the target server is turned off. Determine whether or not to do so. In the case of matching (Y in S58), the server management unit 26 cooperates with the power control unit 38 of the target server to turn off the power of the target server (shift to the power supply stop state) (S60).
  • the server management unit 26 cooperates with the CPU control unit 36 of the target server while maintaining the power on state of the target server. Then, the power mode of the CPU of the target server is set to C6 enable (S62). That is, the target server is moved from the operating state to the standby state. If one or more VMs are being executed on the target server (N in S56), the processes of S58 to S62 are skipped.
  • the server management unit 26 has three servers 40 in the standby state (server 40e, server 40f, server 40g) among the ten servers 40, so that the standby server ratio Judged to be consistent with.
  • the server management unit 26 directly shifts the server 40d from the operating state to the power-off state by turning off the power of the server 40d.
  • the computer system 10 of the third embodiment it is possible to further suppress the power consumption of the entire server group by allowing a part of the server (compute node) that has not executed the VM to be in the power-off state. can. Also, by maintaining a certain number of servers in the standby state based on the standby server ratio, even if many new VMs should be started, those new VMs are started in a short time (for example, in the order of several seconds). be able to.
  • the functions of the VM control unit 34 and the CPU control unit 36 of the server 16 may be executed as the functions of the VM (or container).
  • the VM that executes the functions of the VM control unit 34 and the CPU control unit 36 is called a "basic VM”
  • the VM created in response to the VM creation request from the requester device 12 is called a "service VM”.
  • the server management unit 26 of the cluster management device 14 may count the number of service VMs running on the server 16 excluding the basic VMs, in other words. For example, the basic VM may be excluded from the counting target.
  • the server management unit 26 of the cluster management device 14 sets the standby server ratio determined by the administrator. If it cannot be maintained, alert information may be sent to the administrator terminal 18. For example, when the actual ratio of the standby server 16 to the total number of servers 16 exceeds the standby server ratio and falls below the threshold value, the server management unit 26 sends alert information to that effect to the administrator terminal 18. You may. As a result, it is possible to support the configuration management of the equipment in the data center, and for example, it is possible to support the determination of the addition of the server 16.
  • each of the constituent elements described in the claims are realized by a single component or their cooperation shown in the examples and modifications.
  • the management unit described in the claims may be realized by either the VM management unit 24 of the cluster management device 14 or the VM control unit 34 of the server 16 described in each embodiment, or both may cooperate with each other. It may be realized by doing.
  • the control unit described in the claims may be realized by either the server management unit 26 of the cluster management device 14 or the CPU control unit 36 of the server 16 described in each embodiment, or both may cooperate with each other. It may be realized by doing. That is, each of the management unit and the control unit described in the claims may be realized by any computer included in the computer system 10, or may be realized by coordinating a plurality of computers.
  • the technology of this disclosure can be applied to computer systems that manage workload execution.

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Power Sources (AREA)

Abstract

コンピュータシステム１０は、クラスタ管理装置１４とサーバ１６とを備える。クラスタ管理装置１４のＶＭ管理部２４は、サーバ１６におけるワークロード（例えばＶＭ（Virtual Machine）３２）の実行を管理する。クラスタ管理装置１４のサーバ管理部２６は、サーバ１６におけるワークロード（例えばＶＭ３２）の実行態様の変化に応じて、サーバ１６におけるＣＰＵ３０の電力モードを変更する。

Description

コンピュータシステムおよびコンピュータプログラム
　本開示は、コンピュータシステムおよびコンピュータプログラムに関する。
　多数の汎用サーバを予めデータセンタ等に設置しておき、必要が生じた際に、仮想マシンソフトウェアを汎用サーバに投入して、汎用サーバに特定の機能を発揮させる仮想化技術が知られている。
特開２０２０－０２７５３０号公報
　データセンタ等に事前設置される汎用サーバ群は、仮想マシンソフトウェアの投入を待つ状態においても仮想マシンソフトウェア実行時と同程度の電力が供給されているため、電力消費量が大きいという問題があった。
　本開示はこうした課題に鑑みてなされたものであり、１つの目的は、仮想化された環境においてワークロードを実行するコンピュータの電力消費を抑制する技術を提供することにある。
　上記課題を解決するために、本発明のある態様のコンピュータシステムは、サーバにおけるワークロードの実行を管理する管理部と、サーバにおけるワークロードの実行態様の変化に応じて、サーバにおけるＣＰＵの電力モードを変更する制御部と、を備える。
　本開示の別の態様は、コンピュータプログラムである。このコンピュータプログラムは、サーバにおけるワークロードの実行を管理する機能と、サーバにおけるワークロードの実行態様の変化に応じて、サーバにおけるＣＰＵの電力モードを変更する機能と、をコンピュータに実現させる。
　なお、以上の構成要素の任意の組合せ、本開示の表現を、装置、方法、コンピュータプログラムを読み取り可能に記録した記録媒体などの間で変換したものもまた、本開示の態様として有効である。
　本開示によれば、仮想化された環境においてワークロードを実行するコンピュータの電力消費を抑制することができる。
第１実施例のコンピュータシステムの構成を示す図である。 第１実施例のコンピュータシステムの動作を示すフローチャートである。 第１実施例のコンピュータシステムの動作を示すフローチャートである。 第２実施例のコンピュータシステムの構成を示す図である。 第３実施例のコンピュータシステムの構成を示す図である。 第３実施例のコンピュータシステムの動作を示すフローチャートである。 図７（ａ）と図７（ｂ）は、複数台のサーバの動作状態の例を示す図である。 第３実施例のコンピュータシステムの動作を示すフローチャートである。
　仮想化技術を利用して、情報システムの稼動に必要なサーバをはじめとした機材やネットワークなどのインフラを、インターネット上のサービスとして提供するＩａａＳ（Infrastructure as a Service）が普及してきている。ＩａａＳでは、多数の汎用サーバ（物理サーバ）を予めデータセンタ等に設置しておき、ユーザの要求に応じて、仮想マシンソフトウェア（以下「ＶＭ」とも呼ぶ。）を汎用サーバ（物理サーバ）に実行させることで、ユーザの要求に整合する仮想サーバを提供する。
　以下の実施例では、ＩａａＳを提供するコンピュータシステムにおいて、物理サーバにＶＭを配置する際に当該物理サーバのＣＰＵ（Central Processing Unit）の電力モードを変更し、具体的には、ＣＰＵのスリープ設定を変更する技術を提案する。実施例のコンピュータシステムによると、仮想化された環境においてオンデマンドでＶＭを実行するコンピュータの電力消費を抑制することができる。
　以下の実施例では、物理サーバに仮想化ソフトウェア「ＯｐｅｎＳｔａｃｋ」が導入され、物理サーバ上で１つ以上のＶＭが実行される。変形例として、物理サーバにコンテナエンジン「Ｄｏｃｋｅｒ」が導入され、物理サーバ上で１つ以上のコンテナ（「Ｐｏｄ」とも呼ばれる）が実行される構成でもよい。ＶＭとコンテナ（Ｐｏｄ）は、総称して「ワークロード」とも呼ばれる。
　（第１実施例）
　図１は、第１実施例のコンピュータシステム１０の構成を示す。コンピュータシステム１０は、データ処理システムともいえ、依頼者装置１２、クラスタ管理装置１４、複数台のサーバ（サーバ１６ａ、サーバ１６ｂ、サーバ１６ｃ・・・）を備える。以下、複数台のサーバ（サーバ１６ａ、サーバ１６ｂ、サーバ１６ｃ・・・）を総称して「サーバ１６」とも呼ぶ。クラスタ管理装置１４とサーバ１６は、データセンタに設置され、データセンタのＬＡＮで接続されてもよい。また、１つのデータセンタに、数十台から数百台のサーバ１６が設置されてもよい。また、依頼者装置１２とクラスタ管理装置１４は、インターネットを介して接続されてもよい。
　図１は、クラスタ管理装置１４およびサーバ１６の機能ブロックを示すブロック図を含む。本明細書のブロック図で示す複数の機能ブロックは、ハードウェア的には、回路ブロック、メモリ、その他のＬＳＩで構成することができ、ソフトウェア的には、メモリにロードされたプログラムをＣＰＵが実行すること等により実現される。したがって、これらの機能ブロックがハードウェアのみ、ソフトウェアのみ、またはそれらの組合せによっていろいろな形で実現できることは当業者には理解されるところであり、いずれかに限定されるものではない。
　サーバ１６は、コンピュートノードとも呼ばれる情報処理装置である。サーバ１６は、ＶＭを実行するための各種リソース（ＣＰＵ、メモリ、ストレージ等）を提供する物理サーバである。サーバ１６は、ＣＰＵ３０、ＶＭ３２、ＶＭ制御部３４、ＣＰＵ制御部３６を備える。
　ＶＭ制御部３４とＣＰＵ制御部３６は、コンピュータプログラムとして実装されてもよく、そのコンピュータプログラムがサーバ１６のストレージ（不図示）に記憶されてもよい。ＣＰＵ３０は、そのコンピュータプログラムをメインメモリ（不図示）に読み出して実行することにより、ＶＭ制御部３４とＣＰＵ制御部３６の機能を発揮してもよい。
　ＶＭ制御部３４は、サーバ１６におけるＶＭ３２の実行を制御する。具体的には、ＶＭ制御部３４は、クラスタ管理装置１４からの指示にしたがって、ＣＰＵ３０にＶＭ３２のプログラムを実行させることにより仮想サーバを実現させる。実施例では、ＶＭ３２のプログラムは、クラスタ管理装置１４から提供される。ＶＭ制御部３４は、ＯｐｅｎＳｔａｃｋの機能を利用して実現されてもよい。
　ＣＰＵ制御部３６は、サーバ１６におけるＣＰＵ３０の電力モードを制御する。実施例のＣＰＵ制御部３６は、公知のＢＭＣ（Baseboard Management Controller）の機能を含み、ＩＰＭＩ（Intelligent Platform Management Interface）を介して、リモートからＣＰＵ３０の電力モードの変更の要求を受け付ける。
　実施例では、ＣＰＵ制御部３６は、クラスタ管理装置１４からの指示にしたがって、ＣＰＵ３０の電力モードを、（１）ＣＰＵがスリープ状態に移行しない電力モードであり、言い換えれば、ＣＰＵがスリープ状態に移行することが禁止された電力モード（以下「Ｃ６ディセーブル」とも呼ぶ。）に移行させる。また、ＣＰＵ制御部３６は、クラスタ管理装置１４からの指示にしたがって、ＣＰＵ３０の電力モードを、（２）ＣＰＵがスリープ状態に移行することが許可された電力モードであり、例えば、ＶＭ等のタスクを実行しない場合にＣＰＵがスリープ状態となる電力モード（以下「Ｃ６イネーブル」とも呼ぶ。）に移行させる。
　「Ｃ６」は、ＣＰＵ３０の電力モードを示すＣステートにおいて最も深いスリープ状態であり、ＣＰＵ３０の消費電力が最も小さくなる。また、「Ｃ６」から稼働状態「Ｃ０」への復帰は、他のＣステートからの復帰と比べて長い時間を要するが、それでも１秒未満である。本実施例では、ＶＭを実行中でないサーバ１６のＣＰＵ３０をＣ６のスリープ状態とする。なお、ＶＭを実行中でないサーバ１６におけるＣＰＵ３０のスリープ態様（Ｃステート）はＣ６に限られない。消費電力とＣ０への復帰時間とを比較考量し、適切なスリープ態様が開発者により決定されればよい。
　実施例では、ＶＭ３２により実現される仮想サーバは、電気通信事業者の業務に関するアプリケーションを実行する。このアプリケーションは、例えば、第５世代移動通信システム（５Ｇ）のＲＡＮ（Radio Access Network）のアプリケーション（ｖＣＵ、ｖＤＵ等）であってもよく、５Ｇのコアネットワークシステムのアプリケーション（ＡＭＦ、ＳＭＦ等）であってもよい。電気通信事業者の業務アプリケーションは、リアルタイム処理（言い換えれば超低遅延処理）が求められるため、ＶＭ３２は、ＣＰＵがスリープ状態に移行しない電力モード（Ｃ６ディセーブル）のサーバ１６で実行されるべきものである。
　依頼者装置１２は、ＶＭ（言い換えれば仮想サーバ）の作成または削除を依頼する情報処理装置である。依頼者装置１２は、人が操作する装置（ＰＣ等）であってもよく、ＥＭＳ（Element Management System）等、人を介さず自動的なデータ処理を実行するシステム・装置であってもよい。依頼者装置１２は、ＶＭ作成要求またはＶＭ削除要求をクラスタ管理装置１４へ送信する。ＶＭ作成要求は、新規のＶＭに割り当てるＣＰＵ、メモリ、ストレージそれぞれのリソース量や、ＯＳの種類等を指定する情報を含んでもよい。ＶＭ削除要求は、削除対象のＶＭの識別情報を含んでもよい。
　クラスタ管理装置１４は、複数台のサーバ１６（「クラスタ」とも呼ばれる）を管理する情報処理装置である。図１では、クラスタ管理装置１４を１つ描いているが、クラスタ管理装置１４は、複数台の装置により冗長化されてもよい。クラスタ管理装置１４は、ＶＭＤＢ２０、物理サーバＤＢ２２、ＶＭ管理部２４、サーバ管理部２６を備える。
　ＶＭＤＢ２０は、サーバ１６でＶＭを実行するためのＶＭのイメージデータ（プログラム）を記憶する。また、ＶＭＤＢ２０は、サーバ１６の識別情報と、そのサーバ１６で実行中のＶＭの識別情報とを対応付けて記憶する。言い換えれば、ＶＭＤＢ２０は、複数台のサーバ１６のそれぞれで実行中のＶＭに関する情報（ＶＭのＩＤ等）を記憶する。
　また、ＶＭＤＢ２０は、複数台のサーバ１６の中からＶＭを実行させるサーバ１６を決定するために必要なデータを記憶する。例えば、ＶＭＤＢ２０は、各サーバ１６のハードウェアリソース（ＣＰＵ、メモリ、ストレージ等）の空き容量を記憶してもよい。ＶＭＤＢ２０は、ＯｐｅｎＳｔａｃｋの機能を利用して実現されてもよい。
　物理サーバＤＢ２２は、複数台のサーバ１６それぞれの識別情報と、各サーバ１６との通信に必要なデータを記憶する。例えば、物理サーバＤＢ２２は、複数台のサーバ１６それぞれの（１）ホスト名、（２）ＩＰアドレス、（３）ＩＰＭＩを介して各サーバ１６のＢＭＣ（ＣＰＵ制御部３６）にアクセスするために必要な情報を記憶してもよい。
　また、物理サーバＤＢ２２は、複数台のサーバ１６それぞれの動作状態を記憶し、言い換えれば、各サーバ１６が複数の動作状態のうちいずれであるかを示すデータを記憶する。複数の動作状態は、（１）稼働状態、（２）スタンバイ状態、（３）電源オフ状態を含む。（１）稼働状態は、電力が供給されており（電源オン状態）、かつ、ＣＰＵがスリープ状態に移行しない電力モード（Ｃ６ディセーブル）に設定された動作状態である。（２）スタンバイ状態は、電力が供給されており（電源オン状態）、かつ、ＣＰＵがスリープ状態に移行可能な電力モード（Ｃ６イネーブル）に設定された動作状態である。（３）電源オフ状態は、電力供給が停止された状態であり、電源切断状態とも言える。
　ＶＭ管理部２４とサーバ管理部２６は、コンピュータプログラムとして実装されてもよく、そのコンピュータプログラムがクラスタ管理装置１４のストレージ（不図示）に記憶されてもよい。クラスタ管理装置１４のＣＰＵは、そのコンピュータプログラムをメインメモリ（不図示）に読み出して実行することにより、ＶＭ管理部２４とサーバ管理部２６の機能を発揮してもよい。
　ＶＭ管理部２４は、複数台のサーバ１６のそれぞれにおけるＶＭの実行を管理する。ＶＭ管理部２４は、ＯｐｅｎＳｔａｃｋの機能を利用して実現されてもよい。ＶＭ管理部２４は、依頼者装置１２から送信されたＶＭ作成要求を受け付けると、ＶＭ作成要求が示すハードウェアリソース量と、ＶＭＤＢ２０に記憶された各サーバ１６でのＶＭ実行状況および空きリソース量とに応じて、複数台のサーバ１６の中からＶＭを実行させるサーバ１６（以下「対象サーバ」とも呼ぶ。）を決定する。ＶＭ管理部２４は、対象サーバのＶＭ制御部３４に、ＶＭ作成要求に対応するＶＭのイメージデータを送信し、対象サーバにおけるＶＭの実行を開始させる。
　サーバ管理部２６は、サーバ１６におけるＶＭの実行態様の変化に応じて、サーバ１６におけるＣＰＵの電力モードを変更する。第１実施例では、サーバ管理部２６は、管理対象の複数台のサーバ１６の中の少なくとも１台のサーバ１６におけるＶＭの実行態様が変化することに応じて、複数台のサーバ１６の中の少なくとも１台のサーバ１６におけるＣＰＵの電力モードを変更する。
　また、サーバ管理部２６は、ＶＭ管理部２４が或るサーバ１６でのＶＭの実行を決定した場合、上記或るサーバ１６におけるＣＰＵの電力モードを、ＣＰＵがスリープ状態に移行しない電力モード（Ｃ６ディセーブル）に移行させる。サーバ管理部２６は、ＩＰＭＩを介して各サーバ１６のＢＭＣ（ＣＰＵ制御部３６）にアクセスすることにより、各サーバ１６におけるＣＰＵの電力モードを変更してもよい。
　第１実施例のコンピュータシステム１０の動作を説明する。ここでは、複数台のサーバ１６それぞれの動作状態は、稼働状態とスタンバイ状態のいずれかに設定される。また、ＶＭを実行中でないサーバ１６の動作状態は、スタンバイ状態に設定される。
　図２は、第１実施例のコンピュータシステム１０の動作を示すフローチャートである。同図は、新たなＶＭ作成時、言い換えれば、新たな仮想サーバ作成時の動作を示している。依頼者装置１２は、ＶＭ作成要求をクラスタ管理装置１４へ送信する。クラスタ管理装置１４のＶＭ管理部２４は、依頼者装置１２から送信されたＶＭ作成要求を受け付けると（Ｓ１０のＹ）、ＶＭ作成要求に適合する新規ＶＭを実行するサーバ１６（「対象サーバ」と呼ぶ。）を決定する（Ｓ１２）。ＶＭ管理部２４は、対象サーバの識別情報（例えばホスト名等）をサーバ管理部２６に通知する。
　サーバ管理部２６は、物理サーバＤＢ２２を参照して、ＶＭ管理部２４から通知された対象サーバがスタンバイ状態か否かを確認する。対象サーバがスタンバイ状態であれば（Ｓ１４のＹ）、サーバ管理部２６は、対象サーバのＣＰＵ制御部３６と連携して、対象サーバのＣＰＵの電力モードをＣ６ディセーブルに設定する（Ｓ１６）。言い換えれば、サーバ管理部２６は、対象サーバの動作状態をスタンバイ状態から稼働状態へ移行させる。対象サーバが稼働状態であれば（Ｓ１４のＮ）、Ｓ１６の処理をスキップする。サーバ管理部２６は、対象サーバが稼働状態である旨をＶＭ管理部２４へ通知する。
　ＶＭ管理部２４は、対象サーバのＶＭ制御部３４と連携して、対象サーバにおいてＶＭの実行を開始させる（Ｓ１８）。ＶＭ管理部２４は、対象サーバにおいて新規ＶＭが実行されることをＶＭＤＢ２０に記録する。ＶＭ作成要求を受け付けなければ（Ｓ１０のＮ）、Ｓ１２以降の処理をスキップする。クラスタ管理装置１４は、図２に示す一連の処理を繰り返し実行する。
　図３も、第１実施例のコンピュータシステム１０の動作を示すフローチャートである。同図は、既存のＶＭ削除時、言い換えれば、既存の仮想サーバ削除時の動作を示している。依頼者装置１２は、ＶＭ削除要求をクラスタ管理装置１４へ送信する。クラスタ管理装置１４のＶＭ管理部２４は、依頼者装置１２から送信されたＶＭ削除要求を受け付けると（Ｓ２０のＹ）、ＶＭＤＢ２０を参照して、ＶＭ削除要求で指定されたＶＭ（「対象ＶＭ」と呼ぶ。）を実行しているサーバ１６（「対象サーバ」と呼ぶ。）を識別する（Ｓ２２）。ＶＭ管理部２４は、対象サーバのＶＭ制御部３４と連携して、対象サーバにおける対象ＶＭの実行を終了させる（Ｓ２４）。
　ＶＭ管理部２４は、対象サーバから対象ＶＭが削除されたことをＶＭＤＢ２０に記録し、言い換えれば、ＶＭＤＢ２０における対象サーバと対象ＶＭとの対応付けを削除する。ＶＭ管理部２４は、対象サーバから対象ＶＭを削除した旨をサーバ管理部２６へ通知する。サーバ管理部２６は、ＶＭＤＢ２０を参照して、対象サーバにおいて実行中のＶＭ数を計数する。対象サーバにおいて実行中のＶＭ数が０になった場合（Ｓ２６のＹ）、サーバ管理部２６は、対象サーバのＣＰＵの電力モードをＣ６イネーブルに設定する（Ｓ２８）。言い換えれば、サーバ管理部２６は、対象サーバの動作状態を稼働状態からスタンバイ状態へ移行させる。
　対象サーバにおいて１つ以上のＶＭが実行中であれば（Ｓ２６のＮ）、Ｓ２８をスキップする。ＶＭ削除要求を受け付けなければ（Ｓ２０のＮ）、Ｓ２２以降の処理をスキップする。クラスタ管理装置１４は、図３に示す一連の処理を繰り返し実行する。
　第１実施例のコンピュータシステム１０によると、クラスタを構成するサーバ１６におけるＶＭの実行態様、言い換えれば、仮想サーバの提供状況に応じて、サーバ１６におけるＣＰＵの電力モードを変更する。これにより、仮想化された環境においてオンデマンドでＶＭを実行するサーバ１６の電力消費を抑制することができる。また、コンピュータシステム１０によると、ＶＭを実行するサーバ１６の電力モードをＣＰＵがスリープ状態に移行しない電力モード（Ｃ６ディセーブル）に設定する。これにより、リアルタイム（言い換えれば超低遅延）でのアプリケーション処理に適した仮想サーバを実現することができる。
　本発明者による実験では、ＣＰＵの電力モードをＣ６ディセーブルに設定したサーバ１６（ＶＭ未割当）の消費電力が２３４Ｗであるのに対し、ＣＰＵの電力モードをＣ６イネーブルに設定したサーバ１６（ＶＭ未割当）の消費電力は１４０Ｗであった。すなわち、ＶＭを未割当のサーバ１６においてＣＰＵの電力モードをＣ６イネーブルとすることで消費電力を４１％削減できることが確かめられた。データセンタには、数十台から数百台のサーバ１６が設置されることがあるが、例えば、１００台のサーバ１６がＣ６イネーブルとなる場合、９４００Ｗの電力消費を抑制することができる。
　なお、サーバ１６が電源オフ状態から稼働状態へ移行するには数分～１０分程度要するが、スタンバイ状態（Ｃ６イネーブル）から稼働状態（Ｃ６ディセーブル）へ移行は、既述したように１秒未満である。第１実施例では、ＶＭを未実行のサーバ１６をスタンバイ状態で待機させることにより、ＶＭを未実行のサーバ１６における消費電力を抑制しつつ、ＶＭ実行開始までの時間を短くすることができる。
　（第２実施例）
　本実施例に関して、第１実施例と相違する点を中心に以下説明し、共通する点の説明を適宜省略する。本実施例の構成要素のうち第１実施例の構成要素と同一または対応する構成要素には同一の符号を付して説明する。
　図４は、第２実施例のコンピュータシステム１０の構成を示す。第２実施例のサーバ１６のＶＭ制御部３４は、第１実施例のＶＭ制御部３４の機能に加えて、第１実施例のクラスタ管理装置１４のサーバ管理部２６の機能を備える。
　例えば、サーバ１６のＶＭ制御部３４は、クラスタ管理装置１４からの指示にしたがって、ＣＰＵ３０にＶＭ３２のプログラムを実行させるとともに、ＣＰＵ制御部３６と連携して、サーバ１６におけるＶＭ実行態様の変化に応じて、サーバ１６におけるＣＰＵ３０の電力モードを変更する。また、ＶＭ制御部３４は、自機がスタンバイ状態であるときにＶＭ実行指示を受け付けると、ＣＰＵ制御部３６と連携して、自機のＣＰＵ３０の電力モードをＣ６イネーブルからＣ６ディセーブルに移行させる。
　第２実施例のコンピュータシステム１０においても、第１実施例のコンピュータシステム１０と同様の効果を奏する。なお、第２実施例では、サーバ１６のＶＭ制御部３４が第１実施例のクラスタ管理装置１４のサーバ管理部２６の機能を備えたが、変形例として、サーバ１６のＣＰＵ制御部３６が第１実施例のクラスタ管理装置１４のサーバ管理部２６の機能を備えてもよい。
　（第３実施例）
　本実施例に関して、第１実施例と相違する点を中心に以下説明し、共通する点の説明を適宜省略する。本実施例の構成要素のうち第１実施例の構成要素と同一または対応する構成要素には同一の符号を付して説明する。
　図５は、第３実施例のコンピュータシステム１０の構成を示す。第３実施例のサーバ１６は、図１に示した第１実施例のサーバ１６の機能ブロックに加えて、電源制御部３８を備える。電源制御部３８は、サーバ１６への電力供給有無（すなわち電源のオン／オフ）を制御する。第３実施例において、複数台のサーバ１６それぞれの動作状態は、（１）稼働状態、（２）スタンバイ状態、（３）電源オフ状態のいずれかに制御される。
　なお、第３実施例の電源制御部３８は、ＢＭＣの機能を含むこととする。クラスタ管理装置１４のサーバ管理部２６は、ＩＰＭＩを介してサーバ１６の電源制御部３８にアクセスし、サーバ１６への電力供給有無（すなわち電源のオン／オフ）をリモートから制御することとする。
　第３実施例のコンピュータシステム１０は、コンピュータシステム１０の管理者により操作される管理者端末１８を備える。管理者端末１８は、管理者により予め定められたスタンバイサーバ比率の値をクラスタ管理装置１４へ送信する。スタンバイサーバ比率は、複数台のサーバ１６（クラスタにおけるサーバ１６の総数）に占めるスタンバイ状態のサーバ１６のあるべき割合である。実施例ではスタンバイサーバ比率を３０％とするが、スタンバイサーバ比率は３０％とは異なる値でもよい。スタンバイサーバ比率は、管理者の知見やコンピュータシステム１０を用いた実験に基づいて適切な値に決定されてよい。
　クラスタ管理装置１４のサーバ管理部２６は、管理者端末１８から送信されたスタンバイサーバ比率を記憶する。サーバ管理部２６は、複数台のサーバ１６の中の少なくとも１台のサーバ１６におけるＶＭの実行態様が変化することと、予め記憶するスタンバイサーバ比率とに応じて、複数台のサーバ１６の中の少なくとも１台のサーバにおけるＣＰＵの電力モードを変更する。
　ここで、複数のサーバ１６が、スタンバイ状態の第１サーバと、電源オフ状態（電力供給停止状態）の第２サーバとを含み、クラスタ管理装置１４のＶＭ管理部２４が、第１サーバでのＶＭの実行を決定したこととする。この場合、クラスタ管理装置１４のサーバ管理部２６は、第１サーバにおけるＣＰＵの電力モードを、ＣＰＵがスリープ状態に移行しない電力モード（Ｃ６ディセーブル）に移行させ、言い換えれば、第１サーバを稼働状態に移行させる。ＶＭ管理部２４は、第１サーバにおいてＶＭを実行させる。サーバ管理部２６は、スタンバイサーバ比率に応じて、第２サーバをスタンバイ状態に移行させる。
　また、ＶＭ管理部２４が或るサーバ１６におけるＶＭの実行を終了させ、上記或るサーバ１６で実行されるＶＭが無くなったこととする。この場合、サーバ管理部２６は、スタンバイサーバ比率に応じて、上記或るサーバ１６をスタンバイ状態と電源オフ状態のいずれかに移行させる。サーバ管理部２６は、管理者により定められたスタンバイサーバ比率を維持するように、ＶＭ未実行のサーバ１６の動作状態をスタンバイ状態と電源オフ状態のいずれかに制御する。スタンバイサーバ比率を維持するとは、サーバ１６の総数に占めるスタンバイ状態のサーバ１６の実際の比率と、スタンバイサーバ比率との乖離が所定の閾値内（例えば±５％の範囲内）になることでもよい。
　第３実施例のコンピュータシステム１０の動作を説明する。
　図６は、第３実施例のコンピュータシステム１０の動作を示すフローチャートである。同図のＳ３０～Ｓ３８の処理は、第１実施例で説明した図２のＳ１０～Ｓ１８の処理と同じであるため説明を省略する。なお、Ｓ１２において、クラスタ管理装置１４のＶＭ管理部２４は、稼働状態またはスタンバイ状態のサーバ１６の中から、新規ＶＭを実行する対象サーバを決定する。ここでのスタンバイサーバ比率は３０％とする。
　対象サーバに新規ＶＭを実行させた後、クラスタ管理装置１４のサーバ管理部２６は、物理サーバＤＢ２２を参照して、管理対象のサーバ１６の総数に占めるスタンバイ状態のサーバ１６の実際の比率が、スタンバイサーバ比率に整合するか否かを確認する。スタンバイサーバ比率に不整合の場合（典型的には実際の比率がスタンバイサーバ比率を閾値を超えて下回る場合であり、例えば実際の比率が２５％未満の場合）（Ｓ４０のＮ）、サーバ管理部２６は、電源オフ状態のサーバ１６をスタンバイ状態に移行させる（Ｓ４２）。
管理対象のサーバ１６の総数に占めるスタンバイ状態のサーバ１６の実際の比率が、スタンバイサーバ比率に整合する場合（例えば実際の比率が２５％～３５％の場合）（Ｓ４０のＹ）、Ｓ４２をスキップする。
　Ｓ４２において、具体的には、サーバ管理部２６は、電源オフ状態のサーバ１６の電源制御部３８と連携して、当該サーバ１６の電源をオンする（電力供給状態に移行させる）。また、サーバ管理部２６は、当該サーバ１６のＣＰＵ制御部３６と連携して、当該サーバ１６のＣＰＵをＣ６イネーブルに設定する。
　図７（ａ）と図７（ｂ）は、複数台のサーバの動作状態の例を示す。この例では、クラスタとして１０台のサーバ４０（サーバ４０ａ～サーバ４０ｊ）が設置されている。サーバ４０は、図５のサーバ１６に対応する。図７（ａ）の状態でクラスタ管理装置１４のＶＭ管理部２４が、サーバ４０ｄにおける新規ＶＭの実行を決定すると、クラスタ管理装置１４のサーバ管理部２６は、サーバ４０ｄをスタンバイ状態から稼働状態に移行させる。その結果、１０台のサーバ４０の中でスタンバイ状態のサーバ４０は２台（サーバ４０ｅ、サーバ４０ｆ）となり、スタンバイサーバ比率に不整合となる。
　そこで、図７（ｂ）に示すように、サーバ管理部２６は、電源オフ状態のサーバ４０の中から１台のサーバ４０（ここではサーバ４０ｇ）を選択し、サーバ４０ｇを電源オフ状態からスタンバイ状態に移行させる。この結果、１０台のサーバ４０の中でスタンバイ状態のサーバ４０は３台（サーバ４０ｅ、サーバ４０ｆ、サーバ４０ｇ）となり、スタンバイサーバ比率に整合する状態が維持される。
　図８も、第３実施例のコンピュータシステム１０の動作を示すフローチャートである。同図のＳ５０～Ｓ５４の処理は、第１実施例で説明した図３のＳ２０～Ｓ２４の処理と同じであるため説明を省略する。
　ＶＭが削除された対象サーバにおいて実行中のＶＭ数が０になった場合（Ｓ５６のＹ）、クラスタ管理装置１４のサーバ管理部２６は、対象サーバの電源をオフした場合にスタンバイサーバ比率に整合するか否かを判定する。整合する場合（Ｓ５８のＹ）、サーバ管理部２６は、対象サーバの電源制御部３８と連携して、対象サーバの電源をオフする（電力供給停止状態に移行させる）（Ｓ６０）。
　対象サーバの電源をオフした場合にスタンバイサーバ比率に不整合となる場合（Ｓ５８のＮ）、サーバ管理部２６は、対象サーバの電源オン状態を維持しつつ、対象サーバのＣＰＵ制御部３６と連携して、対象サーバのＣＰＵの電力モードをＣ６イネーブルに設定する（Ｓ６２）。すなわち、対象サーバを稼働状態からスタンバイ状態へ移行させる。対象サーバにおいて１つ以上のＶＭが実行中であれば（Ｓ５６のＮ）、Ｓ５８～Ｓ６２の処理をスキップする。
　例えば、図７（ｂ）に示す複数台のサーバ４０の動作状態において、サーバ４０ｄからＶＭが削除されたとする。このとき、サーバ管理部２６は、サーバ４０ｄの電源をオフすると、１０台のサーバ４０の中でスタンバイ状態のサーバ４０は３台（サーバ４０ｅ、サーバ４０ｆ、サーバ４０ｇ）となるため、スタンバイサーバ比率に整合すると判定する。サーバ管理部２６は、サーバ４０ｄの電源をオフすることにより、サーバ４０ｄを稼働状態から電源オフ状態に直接移行させる。
　第３実施例のコンピュータシステム１０によると、ＶＭを未実行のサーバ（コンピュートノード）の一部が電源オフ状態となることを許容することにより、サーバ群全体での電力消費を一層抑制することができる。また、スタンバイサーバ比率に基づいて、スタンバイ状態のサーバ台数を一定程度維持することにより、多くの新規ＶＭを起動すべき場合でも、短時間で（例えば数秒のオーダで）それらの新規ＶＭを起動することができる。
　以上、本開示を第１実施例～第３実施例をもとに説明した。これらの実施例は例示であり、各構成要素あるいは各処理プロセスの組合せにいろいろな変形例が可能なこと、またそうした変形例も本開示の技術の範囲にあることは当業者に理解されるところである。
　第１実施例～第３実施例に関する変形例を説明する。サーバ１６のＶＭ制御部３４とＣＰＵ制御部３６の機能は、ＶＭ（もしくはコンテナ）の機能として実行されてもよい。ここでは、ＶＭ制御部３４とＣＰＵ制御部３６の機能を実行するＶＭを「基本ＶＭ」と呼び、依頼者装置１２からのＶＭ作成要求に応じて作成されるＶＭを「サービスＶＭ」と呼ぶ。クラスタ管理装置１４のサーバ管理部２６は、サーバ１６でのＶＭ実行数を計数する場合、サーバ１６で実行中のＶＭの中から基本ＶＭを除いたサービスＶＭの個数を計数してもよく、言い換えれば、基本ＶＭを計数対象から除外してもよい。
　第３実施例に関する変形例を説明する。クラスタ管理装置１４のサーバ管理部２６は、複数台のサーバ１６のうち少なくとも１台のサーバ１６の動作モード（言い換えればＣＰＵの電力モード）を変更した結果、管理者により定められたスタンバイサーバ比率を維持できない場合、管理者端末１８へアラート情報を送信してもよい。例えば、サーバ１６の総数に占めるスタンバイ状態のサーバ１６の実際の比率が、スタンバイサーバ比率を閾値を超えて下回った場合、サーバ管理部２６は、その旨を示すアラート情報を管理者端末１８へ送信してもよい。これにより、データセンタにおける機器の構成管理を支援することができ、例えば、サーバ１６の増設等の判断を支援することができる。
　上述した実施例および変形例の任意の組み合わせもまた本開示の実施の形態として有用である。組み合わせによって生じる新たな実施の形態は、組み合わされる実施例および変形例それぞれの効果をあわせもつ。
　また、請求項に記載の各構成要件が果たすべき機能は、実施例および変形例において示された各構成要素の単体もしくはそれらの連携によって実現されることも当業者には理解されるところである。例えば、請求項に記載の管理部は、各実施例に記載した、クラスタ管理装置１４のＶＭ管理部２４とサーバ１６のＶＭ制御部３４のいずれか一方により実現されてもよく、または両者が連携することにより実現されてもよい。また、請求項に記載の制御部は、各実施例に記載した、クラスタ管理装置１４のサーバ管理部２６とサーバ１６のＣＰＵ制御部３６のいずれか一方により実現されてもよく、または両者が連携することにより実現されてもよい。すなわち、請求項に記載の管理部と制御部のそれぞれは、コンピュータシステム１０に含まれるいずれかのコンピュータで実現されてもよく、複数台のコンピュータが連携することにより実現されてもよい。
　本開示の技術は、ワークロードの実行を管理するコンピュータシステムに適用することができる。
　１０　コンピュータシステム、　１４　クラスタ管理装置、　１６　サーバ、　２４　ＶＭ管理部、　２６　サーバ管理部、　３０　ＣＰＵ、　３４　ＶＭ制御部、　３６　ＣＰＵ制御部、　３８　電源制御部。

Claims (7)

  1. 　サーバにおけるワークロードの実行を管理する管理部と、
    　前記サーバにおけるワークロードの実行態様の変化に応じて、前記サーバにおけるＣＰＵの電力モードを変更する制御部と、
    　を備えることを特徴とするコンピュータシステム。
  2. 　前記ワークロードは、ＣＰＵがスリープ状態に移行しない電力モードのサーバにおいて実行されるべきものであり、
    　前記制御部は、前記管理部が或るサーバでのワークロードの実行を決定した場合、前記或るサーバにおけるＣＰＵの電力モードを、ＣＰＵがスリープ状態に移行しない電力モードに移行させる、請求項１に記載のコンピュータシステム。
  3. 　前記管理部は、複数台のサーバのそれぞれにおけるワークロードの実行を管理し、
    　前記制御部は、電力が供給されているがＣＰＵがスリープ状態であるスタンバイ状態のサーバについて、前記複数台のサーバに占めるスタンバイ状態のサーバのあるべき割合を示すスタンバイサーバ比率を記憶し、
    　前記制御部は、前記複数台のサーバの中の少なくとも１台のサーバにおけるワークロードの実行態様が変化することと前記スタンバイサーバ比率とに応じて、前記複数台のサーバの中の少なくとも１台のサーバにおけるＣＰＵの電力モードを変更する、請求項１または２に記載のコンピュータシステム。
  4. 　前記複数台のサーバが、スタンバイ状態の第１サーバと、電力供給停止状態の第２サーバとを含み、前記管理部が、前記第１サーバでのワークロードの実行を決定した場合、
    　前記制御部は、前記第１サーバにおけるＣＰＵの電力モードを、ＣＰＵがスリープ状態に移行しない電力モードに移行させ、
    　前記管理部は、前記第１サーバにおいてワークロードを実行させ、
    　前記制御部は、前記スタンバイサーバ比率に応じて、前記第２サーバをスタンバイ状態に移行させる、請求項３に記載のコンピュータシステム。
  5. 　前記管理部が或るサーバにおけるワークロードの実行を終了させ、前記或るサーバで実行されるワークロードがなくなった場合、前記制御部は、前記スタンバイサーバ比率に応じて、前記或るサーバをスタンバイ状態と電力供給停止状態のいずれかに移行させる、請求項３または４に記載のコンピュータシステム。
  6. 　前記ワークロードは、仮想化ソフトウェア上で動作する仮想マシンソフトウェアまたはコンテナである、請求項１から５のいずれかに記載のコンピュータシステム。
  7. 　サーバにおけるワークロードの実行を管理する機能と、
    　前記サーバにおけるワークロードの実行態様の変化に応じて、前記サーバにおけるＣＰＵの電力モードを変更する機能と、
    　をコンピュータに実現させるためのコンピュータプログラム。
PCT/JP2021/031592 2020-09-03 2021-08-27 コンピュータシステムおよびコンピュータプログラム WO2022050197A1 (ja)

Priority Applications (1)

Application Number Priority Date Filing Date Title
US17/793,921 US20230058193A1 (en) 2020-09-03 2021-08-27 Computer system and storage medium

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
JP2020148060A JP2023159472A (ja) 2020-09-03 2020-09-03 コンピュータシステムおよびコンピュータプログラム
JP2020-148060 2020-09-03

Publications (1)

Publication Number Publication Date
WO2022050197A1 true WO2022050197A1 (ja) 2022-03-10

Family

ID=80491711

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2021/031592 WO2022050197A1 (ja) 2020-09-03 2021-08-27 コンピュータシステムおよびコンピュータプログラム

Country Status (3)

Country Link
US (1) US20230058193A1 (ja)
JP (1) JP2023159472A (ja)
WO (1) WO2022050197A1 (ja)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11799739B1 (en) * 2022-06-08 2023-10-24 Sap Se Matching of virtual machines to physical nodes for resource optimization

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2015022671A (ja) * 2013-07-23 2015-02-02 日本電信電話株式会社 サーバ仮想化環境における予備系装置の配備装置およびその配備方法
JP2016110240A (ja) * 2014-12-03 2016-06-20 日本電信電話株式会社 電源制御装置、サーバ仮想化システム、および、電源制御方法

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2015022671A (ja) * 2013-07-23 2015-02-02 日本電信電話株式会社 サーバ仮想化環境における予備系装置の配備装置およびその配備方法
JP2016110240A (ja) * 2014-12-03 2016-06-20 日本電信電話株式会社 電源制御装置、サーバ仮想化システム、および、電源制御方法

Also Published As

Publication number Publication date
US20230058193A1 (en) 2023-02-23
JP2023159472A (ja) 2023-11-01

Similar Documents

Publication Publication Date Title
US11237871B1 (en) Methods, systems, and devices for adaptive data resource assignment and placement in distributed data storage systems
JP7138126B2 (ja) リソース配置を最適化するための適時性リソース移行
US9329910B2 (en) Distributed power delivery
US9874924B1 (en) Equipment rack power reduction using virtual machine instance migration
CA2929590C (en) Session idle optimization for streaming server
US9110717B2 (en) Managing use of lease resources allocated on fallover in a high availability computing environment
JP6372074B2 (ja) 情報処理システム，制御プログラム及び制御方法
US20140040474A1 (en) Maximizing server utilization within a datacenter
CN103608792A (zh) 支持多核架构下资源隔离的方法及系统
US20190317824A1 (en) Deployment of services across clusters of nodes
JP6123626B2 (ja) 処理再開方法、処理再開プログラムおよび情報処理システム
US11249790B1 (en) Scheduling usage of oversubscribed computing resources
US8910152B1 (en) Migrating a virtual machine by using a hot-plug event
Hsieh et al. The incremental load balance cloud algorithm by using dynamic data deployment
Lin et al. Capacity optimization for resource pooling in virtualized data centers with composable systems
WO2022050197A1 (ja) コンピュータシステムおよびコンピュータプログラム
WO2016122595A1 (en) Chunk monitoring
US11726684B1 (en) Cluster rebalance using user defined rules
US11531572B2 (en) Cross-cluster host reassignment
US11182189B2 (en) Resource optimization for virtualization environments
EP4046021A1 (en) Virtual machine operation management in computing devices
EP3871087A1 (en) Managing power request during cluster operations
Michael et al. Downtime-free live migration in a multitenant database
JPH08212090A (ja) サーバシステム
US11126452B2 (en) Performance modeling for virtualization environments

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 21864255

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 21864255

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: JP