WO2019160030A1 - サービス提供システム、資源割り当て方法、及び資源割り当てプログラム - Google Patents

サービス提供システム、資源割り当て方法、及び資源割り当てプログラム Download PDF

Info

Publication number
WO2019160030A1
WO2019160030A1 PCT/JP2019/005325 JP2019005325W WO2019160030A1 WO 2019160030 A1 WO2019160030 A1 WO 2019160030A1 JP 2019005325 W JP2019005325 W JP 2019005325W WO 2019160030 A1 WO2019160030 A1 WO 2019160030A1
Authority
WO
WIPO (PCT)
Prior art keywords
virtual machine
virtual
resource
core
resource allocation
Prior art date
Application number
PCT/JP2019/005325
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 US16/970,591 priority Critical patent/US11640314B2/en
Publication of WO2019160030A1 publication Critical patent/WO2019160030A1/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/46—Multiprogramming arrangements
    • G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
    • G06F9/5061—Partitioning or combining of resources
    • 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
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/0703—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
    • G06F11/0751—Error or fault detection not based on redundancy
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/16—Error detection or correction of the data by redundancy in hardware
    • G06F11/20—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements
    • G06F11/202—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements where processing functionality is redundant
    • G06F11/2023—Failover techniques
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/16—Error detection or correction of the data by redundancy in hardware
    • G06F11/20—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements
    • G06F11/202—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements where processing functionality is redundant
    • G06F11/2023—Failover techniques
    • G06F11/2028—Failover techniques eliminating a faulty processor or activating a spare
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/16—Error detection or correction of the data by redundancy in hardware
    • G06F11/20—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements
    • G06F11/202—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements where processing functionality is redundant
    • G06F11/2038—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements where processing functionality is redundant with a single idle spare processing component
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/30—Monitoring
    • G06F11/3003—Monitoring arrangements specially adapted to the computing system or computing system component being monitored
    • G06F11/3006—Monitoring arrangements specially adapted to the computing system or computing system component being monitored where the computing system is distributed, e.g. networked systems, clusters, multiprocessor systems
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/30—Monitoring
    • G06F11/3003—Monitoring arrangements specially adapted to the computing system or computing system component being monitored
    • G06F11/301—Monitoring arrangements specially adapted to the computing system or computing system component being monitored where the computing system is a virtual computing platform, e.g. logically partitioned systems
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/30—Monitoring
    • G06F11/34—Recording or statistical evaluation of computer activity, e.g. of down time, of input/output operation ; Recording or statistical evaluation of user activity, e.g. usability assessment
    • G06F11/3409—Recording or statistical evaluation of computer activity, e.g. of down time, of input/output operation ; Recording or statistical evaluation of user activity, e.g. usability assessment for performance assessment
    • 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]
    • G06F9/5005—Allocation of resources, e.g. of the central processing unit [CPU] to service a request
    • G06F9/5027—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resource being a machine, e.g. CPUs, Servers, Terminals
    • 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/45575—Starting, stopping, suspending or resuming virtual machine instances
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2201/00—Indexing scheme relating to error detection, to error correction, and to monitoring
    • G06F2201/815—Virtual
    • 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

Definitions

  • the present invention relates to a service providing system, a resource allocation method, and a resource allocation program.
  • Network virtualization is configured such that a network function that has been realized using dedicated hardware is converted into software and operated on a general-purpose server.
  • HA High Availability
  • VM Virtual Machine
  • VNF virtual network function
  • a virtual network function pair that realizes the same function is prepared in advance, and one of the pair is set on the active side, that is, the active system. And the other side of the pair is the standby side, that is, the standby system.
  • the other virtual network function paired therewith is switched from the standby state to the active state, thereby enabling instantaneous failover.
  • each virtual machine and the above virtual network function on the hardware of each server the actual hardware, that is, the physical resource, especially the virtual function that the virtual machine requires, is required.
  • the physical resource especially the virtual function that the virtual machine requires.
  • each processor (CPU) in the server incorporates a plurality of core circuits, that is, CPU cores for each chip, it is necessary to assign physical CPU cores to virtual CPU cores in units of cores. .
  • Non-Patent Document 2 shows CPU pinning setting in a Linux (registered trademark) kernel virtualization platform (KVM). Specifically, the setting item of “vcpupin” in the virtual machine setting file (XML file) indicates that the physical CPU to be assigned to the virtual CPU can be specified.
  • KVM kernel virtualization platform
  • Non-Patent Document 3 shows HA technology.
  • HA configuration such as an active / standby (ACT / SBY) configuration or an “N + M configuration”.
  • the active / standby configuration is a system in which a plurality of the same systems are prepared and fault tolerance is improved, and several (one in the case of two systems) are set in a standby state, and the process is switched over at the time of failure and takes over the processing.
  • N + M configuration a plurality of spare blades (M) are prepared in a power-off state for a large number of working blades (N) so that spare blades are operated instead of the working blades when an error occurs. Keep it.
  • the active side virtual machine that realizes the virtual network function on the active side and the standby side that realizes the virtual network function on the standby side Each virtual machine is prepared and arranged on separate hardware.
  • the standby-side virtual machine is not operating when a failure has not occurred. Therefore, it is wasteful if hardware resources having large performance are fixedly allocated to the standby-side virtual machine. In other words, by preparing the same hardware resource on the active side and the standby side, the resource utilization efficiency is not improved, and the merit of the virtualization technology is hindered.
  • the present invention has been made in view of the above situation, and can guarantee the performance of the active virtual machine and improve the resource utilization efficiency of the entire system including the standby virtual machine.
  • An object is to provide a service providing system, a resource allocation method, and a resource allocation program.
  • An application function capable of providing a desired service is configured by a first virtual machine and a second virtual machine that are paired with each other, and at least in an initial state, the first virtual machine is in an active state, and the second virtual machine is A service providing system that sets a standby state and provides a service by using the first virtual machine or the second virtual machine in an active state, A plurality of hardware computer resources that can be allocated to the first virtual machine and the second virtual machine;
  • An assigning unit At least before starting the service, the hardware computer resource allocated to the first virtual machine is determined to have a high occupation or execution priority of the first virtual machine, and the hardware computer resource allocated to the second virtual machine is , A resource allocation changing unit that determines that the second virtual machine can be shared with other virtual machines;
  • the resource allocation changing unit allocates sufficient computer resources to satisfy the performance required by the first virtual machine, for example, by allocating dedicated computer resources to the first virtual machine. be able to. Further, the resource allocation changing unit allocates a shared computer resource to the second virtual machine, so that the use efficiency of the computer resource can be improved for the entire system. Moreover, in the initial state, the initial resource allocation unit allocates computer resources according to predetermined initial conditions, so that the operation of the entire system can be stabilized when each virtual machine is started, and the utilization efficiency of computer resources can be increased. become.
  • the initial resource allocation unit selects a predetermined startup core from the plurality of hardware computer resources, and the startup core is in the initial state of the first virtual machine and the second virtual machine. Assigned to The resource allocation changing unit changes the allocation of computer resources for the first virtual machine and the second virtual machine.
  • the operation of the entire system is performed when each virtual machine is started. Can be stabilized. That is, when starting a virtual machine, a computer resource such as a CPU may be subjected to a very large load. However, by starting a new virtual machine with a startup core that is independent of the computer resources allocated to other virtual machines that are already running, it is possible to prevent load fluctuations at startup from affecting other virtual machines. Can do. Further, for the first virtual machine and the second virtual machine, the resource allocation changing unit changes the allocation of computer resources. Thereby, the utilization efficiency of computer resources can be improved for the entire system.
  • the initial resource allocation unit selects a shared core that can be commonly used by a plurality of virtual machines from the plurality of hardware computer resources, and uses the shared virtual core as the first virtual machine in the initial state and the Assigned to the second virtual machine,
  • the resource allocation changing unit changes the allocation of computer resources for the first virtual machine and the second virtual machine.
  • a shared core that can be shared by a plurality of virtual machines is used regardless of whether the first virtual machine or the second virtual machine is activated. Can be increased.
  • the resource allocation changing unit changes the allocation of computer resources. Thereby, the utilization efficiency of computer resources can be improved for the entire system.
  • the initial resource allocation unit selects an occupied core having a high occupation priority or execution priority of a single virtual machine from the plurality of hardware computer resources, and sets the occupied core as the first virtual machine in an initial state. Assigned to a machine and said second virtual machine, The resource allocation changing unit does not change the allocation of computer resources to the first virtual machine and changes the allocation of computer resources to the second virtual machine;
  • the service providing system according to (1) above.
  • the resource assignment changing unit can complete the assignment operation and start providing the service as it is without changing the assignment of computer resources. Therefore, it is possible to shorten the delay time from requesting a service to starting the service. Further, the resource allocation changing unit changes the allocation of computer resources for the second virtual machine, but since the second virtual machine is in a standby state, the time required for the allocation change is a delay time until the service starts. Does not affect.
  • the second virtual machine when a failure occurs in the first virtual machine, the second virtual machine only switches from the standby state to the active state, and the allocation of computer resources to the second virtual machine is changed. There is no need to do.
  • other virtual machines that use the core are excluded from the shared core assigned to the second virtual machine, a computer resource that satisfies the performance required for the active second virtual machine is consequently assigned. Therefore, it is possible to minimize service interruption and delay associated with failover in the event of a failure.
  • An application function capable of providing a desired service is configured by a first virtual machine and a second virtual machine that are paired with each other, and at least in an initial state, the first virtual machine is in an active state, and the second virtual machine is A resource allocation method for controlling a system that provides a service using the first virtual machine or the second virtual machine in an active state, which is set in a standby state, When starting up the first virtual machine and the second virtual machine, any one of a plurality of hardware computer resources prepared in advance according to a predetermined initial condition is assigned to the first virtual machine and the second virtual machine.
  • the hardware computer resource allocated to the first virtual machine is determined to have a high occupation or execution priority of the first virtual machine, and the hardware computer resource allocated to the second virtual machine is The second virtual machine and another virtual machine can be shared. Resource allocation method.
  • this resource allocation method it is possible to allocate sufficient computer resources so that the first virtual machine satisfies the required performance by allocating dedicated computer resources to the first virtual machine. Further, by allocating a shared computer resource to the second virtual machine, it is possible to improve the use efficiency of the computer resource for the entire system. Moreover, in the initial state, computer resources are allocated according to predetermined initial conditions, so that it is possible to stabilize the operation of the entire system at the time of starting each virtual machine and increase the utilization efficiency of computer resources.
  • An application function capable of providing a desired service is configured by a first virtual machine and a second virtual machine that are paired with each other, and at least in an initial state, the first virtual machine is in an active state, and the second virtual machine is A resource allocation program that can be executed by a computer that controls a system that provides a service using the first virtual machine or the second virtual machine in an active state, which is set in a standby state, When starting up the first virtual machine and the second virtual machine, any one of a plurality of hardware computer resources prepared in advance according to a predetermined initial condition is assigned to the first virtual machine and the second virtual machine.
  • An initial resource allocation procedure for allocation At least before starting the service, the hardware computer resource allocated to the first virtual machine is determined to have a high occupation or execution priority of the first virtual machine, and the hardware computer resource allocated to the second virtual machine is , A resource allocation change procedure defined in a state where the second virtual machine can be shared with other virtual machines; A resource allocation program.
  • this resource allocation program When this resource allocation program is executed by a predetermined computer to control the system, for example, an occupied computer resource is allocated to the first virtual machine, so that the first virtual machine satisfies the required performance. Sufficient computer resources can be allocated. Further, by allocating a shared computer resource to the second virtual machine, it is possible to improve the use efficiency of the computer resource for the entire system. Moreover, in the initial state, computer resources are allocated according to predetermined initial conditions, so that it is possible to stabilize the operation of the entire system at the time of starting each virtual machine and increase the utilization efficiency of computer resources.
  • the resource allocation method, and the resource allocation program of the present invention it is possible to guarantee the performance of the active virtual machine and improve the resource utilization efficiency for the entire system including the standby virtual machine. It is possible.
  • FIG. 2 is a block diagram illustrating an example of a system configuration and resource allocation state immediately after a failure occurs.
  • FIG. 3 is a block diagram illustrating an example of a system configuration and resource allocation state during failover.
  • 2 is a block diagram illustrating an example of a system configuration and resource allocation state after failover.
  • FIG. 10 is a flowchart showing an operation example-1 for failover when a failure occurs. It is a flowchart which shows the operation example-2 for the failover at the time of a failure occurrence. It is a schematic diagram which shows the structural example of a redundant structure management table. It is a schematic diagram which shows the structural example of a resource management table.
  • FIGS. 1A and 1B A basic configuration example in a steady state of a system that provides a communication service is shown in FIGS. 1A and 1B, respectively. Note that an apparatus for managing this system is omitted in FIGS. 1A and 1B.
  • FIG. 1B The configuration shown in FIG. 1B is a generally assumed configuration, and FIG. 1A shows a configuration assumed when the configuration of FIG. 1B is improved. In order to facilitate understanding, the configuration shown in FIG. 1B will be described first.
  • a service providing system 100A of a comparative example shown in FIG. 1B includes a plurality of servers 31, 32, 33, and 34.
  • Each of the servers 31 to 34 incorporates physical resources 10-1, 10-2, 10-3, and 10-4, that is, electronic circuit hardware necessary for the operation of the computer.
  • Each physical resource 10-1 to 10-4 has a plurality of independent physical CPU cores 11 built therein.
  • the actual processor (CPU) hardware exists as one or more semiconductor integrated circuit chips mounted on one or more circuit boards.
  • the package of each chip includes a plurality of core circuits that can operate independently from each other, that is, a plurality of physical CPU cores. Therefore, when managing such computer resources, it is necessary to manage them independently for each CPU core.
  • virtual network functions 21 and 22 are arranged on the server 31
  • virtual network functions 23 and 24 are arranged on the server 32
  • virtual network functions 21B and 22B are arranged on the server 33
  • Virtual network functions 23B and 24B are arranged on the server 34.
  • Each of these virtual network functions 21 to 24 and 21B to 24B corresponds to various communication functions required by a carrier network that provides communication services, such as a firewall, a packet switch, and a voice switch.
  • a carrier network that provides communication services
  • NFV network function virtualization technology
  • each of the virtual network functions 21 to 24 and 21B to 24B exists as the virtual network function VNF.
  • each virtual network function VNF is realized by a virtual machine (VM: Virtual Machine) running on hardware of a general-purpose server executing application software incorporated therein.
  • VM Virtual Machine
  • the virtual network functions 21 to 24 shown in FIG. 1B are used as virtual network functions VNF1, VNF2, VNF3, and VNF4 that realize different functions.
  • the service providing system 100A shown in FIG. 1B adopts a redundant configuration such as an HA cluster. That is, a pair of virtual network functions that realize the same function is prepared in advance, and one of the pair is an active side, that is, an active ACT, and the other side is a standby side, that is, a standby SBY.
  • the other virtual network function paired therewith is switched from the standby state to the active state, thereby enabling instantaneous failover.
  • each of the virtual network functions 21 to 24 operates as the active system ACT and the virtual network functions 21B to 24B are in the standby system SBY. Therefore, for example, when a failure occurs in the virtual network function VNF1 of the active ACT, the virtual network function VNF1 of the standby SBY paired with this, that is, the virtual network function 21B is switched from the standby SBY to the active ACT.
  • the same communication service can be provided instead of the virtual network function 21.
  • the virtual network functions 21 to 24 and 21B to 24B are realized on independent virtual machines.
  • the physical CPU core 11 is allocated to each of one or more virtual CPU cores 12 included in each virtual machine.
  • the physical CPU core 11 and the virtual CPU core 12 are individually associated one-to-one, and are associated by a link 13.
  • each of the virtual network functions 21 to 24 and 21B to 24B can use the independent physical CPU core 11 in its own occupied state. That is, since the performance of each physical CPU core 11 does not change, the performance of each virtual machine that uses it as the virtual CPU core 12 does not change without being affected by other virtual machines. Therefore, the performance required for the virtual network functions 21 to 24 can be easily guaranteed.
  • the physical CPU core 11 is assigned to the virtual CPU core 12 in the occupied state, not only for the active system ACT but also for the virtual network functions 21B to 24B of the standby system SBY. Therefore, even when each of the virtual network functions 21B to 24B is switched from the standby system SBY to the active system ACT, the performance required for them can be easily guaranteed.
  • the virtual network functions 21B to 24B of the standby system SBY will not be switched to the active system ACT, so all the physical CPU cores assigned to the virtual network functions 21B to 24B 11 becomes an unused state. Therefore, the utilization efficiency of resources, that is, computer hardware, as the entire system is significantly reduced. However, since it is actually necessary to guarantee the performance when a failure occurs, it is necessary to allocate sufficient resources to the virtual network functions 21B to 24B of the standby system SBY as in the active system ACT. There is.
  • FIG. 1A a configuration like the service providing system 100B shown in FIG. 1A is adopted instead of the configuration of FIG. 1B.
  • the configuration of FIG. 1A will be described below.
  • the service providing system 100B of this embodiment shown in FIG. 1A includes a plurality of servers 31, 32, 33, and 34, as in the configuration of FIG. 1B.
  • Each of the servers 31 to 34 incorporates physical resources 10-1, 10-2, 10-3, and 10-4, that is, electronic circuit hardware necessary for the operation of the computer. Further, each of the physical resources 10-1 to 10-4 incorporates a plurality of independent physical CPU cores 11, respectively.
  • virtual network functions 21 and 22 are arranged on the server 31, virtual network functions 23 and 24 are arranged on the server 32, and virtual network functions 25 and 26 are arranged on the server 33. Yes.
  • virtual network functions 21B, 22B, 23B, 24B, 25B, and 26B are arranged on the server 34.
  • the virtual network functions 21 to 26 and 21B to 26B exist as virtual network functions VNF. Further, the virtual network function 21 of the active system ACT and the virtual network function 21B of the standby system SBY are paired to form a redundant virtual network function VNF1.
  • the virtual network functions 22 and 22B are paired to form a redundant virtual network function VNF2.
  • the virtual network functions 23 and 23B are paired to form a redundant virtual network function VNF3.
  • the virtual network functions 24 and 24B are paired to form a redundant virtual network function VNF4.
  • the virtual network functions 25 and 25B are paired to form a redundant virtual network function VNF5.
  • the virtual network functions 26 and 26B are paired to form a redundant virtual network function VNF6.
  • Each virtual network function VNF1 to VNF6 shown in FIG. 1A is realized by a virtual machine running on the hardware of a general-purpose server executing application software embedded therein.
  • the physical CPU core 11 of the physical resource 10-1 is assigned to each virtual CPU core 12 of the virtual network function 21 on a one-to-one basis. Further, the physical CPU cores 11 of the physical resources 10-1 are assigned to the virtual CPU cores 12 of the virtual network function 22 on a one-to-one basis. That is, the virtual machines of the virtual network functions 21 and 22 can be used in a state where the physical CPU core 11 of the physical resource 10-1 is occupied.
  • the physical CPU core 11 of the physical resource 10-2 is assigned one-to-one to each virtual CPU core 12 of the virtual network function 23, and the physical resource 10-2 is assigned to each virtual CPU core 12 of the virtual network function 24.
  • Physical CPU cores 11 are assigned on a one-to-one basis.
  • the physical CPU core 11 of the physical resource 10-3 is assigned to each virtual CPU core 12 of the virtual network function 25 on a one-to-one basis, and the physical CPU 10 of the physical resource 10-3 is assigned to each virtual CPU core 12 of the virtual network function 26.
  • the physical CPU cores 11 are assigned on a one-to-one basis.
  • the virtual CPU cores 12 of the virtual machines of the virtual network functions 21B, 22B, 23B, 24B, 25B, and 26B are assigned to the common physical CPU core 11 on the physical resource 10-4, and are individually linked by links 13. Associated.
  • the physical CPU core 11 is allocated in a single virtual machine occupation state.
  • the virtual network functions 21B to 26B of the standby system SBY are allocated in a state where the shared physical CPU core 11 is shared by a plurality of virtual machines.
  • the shared physical core includes not only those that are actually shared by a plurality of virtual machines but also those that are idle and can be shared by a plurality of virtual machines.
  • resources can be allocated to the virtual network functions 21B to 26B of the standby system SBY so that a common physical CPU core 11 is shared by a plurality of virtual machines.
  • the number of virtual network functions VNF1 to VNF6 can be increased from 4 to 6 using the same hardware as in FIG. 1B.
  • the number of virtual network functions VNF1 to VNF6 increases or decreases as the situation changes.
  • the active system ACT and the standby system SBY are switched, or a new active system ACT or standby system SBY needs to be prepared. That is, resources cannot be fixedly allocated from the beginning as in the configuration shown in FIG. 1A.
  • the standby system SBY of each of the virtual network functions VNF1 to VNF6 is switched to the active system ACT, there is a possibility that necessary performance cannot be obtained due to the shared resource allocation.
  • FIG. 2 shows a configuration example of a service providing system provided with components necessary for carrying out the present invention. That is, the service providing system shown in FIG. 2 realizes each virtual machine and virtual network function VNF in addition to hardware necessary for realizing the system configuration shown in FIG. Includes management function for assigning.
  • the resource allocation system 40 shown in FIG. 2 allocates each virtual machine from the physical resources 10-1 to 10-4 to be controlled in accordance with a request from the resource request unit 50. Further, the resource allocation system 40 automatically changes the allocation of the physical resources 10-1 to 10-4 according to the change of the situation.
  • the physical resources 10-1 to 10-4 contain a plurality of physical CPU cores 11 that operate independently of each other.
  • the startup core 11B prepared in advance for starting up the virtual machine is also included in the physical resources 10-1 to 10-4.
  • Each physical CPU core 11 and startup core 11B exist as hardware in the servers 31 to 34 shown in FIG. 1A, for example.
  • the virtual machine setting file 14 is included in the physical resources 10-1 to 10-4.
  • the virtual machine setting file 14 is used to hold information indicating the setting state of each constructed virtual machine.
  • the resource allocation system 40 allocates physical resources to each virtual machine, the result is reflected in the contents of the virtual machine setting file 14.
  • the resource request accepting unit 41 accepts a request from the resource requesting unit 50 and starts the operation of the corresponding virtual machine management and physical resource allocation.
  • the VM management unit 42 includes a VM information acquisition unit 42a and a resource operation instruction unit 42b.
  • the VM information acquisition unit 42a of the VM management unit 42 acquires information on the operating state of each virtual machine (VM) of the active system ACT and the standby system SBY.
  • the resource operation instruction unit 42 b issues a CPU pinning setting instruction to the resource payout control unit 43. That is, for example, the VM management unit 42 issues an instruction for fixedly assigning each physical CPU core 11 to each virtual CPU core 12 in a predetermined state as shown in FIG. 1A or the state shown in FIG. 1B. Comes out.
  • the resource payout control unit 43 includes a resource management unit 43a, a resource extraction / selection unit 43b, and a virtual machine control unit 43c.
  • the resource manager 43a manages each available physical resource.
  • the resource extraction / selection unit 43b extracts and selects physical resources that can be allocated.
  • the resource payout control unit 43 performs resource payout control based on the payout request from the resource request unit 50 and the CPU pinning setting instruction from the VM management unit 42. Further, the resource payout control unit 43 performs control such as activation and termination of each virtual machine.
  • the monitoring function unit 44 includes a VM monitoring function unit 44a and a resource monitoring function unit 44b.
  • the monitoring function unit 44 monitors each virtual machine and physical resource. For example, operation information called a heartbeat is periodically transmitted and received between the active ACT virtual machine and the standby SBY virtual machine. By confirming this operation information by the VM monitoring function unit 44a, it is possible to identify whether each virtual machine is operating normally.
  • the resource monitoring function unit 44b monitors the allocation state of each physical CPU core 11 and 11B in the physical resources 10-1 to 10-4, the presence / absence of a failure, and the like.
  • the storage unit 45 includes a resource information repository 45a and a virtual machine image repository 45b.
  • the storage unit 45 is a database for centrally managing the resource usage status of the physical resources 10-1 to 10-4 and each virtual machine image.
  • 3A and 3B show examples of assignment states of virtual cores and physical cores constituting each virtual machine.
  • FIG. 3A shows the assignment state when the virtual machine is activated
  • FIG. 3B shows the state after the assignment is changed.
  • the resource payout control unit 43 functions as an initial resource allocation unit that selects a predetermined activation core from a plurality of hardware computer resources.
  • the resource allocation changing unit further functions as a resource allocation changing unit that changes the allocation of computer resources to the active ACT virtual machine and the standby SBY virtual machine.
  • the startup core 11B prepared in advance among the physical CPU cores 11 on the physical resources 10-1 to 10-4 is allocated to the virtual network functions 20 and 20B. . That is, resources are allocated so that all virtual CPU cores 12 of the active network ACT virtual network function 20 and the standby network SBY virtual network function 20B performing the same function share only the common startup core 11B. Therefore, the activation core 11B and the virtual CPU cores 12 of the virtual network functions 20 and 20B are associated with each other by the link 13.
  • a plurality of occupied cores 11-X on the physical resources 10-1 to 10-4 are assigned to the virtual CPU core 12 of the virtual network function 20, and these are associated with each other through the link 13. It has been.
  • a plurality of shared cores 11 -Y on the physical resources 10-1 to 10-4 are assigned to the virtual CPU core 12 of the virtual network function 20 B, and these are associated with each other by a link 13.
  • the occupied core 11-X is conditioned by the CPU pinning method so that the allocated physical CPU core 11 and virtual CPU core 12 can be used only in a one-to-one state. Therefore, the occupied core 11 -X that has already been assigned to one virtual CPU core 12 cannot be assigned to another virtual CPU core 12.
  • the shared core 11-Y is conditioned so that the virtual CPU cores 12 of a plurality of virtual machines can be shared. Therefore, when performing resource allocation, the shared core 11-Y that has already been allocated to another virtual CPU core 12 can be allocated to another virtual CPU core 12 at the same time.
  • the dedicated cores 11-X and the shared cores 11-Y do not need to be fixedly assigned in advance. That is, by performing conditioning on each physical CPU core 11 according to the situation, the occupied core 11-X and the shared core 11-Y can be secured as necessary. For example, there is an empty physical CPU core 11 that is neither the occupied core 11-X nor the shared core 11-Y, and the occupied machine 11-X and the shared core 11-Y can be formed by placing a virtual machine there. Good. It is also possible to perform resource allocation similar to that of the occupied core 11-X using a method other than CPU pinning.
  • the execution priority of each physical CPU core 11 is adjusted to be different between the active system ACT and the standby system SBY, the performance equivalent to that of the occupied core 11-X and the shared core 11-Y can be obtained.
  • the resource which it has is realizable. Specifically, in the environment of a kernel virtualization infrastructure (KVM), this can be realized by adjusting the value of “share” under the ⁇ cputune> item in the virtual machine setting file, that is, the XML file.
  • KVM kernel virtualization infrastructure
  • the configuration shown in FIG. 3B is equivalent to the configuration shown in FIG. 1A.
  • the virtual machine of the virtual network function 20 of the active ACT can occupy the occupied core 11-X assigned to the virtual CPU core 12, so that it is sufficient to guarantee the required performance. Secure resources.
  • the shared core 11-Y assigned to the virtual CPU core 12 of the virtual machine of the virtual network function 20B of the standby system SBY can be simultaneously assigned to other virtual machines and shared, the use efficiency of physical resources can be improved. Can be raised.
  • FIG. 4 shows an operation example for realizing resource allocation as shown in FIGS. 3A and 3B. That is, when the resource allocation system 40 shown in FIG. 2 performs an operation according to the procedure shown in FIG. 4, resources are assigned as shown in FIG. 3A, and further, resources are assigned as shown in FIG. 3B. Can be assigned. The operation shown in FIG. 4 will be described below.
  • the resource request reception unit 41 in the resource allocation system 40 receives the resource allocation request from the resource request unit 50 in step S11 and gives an instruction to the VM management unit 42 and the resource payout control unit 43.
  • the resource payout control unit 43 extracts resources that can be allocated to the current resource allocation request from the physical resources 10-1 to 10-4 in step S12. Further, the resource payout control unit 43 selects a more appropriate resource from the assignable resources in step S13. For example, when the occurrence of a failure is considered, it is desirable that the active system ACT and the standby system SBY are mounted on different hardware. Therefore, for example, when the physical CPU core 11 assigned to the virtual CPU core 12 of the active system ACT is selected on the server 31, the physical CPU core 11 assigned to the virtual CPU core 12 of the standby system SBY is on another server 32 to 34, etc. Select from. In this embodiment, the activation core 11B is always selected when each virtual machine is activated.
  • the resource payout control unit 43 updates the management table in step S14 to reflect the contents of steps S11 to S13.
  • This management table includes, for example, a redundant configuration management table TB1 and a resource management table TB2, which will be described later.
  • the VM management unit 42 starts a new virtual machine for each of the active system ACT and the standby system SBY in step S15 according to the contents of the management table.
  • the startup core 11B is assigned to the virtual CPU core 12 of each virtual machine to be started on the management table. Therefore, for example, in the resource allocation state as shown in FIG. 3A, the virtual machines of the virtual network functions 20 and 20B are started in step S15.
  • the VM information acquisition unit 42a of the VM management unit 42 confirms the activation state of each virtual machine activated in step S15 in step S16. That is, a virtual machine activated as the active system ACT is distinguished from a virtual machine activated as the standby system SBY.
  • the resource operation instruction unit 42b gives an instruction to the resource payout control unit 43 so as to change the resource allocation for each virtual machine reflecting the result.
  • the resource payout control unit 43 extracts resources that can be allocated to the corresponding virtual machine from the physical resources 10-1 to 10-4 in step S17 in accordance with the instruction from the resource operation instruction unit 42b.
  • the resource payout control unit 43 selects a more appropriate resource from the assignable resources in step S18. For example, when the occurrence of a failure is considered, it is desirable that the active system ACT and the standby system SBY are mounted on different hardware. Therefore, for example, when the physical CPU core 11 assigned to the virtual CPU core 12 of the active system ACT is selected on the server 31, the physical CPU core 11 assigned to the virtual CPU core 12 of the standby system SBY is on another server 32 to 34, etc. Select from.
  • the occupancy core 11-X is assigned to the virtual CPU core 12 of the active system ACT
  • the shared core 11-Y is assigned to the virtual CPU core 12 of the standby system SBY.
  • the occupied core 11-X is allocated, the occupied core 11-X and the virtual CPU core 12 are associated with each other on a one-to-one basis using, for example, a CPU pinning technique. For example, after actually allocating resources of the physical CPU core 11, the conditioning may be changed so that it functions as the occupied core 11-X or the shared core 11-Y.
  • the resource payout control unit 43 updates the management table in step S19 to reflect the contents of steps S15 to S18. Further, according to the contents of the management table updated in S19, the VM management unit 42 updates the description contents of the corresponding virtual machine in the virtual machine setting file 14 in step S20. Furthermore, according to the instruction of the VM management unit 42, the virtual machine control unit 43c in the resource payout control unit 43 restarts the corresponding virtual machine (VM) in step S21.
  • VM virtual machine
  • the contents of the virtual machine setting file 14 can be edited by using the “virsh edit” command.
  • the resource request reception unit 41 in the resource allocation system 40 notifies the resource request unit 50 of a resource payout response to the resource allocation request received in step S11 in step S22.
  • the resource allocation system 40 can be controlled to configure the service providing system in the resource allocation state as shown in FIG. 3B via the resource allocation state as shown in FIG. 3A.
  • FIGS. 5A and 5B Examples of assignment states of virtual cores and physical cores constituting each virtual machine are shown in FIGS. 5A and 5B.
  • FIG. 5A shows the assignment state when the virtual machine is activated
  • FIG. 5B shows the state after the assignment change.
  • the resource payout control unit 43 functions as an initial resource allocation unit that selects a shared core that can be commonly used by a plurality of virtual machines from among hardware computer resources.
  • the resource allocation changing unit further functions as a resource allocation changing unit that changes the allocation of computer resources to the active ACT virtual machine and the standby SBY virtual machine.
  • each shared core 11 -Y is simultaneously associated with a plurality of virtual CPU cores 12 by links 13.
  • the same shared core 11-Y may be simultaneously assigned to the virtual CPU core 12 of the active system ACT and the virtual CPU core 12 of the standby system SBY performing the same function, or different shared cores 11-Y may be assigned to the active system ACT and It may be assigned to the virtual CPU core 12 of the standby system SBY.
  • a plurality of occupied cores 11-X on the physical resources 10-1 to 10-4 are allocated to the virtual CPU core 12 of the virtual network function 20, and these are associated with each other through the link 13. It has been.
  • a plurality of shared cores 11 -Y on the physical resources 10-1 to 10-4 are assigned to the virtual CPU core 12 of the virtual network function 20 B, and these are associated with each other by a link 13.
  • the configuration shown in FIG. 5B is the same as the configuration shown in FIG. 1A. That is, in the configuration of FIG. 5B, since the virtual machine of the virtual network function 20 of the active ACT can occupy the occupied core 11-X assigned to the virtual CPU core 12, it is sufficient to guarantee the required performance. Secure resources. In addition, since the shared core 11-Y assigned to the virtual CPU core 12 of the virtual machine of the virtual network function 20B of the standby system SBY can be simultaneously assigned to other virtual machines and shared, the use efficiency of physical resources can be improved. Can be raised.
  • FIG. 6 shows an operation example for realizing resource allocation as shown in FIGS. 5A and 5B. That is, when the resource allocation system 40 shown in FIG. 2 performs an operation according to the procedure shown in FIG. 6, resources are allocated as shown in FIG. 5A, and further, the resources as shown in FIG. Can be assigned. The operation shown in FIG. 6 will be described below.
  • the resource request receiving unit 41 in the resource allocation system 40 receives the resource allocation request from the resource request unit 50 in step S31, and gives an instruction to the VM management unit 42 and the resource payout control unit 43.
  • the resource payout control unit 43 extracts resources that can be allocated to the current resource allocation request from the physical resources 10-1 to 10-4 in step S32. Further, the resource payout control unit 43 selects a more appropriate resource from the assignable resources in step S33. For example, when the occurrence of a failure is considered, it is desirable that the active system ACT and the standby system SBY are mounted on different hardware. Therefore, for example, when the physical CPU core 11 assigned to the virtual CPU core 12 of the active system ACT is selected on the server 31, the physical CPU core 11 assigned to the virtual CPU core 12 of the standby system SBY is on another server 32 to 34, etc. Select from. When performing the operation of FIG. 6, the shared core 11-Y is always selected for both the active system ACT and the standby system SBY when each virtual machine is activated.
  • the resource payout control unit 43 updates the management table in step S34 to reflect the contents of steps S31 to S33.
  • This management table includes, for example, a redundant configuration management table TB1 and a resource management table TB2, which will be described later.
  • the VM management unit 42 starts a new virtual machine for each of the active system ACT and the standby system SBY in step S35 according to the contents of the management table.
  • the shared CPU 11-Y is assigned to the virtual CPU core 12 of each virtual machine started here on the management table. Therefore, for example, the virtual machines of the virtual network functions 20 and 20B are activated in step S35 in the resource allocation state as shown in FIG. 5A.
  • the VM information acquisition unit 42a of the VM management unit 42 confirms the activation state of each virtual machine activated in step S35 in step S36. That is, a virtual machine activated as the active system ACT is distinguished from a virtual machine activated as the standby system SBY.
  • the resource operation instruction unit 42b gives an instruction to the resource payout control unit 43 so as to change the resource allocation for each virtual machine reflecting the result.
  • the resource payout control unit 43 extracts resources that can be allocated to the corresponding virtual machine from the physical resources 10-1 to 10-4 in step S37 in accordance with the instruction from the resource operation instruction unit 42b.
  • the resource payout control unit 43 selects a more appropriate resource from the assignable resources in step S38. For example, when the occurrence of a failure is considered, it is desirable that the active system ACT and the standby system SBY are mounted on different hardware. Therefore, for example, when the physical CPU core 11 assigned to the virtual CPU core 12 of the active system ACT is selected on the server 31, the physical CPU core 11 assigned to the virtual CPU core 12 of the standby system SBY is on another server 32 to 34, etc. Select from.
  • the occupied core 11-X is allocated to the virtual CPU core 12 of the active system ACT, and the shared core 11-Y is allocated to the virtual CPU core 12 of the standby system SBY.
  • Select to assign When the occupied core 11-X is allocated, the occupied core 11-X and the virtual CPU core 12 are associated with each other on a one-to-one basis using, for example, a CPU pinning technique. For example, after actually allocating resources of the physical CPU core 11, the conditioning may be changed so that it functions as the occupied core 11-X or the shared core 11-Y.
  • the resource payout control unit 43 updates the management table in step S39 to reflect the contents of steps S35 to S38.
  • the VM management unit 42 updates the description contents of the corresponding virtual machine in the virtual machine setting file 14 in step S40. Furthermore, according to the instruction of the VM management unit 42, the virtual machine control unit 43c in the resource payout control unit 43 restarts the corresponding virtual machine (VM) in step S41.
  • the resource request reception unit 41 in the resource allocation system 40 notifies the resource request unit 50 of a resource payout response to the resource allocation request received in step S31 in step S42.
  • the resource allocation system 40 can be controlled to configure the service providing system in the resource allocation state shown in FIG. 5B via the resource allocation state shown in FIG. 5A.
  • FIG. 7 shows an example of the allocation state between the virtual cores and physical cores constituting each virtual machine.
  • FIG. 7 shows the allocation state when the virtual machine is activated.
  • the state after the assignment change is the same as the content of FIG. 5B already described.
  • the resource payout control unit 43 selects an occupied core having a high occupation priority or execution priority of a single virtual machine from a plurality of hardware computer resources, and makes this occupied core an initial virtual machine. Functions as an initial resource allocation unit to be allocated. Further, the resource payout control unit 43 functions as a resource allocation changing unit that completes the allocation operation without changing the computer resource allocation for the active ACT virtual machine.
  • the resource payout control unit 43 functions as a resource allocation change unit that changes the allocation of computer resources for the standby SBY virtual machine.
  • the number of virtual network functions VNF1 to VNF6 shown in FIG. In the actual system, for example, the number of virtual network functions VNF1 to VNF6 shown in FIG.
  • the active system ACT and the standby system SBY are switched, or a new active system ACT or standby system SBY needs to be prepared. Therefore, resources cannot be fixedly assigned from the beginning as in the configuration shown in FIG. If the configuration shown in FIG. 7 is maintained, the standby SBY virtual machine also occupies the resources of the occupied core 11-X in the same manner as the active ACT, and the use efficiency of physical resources cannot be increased.
  • FIG. 8 shows an operation example for realizing resource allocation as shown in FIG. 7 and FIG. 5B. That is, when the resource allocation system 40 shown in FIG. 2 performs an operation according to the procedure shown in FIG. 8, resources are allocated as shown in FIG. 7, and further, for example, as shown in FIG. 5B. You can change the resource allocation. The operation shown in FIG. 8 will be described below.
  • the resource request receiving unit 41 in the resource allocation system 40 receives the resource allocation request from the resource request unit 50 in step S51, and gives an instruction to the VM management unit 42 and the resource payout control unit 43.
  • the resource payout control unit 43 extracts resources that can be allocated to the current resource allocation request from the physical resources 10-1 to 10-4 in step S52. Further, the resource payout control unit 43 selects a more appropriate resource from the assignable resources in step S53. For example, when the occurrence of a failure is considered, it is desirable that the active system ACT and the standby system SBY are mounted on different hardware. Therefore, for example, when the physical CPU core 11 assigned to the virtual CPU core 12 of the active system ACT is selected on the server 31, the physical CPU core 11 assigned to the virtual CPU core 12 of the standby system SBY is on another server 32 to 34, etc. Select from. Further, when the operation of FIG. 8 is performed, the occupied core 11-X is always selected for both the active system ACT and the standby system SBY when each virtual machine is activated.
  • the resource payout control unit 43 updates the management table in step S54 so as to reflect the contents of steps S51 to S53.
  • This management table includes, for example, a redundant configuration management table TB1 and a resource management table TB2, which will be described later.
  • the VM management unit 42 starts a new virtual machine for each of the active system ACT and the standby system SBY in step S55 according to the contents of the management table.
  • the dedicated CPU 11-X is assigned to the virtual CPU core 12 of each virtual machine to be started on the management table. Therefore, for example, in the resource allocation state as shown in FIG. 7, the virtual machines of the virtual network functions 20 and 20B are started in step S55.
  • the VM information acquisition unit 42a of the VM management unit 42 confirms the activation state of each virtual machine activated in step S55 in step S56. That is, a virtual machine activated as the active system ACT is distinguished from a virtual machine activated as the standby system SBY.
  • the resource operation instruction unit 42b gives an instruction to the resource payout control unit 43 in step S56 so as to change the resource allocation for each virtual machine reflecting the result.
  • the resource payout control unit 43 extracts resources that can be allocated to the corresponding virtual machine from the physical resources 10-1 to 10-4 in step S57 in accordance with the instruction from the resource operation instruction unit 42b.
  • the resource payout control unit 43 selects a more appropriate resource from the assignable resources in step S58. For example, when the occurrence of a failure is considered, it is desirable that the active system ACT and the standby system SBY are mounted on different hardware. Therefore, for example, when the physical CPU core 11 assigned to the virtual CPU core 12 of the active system ACT is selected on the server 31, the physical CPU core 11 assigned to the virtual CPU core 12 of the standby system SBY is on another server 32 to 34, etc. Select from.
  • the occupied core 11-X is allocated to the virtual CPU core 12 of the active system ACT, and the shared core 11-Y is allocated to the virtual CPU core 12 of the standby system SBY.
  • Select to assign When the occupied core 11-X is allocated, the occupied core 11-X and the virtual CPU core 12 are associated with each other on a one-to-one basis using, for example, a CPU pinning technique. For example, after actually allocating resources of the physical CPU core 11, the conditioning may be changed so that it functions as the occupied core 11-X or the shared core 11-Y.
  • the occupied core 11-X is allocated to the virtual machine of the active ACT in the state where the virtual machine is first activated, for example, as shown in FIG. 7, it is not necessary to change this.
  • the selection for changing the resource allocation is performed in step S58 only for the standby system SBY to which the occupied core 11-X is allocated in the starting state.
  • the resource payout control unit 43 updates the management table in step S59 so that the contents of steps S55 to S58 are reflected.
  • the VM management unit 42 updates the description contents of the corresponding virtual machine in the virtual machine setting file 14 in step S60. Furthermore, according to the instruction of the VM management unit 42, the virtual machine control unit 43c in the resource payout control unit 43 restarts the corresponding virtual machine (VM) in step S61.
  • the resource request reception unit 41 in the resource allocation system 40 notifies the resource request unit 50 of a resource payout response to the resource allocation request received in step S51 in step S62.
  • the resource allocation system 40 can control to configure the service providing system in the resource allocation state as shown in FIG. 5B via the resource allocation state as shown in FIG.
  • the content of the virtual machine setting file 14A shown in FIG. 9A is a description example for realizing resource allocation as shown in FIG. 3A, for example. That is, in the description example of FIG. 9A, the virtual CPU core 12 of each virtual machine indicated by “vcpu” of No. 1, No. 1, and No. 2 in the ⁇ cputune> item in the virtual machine setting file 14A is as follows. This means that the 0th physical CPU core 11 prepared as the activation core 11B is allocated.
  • the content of the virtual machine setting file 14B shown in FIG. 9B is a description example for realizing resource allocation as shown in FIG. 5A, for example. That is, in the description example of FIG. 9B, for the virtual CPU core 12 of each virtual machine indicated by “vcpu” of No. 0, No. 1, and No. 2 in the ⁇ cputune> item in the virtual machine setting file 14B, This means that the seventh physical CPU core 11 corresponding to the shared core 11-Y is allocated.
  • the contents of the virtual machine setting file 14C shown in FIG. 9C are a description example for realizing resource allocation as shown in FIG. 7, for example. That is, in the description example of FIG. 9C, for the virtual CPU core 12 of each virtual machine indicated by “vcpu” of No. 1, No. 1, and No. 2 in the ⁇ cputune> item in the virtual machine setting file 14C, This means that the first, second and third physical CPU cores 11 corresponding to the occupied core 11-X are allocated.
  • FIGS. 10A and 10B description examples of the contents of the virtual machine setting file 14 after the assignment change are shown in FIGS. 10A and 10B, respectively.
  • the description example of the virtual machine setting file 14D illustrated in FIG. 10A represents the contents of resource allocation to the virtual machine of the active ACT after the resource allocation is changed, for example, as in the allocation state illustrated in FIG. 3B.
  • the virtual CPU cores 12 of the virtual machines indicated by “vcpu” of No. 0, No. 1, and No. 2 are This means that the first, second, and third independent physical CPU cores 11 corresponding to the occupied cores 11-X are individually assigned.
  • the description example of the virtual machine setting file 14E illustrated in FIG. 10B represents the contents of resource allocation for the virtual machine of the standby system SBY after the resource allocation is changed, for example, as in the allocation state illustrated in FIG. 3B.
  • the virtual CPU cores 12 of the virtual machines indicated by “vcpu” of No. 0, No. 1, and No. 2 are This means that the seventh, eighth, and ninth physical CPU cores 11 corresponding to the shared core 11-Y are allocated.
  • the same shared core 11-Y may be assigned to a plurality or all of the virtual CPU cores 12 of the standby system SBY. That is, a virtual resource exceeding the capacity of the actual physical resource can be allocated to the virtual machine, that is, overcommitment can be performed.
  • FIG. 11 shows an operation example when resources are allocated to each virtual machine according to the resource management table. That is, FIG. 11 shows details of processing corresponding to steps S16 to S18 in FIG. 4, steps S36 to S38 in FIG. 6, and steps S56 to S58 in FIG. Therefore, when the resource allocation system 40 executes the operation shown in FIG. 11, the resource allocation can be changed to a desirable state as shown in FIGS. 3B and 5B, for example. The operation of FIG. 11 will be described below.
  • the resource payout control unit 43 creates a resource selection table in step S71, initializes the variable X to 1 in step S72, and then repeatedly executes the processing after step S73 in a loop.
  • the resource payout control unit 43 selects a resource on the line specified by the value of the variable X from the resource management table TB2 as shown in FIG. 16 in step S73.
  • the resource management table TB2 will be described later.
  • the resource payout control unit 43 repeatedly executes the processes between steps S74 to S84 as many times as the number of virtual CPU cores 12 to be processed.
  • step S75 the resource payout control unit 43 identifies whether the allocation destination virtual machine is a virtual machine “Active VM” of the active ACT. If the allocation destination is the active system ACT, the process proceeds to step S76, and if the allocation destination is the standby system SBY, the process proceeds to step S80.
  • step S76 the resource payout control unit 43 identifies whether or not the physical CPU core 11 to be allocated is in the “occupied” state. If it is in the “occupied” state, the process proceeds to step S77. . In step S77, the resource payout control unit 43 identifies whether or not the result of subtracting the “usage rate” from the “multiplex rate” is equal to or greater than the “request usage rate”. If this condition is satisfied, the process proceeds to step S78. If not, the process proceeds to step S79.
  • step S78 the resource payout control unit 43 writes information indicating “allocation possible” at the position of the corresponding row in the resource selection table created in step S71.
  • step S79 the resource payout control unit 43 writes information indicating “unallocated” at the position of the corresponding row in the resource selection table.
  • step S80 the resource payout control unit 43 identifies whether or not the physical CPU core 11 to be allocated is in the “shared” state. If it is in the “shared” state, the process proceeds to step S81, and if not in the “shared” state, the process proceeds to step S83. .
  • step S81 the resource payout control unit 43 identifies whether or not the result obtained by subtracting the “usage rate” from the “multiplex rate” is equal to or greater than the “request usage rate”. If this condition is satisfied, the process proceeds to step S82. If not, the process proceeds to step S83.
  • step S82 the resource payout control unit 43 writes information indicating “allocation possible” at the position of the corresponding row of the resource selection table.
  • step S83 the resource payout control unit 43 writes information indicating “allocation impossible” at the position of the corresponding row in the resource selection table.
  • step S85 the resource payout control unit 43 identifies whether or not the processing has been completed up to the last row of the resource management table TB2, and if completed, the process proceeds to step S87. If not completed, the process proceeds to step S86, the value of the variable X is incremented, and then the process returns to step S73 to repeat the above processing.
  • step S87 the resource payout control unit 43 identifies whether or not the result of the above process satisfies the hardware (HW) condition. If the condition is satisfied, the process of FIG. If the hardware condition is not satisfied, the resource payout control unit 43 proceeds to step S88, and writes “unassignable” information in the resource selection table.
  • satisfying the hardware condition means that the HW allocation condition such as the “anti-affinity” attribute is satisfied.
  • the anti-affinity attribute specifies that a particular virtual machine must always be run on a different physical server.
  • FIGS. 12A to 12C Examples of system configurations and resource allocation states are shown in FIGS. 12A to 12C.
  • 12A shows a state immediately after a failure has occurred in the virtual network function 21 of the active ACT
  • FIG. 12B shows a state in the middle of failover
  • FIG. 12C shows a state after failover.
  • a failure 19 may occur in the virtual network function 21 of the active ACT as shown in FIG. 12A.
  • the state shown in FIG. 12C is obtained after the state of FIG. 12B. That is, in the configuration of FIG. 12B, a new active network ACT virtual network function 21C is prepared in place of the virtual network function 21 whose function is stopped. Further, since the virtual network function 21C is the active ACT, the occupied core 11-X is assigned to the virtual CPU core 12 as a hardware resource. In the state of FIG. 12B, another virtual network function 22B still shares the same occupied core 11-X. Therefore, for example, as shown in FIG. 12C, the resource allocation is changed so that the virtual network function 22B uses another shared core 11-Y.
  • Sf1 Detection operation of the failure 19
  • the monitoring function unit 44 detects the occurrence of the failure or the application software of the corresponding virtual network function VNF1 detects the occurrence of the failure and notifies the VM management unit 42 of the detection.
  • Sf2 Failover operation
  • the virtual network function VNF1 of the standby system SBY is switched from the standby system SBY to the active ACT virtual machine by the function of the application software. This operation may occur before the failure detection operation in step Sf1 described above.
  • Sf3 Virtual machine activation state confirmation and CPU resource reassignment operation_Sf31:
  • the VM management unit 42 designates the other virtual machine that forms a redundant configuration pair with the virtual machine in which the failure 19 has occurred in the redundant configuration management table TB1 (FIG. 15).
  • the activation status is identified and the CPU resource sharing status is confirmed by the resource management table TB2.
  • the VM management unit 42 can confirm that a failure has occurred in the active ACT as shown in FIG. 12A. For example, in the case of FIG.
  • __Sf31A The virtual machine of the other standby system SBY sharing the shared core 11-Y allocated to the virtual machine of the virtual network function 21B switched to the active system ACT is evicted from the allocation destination of the shared core 11-Y. Exclude. Thereby, the virtual machine of the virtual network function 21B can be used as it is with the corresponding shared core 11-Y as the new occupied core 11-X.
  • __Sf31B The CPU resource is newly allocated, and the contents of the definition file of the corresponding virtual machine are updated so that the physical CPU core 11 and the virtual CPU core 12 are fixedly occupied by CPU pinning in a one-to-one relationship.
  • _Sf32 When step Sf31A is executed, it is necessary to return the other virtual machine evicted from the shared core 11-Y to a predetermined usable state. Therefore, one of the following steps Sf32A and Sf32B is executed.
  • __Sf32A Suspends and shuts off the corresponding other virtual machine, newly pays out CPU resources for the standby SBY virtual machine, and updates the contents of the definition file of this virtual machine.
  • __Sf32B After deleting the corresponding other virtual machine, the corresponding standby SBY virtual machine is activated again.
  • Sf4 Activation and incorporation operation of a new standby SBY virtual machine
  • the VM management unit 42 instructs the resource payout control unit 43 to activate a new standby SBY virtual machine.
  • step Sf3 in that case, the following processing is performed.
  • the VM management unit 42 identifies the other virtual machine that forms a redundant configuration pair with the virtual machine in which the failure 19 has occurred, from the redundant configuration management table TB1, confirms its activation state, and further determines the CPU resource sharing status as a resource. Confirm with the management table TB2. For example, when the “status” is “occupied” in the resource management table TB2, the VM management unit 42 can confirm that a failure has occurred in the standby system SBY. In that case, resource reallocation is not performed.
  • FIG. 13 shows an operation example-1 for failover when a failure occurs. That is, FIG. 13 shows an operation example when the resource allocation system 40 executes the above step Sf31A. The operation of FIG. 13 will be described below.
  • step S101 the monitoring function unit 44 detects the occurrence of the failure 19.
  • the failure 19 can be detected by monitoring the heartbeat operation information notified to each other between the active ACT and the standby SBY during normal operation.
  • step S102 the VM management unit 42 refers to the redundant configuration management table TB1 and extracts information that identifies the normal virtual machine that is paired with the redundant configuration of the virtual machine in which the failure 19 has occurred. Further, the VM management unit 42 confirms the normal virtual machine activation state extracted in step S102 in steps S103 and S104. That is, it is identified in step S104 whether or not the operating state of the corresponding normal virtual machine is an active state (Active VM).
  • Active VM active state
  • step S104 If the operating state of the corresponding normal virtual machine is not active, the process proceeds from step S104 to S105, waits for a predetermined time (X seconds) sleep, and waits until it becomes active.
  • X seconds a predetermined time
  • the resource payout control unit 43 refers to the contents of the resource management table TB2 in step S106, and whether the “status” of the corresponding resource is “shared”. Identify whether or not. That is, it is determined whether or not the physical CPU core 11 assigned to the virtual CPU core 12 of the corresponding virtual machine is the shared core 11-Y. If the “status” of the corresponding resource is “shared”, the process proceeds to step S107, and if not “shared”, the process proceeds to step S113.
  • step S107 the VM management unit 42 identifies other virtual machines sharing the same physical CPU core 11 based on the “allocation destination” information on the resource management table TB2, and suspends and shuts off the other virtual machines. To do. As a result, another virtual machine can be expelled from the assignment destination of the shared core 11-Y assigned to the virtual machine operating as the new active ACT by failover, and this shared core 11-Y can be expelled. Can be used as
  • the resource payout control unit 43 executes steps S108 to S112 in order to return the other virtual machine evicted from the allocation destination of the shared core 11-Y to the normal usable state by the process of step S107.
  • step S108 the resource extraction / selection unit 43b extracts the physical CPU core 11 that can be assigned to the corresponding virtual machine as a resource.
  • step S109 the resource extraction / selection unit 43b selects an appropriate physical CPU core 11 to be assigned to the corresponding virtual machine.
  • the resource payout control unit 43 updates the contents of the redundant configuration management table TB1 and the resource management table TB2 in step S110 so as to reflect the selection result in step S109.
  • the resource payout control unit 43 updates the contents of the virtual machine setting file 14.
  • step S112 the resource payout control unit 43 restarts the corresponding virtual machine so that the corresponding virtual machine operates in a state reflecting the contents of the virtual machine setting file 14 updated in step S111.
  • the virtual machine in which the failure 19 has occurred is the standby system SBY
  • the virtual machine of the active system ACT paired with it can be used as it is, so that failover is not necessary.
  • the standby SBY virtual machine in which the failure 19 has occurred it is necessary to prepare for the subsequent occurrence of the failure.
  • step S113 the VM management unit 42 gives an instruction for starting a new virtual machine (Standby VM) operable as the standby system SBY to the resource payout control unit 43.
  • step S114 the resource payout control unit 43 executes a predetermined activation sequence for the new virtual machine that can operate as the standby system SBY according to the instruction from the VM management unit 42. For example, the operation shown in any of FIG. 4, FIG. 6, and FIG. 8 is executed.
  • FIG. 14 shows an operation example-2 for failover when a failure occurs. That is, FIG. 14 shows an operation example when the resource allocation system 40 executes the above step Sf31B. The operation of FIG. 14 will be described below.
  • the monitoring function unit 44 detects the occurrence of the failure 19.
  • the failure 19 can be detected by monitoring the heartbeat operation information notified to each other between the active ACT and the standby SBY during normal operation.
  • step S122 the VM management unit 42 refers to the redundant configuration management table TB1 and extracts information that identifies the normal virtual machine that is paired with the redundant configuration of the virtual machine in which the failure 19 has occurred. Further, the VM management unit 42 confirms the normal virtual machine activation state extracted in step S122 in steps S123 and S124. That is, it is identified in step S124 whether or not the operating state of the corresponding normal virtual machine is an active state (Active VM).
  • Active VM active state
  • step S124 If the operating state of the corresponding normal virtual machine is not active, the process proceeds from step S124 to S125, waits for a predetermined time (X seconds) sleep, and waits until it becomes active.
  • X seconds a predetermined time
  • the resource payout control unit 43 refers to the contents of the resource management table TB2 in step S126, and determines whether the “status” of the corresponding resource is “shared”. Identify whether or not. That is, it is determined whether or not the physical CPU core 11 assigned to the virtual CPU core 12 of the corresponding virtual machine is the shared core 11-Y. If the “status” of the corresponding resource is “shared”, the process proceeds to step S127, and if not “shared”, the process proceeds to step S131.
  • the resource payout control unit 43 allocates resources for allocating an appropriate occupied core 11-X instead of the shared core 11-Y to a virtual machine that is operated as a new active ACT by failover. Run.
  • step S127 the resource extraction / selection unit 43b extracts the physical CPU core 11 that can be assigned to the corresponding virtual machine as a resource.
  • step S128 the resource extraction / selection unit 43b selects the occupied core 11-X as an appropriate physical CPU core 11 to be assigned to the corresponding virtual machine.
  • the resource payout control unit 43 updates the contents of the redundant configuration management table TB1 and the resource management table TB2 in step S129 so as to reflect the selection result in step S128. Further, in step S130, the resource payout control unit 43 updates the contents of the virtual machine setting file 14.
  • the virtual machine in which the failure 19 has occurred is the standby system SBY
  • the virtual machine of the active system ACT paired with it can be used as it is, so that failover is not necessary.
  • the standby SBY virtual machine in which the failure 19 has occurred it is necessary to prepare for the subsequent occurrence of the failure.
  • step S131 the VM management unit 42 gives an instruction for starting a new virtual machine (Standby VM) operable as the standby system SBY to the resource payout control unit 43.
  • step S132 the resource payout control unit 43 executes a predetermined activation sequence for a new virtual machine that can operate as the standby SBY in accordance with an instruction from the VM management unit 42. For example, the operation shown in any of FIG. 4, FIG. 6, and FIG. 8 is executed.
  • a configuration example of the redundant configuration management table TB1 is shown in FIG.
  • the redundant configuration management table TB1 is used to specify the other virtual machine that forms a pair of a redundant configuration and a virtual machine in which a failure has occurred when a failure occurs.
  • the redundancy configuration management table TB1 shown in FIG. 15 includes, for each application software (App) of the virtual network function VNF, an application identifier (App ⁇ ⁇ ID), a virtual machine number (VM Number), a virtual machine identifier (VM ID), and It has an area for holding virtual IP address (Virtual IP) information.
  • App application software
  • VNF virtual network function
  • VM Number virtual machine number
  • VM ID virtual machine identifier
  • Virtual IP Virtual IP
  • the redundant configuration management table TB1 of FIG. 15 there is no need for virtual IP address information.
  • the redundant configuration management table TB1 of FIG. 15 by managing the IP addresses of all the virtual machines that belong to the virtual IP address instead of the virtual IP address, it is possible to grasp the other virtual machine that forms a redundant configuration pair.
  • the first virtual machine and 2 from the two pieces of information “# 01” and “# 02” included in the virtual machine identifier item You can see that the second virtual machine is assigned as a redundant pair. That is, in this case, one of the first virtual machine and the second virtual machine is the active system ACT, and the other is the standby system SBY.
  • FIG. 16 shows a configuration example of the resource management table TB2.
  • This resource management table TB2 is used for managing the allocation status of the physical CPU core 11 to the virtual CPU core 12 of each virtual machine.
  • the resource management table TB2 shown in FIG. 16 holds information on each of the hardware identifier (HW Id) indicating each physical resource 10, the core number of the physical CPU core 11, the multiplexing rate, the usage rate, the state, and the allocation destination. Has an area.
  • HW Id hardware identifier
  • the multiplexing rate is an index indicating the computing capability of each physical CPU core 11 based on the performance of the physical CPU core 11 included in a certain physical resource 10.
  • the physical CPU core 11 with the hardware identifier # 0 and the core number 0 is selected as a reference.
  • the usage rate is an index indicating how much of the performance of the physical CPU core 11 indicated by the multiplexing rate is being used.
  • the state indicates whether each physical CPU core 11 is occupied by any virtual machine and whether it is assigned for activation. In the example of FIG. 16, one of the physical CPU cores 11 of each physical resource 10 is selected as a dedicated CPU core for activation.
  • the allocation destination indicates whether each physical CPU core 11 is allocated to any virtual machine.
  • the physical CPU core 11 with the hardware identifier “# 0” and the core number “0” is assigned as the dedicated core for “startup”, that is, the startup core 11B. It has been.
  • Each physical CPU core 11 with the hardware identifier “# 0” and the core number “1-3” is assigned as a core in the “occupied” state, that is, the occupied core 11-X.
  • the physical CPU core 11 having the hardware identifier “# 0” and the core number “2” is assigned to the virtual CPU core 12 (vCPU0) 0 having the virtual machine identifier “# 01”.
  • each physical CPU core 11 having the hardware identifier “# 1” and the core number “1” is assigned as a “shared” state core, that is, a shared core 11-Y.
  • the physical CPU core 11 with the hardware identifier “# 1” and the core number “1” has the virtual CPU core 12 (vCPU0) with the virtual machine identifier “# 02” and the virtual machine identifier They are assigned to the # 0 virtual CPU core 12 (vCPU0) “# 04” in a shared state.
  • the physical CPU core 11 with the hardware identifier “# 1” and the core number “1” has a multiplexing rate of “150%”, so that the physical CPU core 11 with the hardware identifier “# 0” It can be seen that the performance ratio is 1.5 times. Further, for example, the physical CPU core 11 with the hardware identifier “# 1” and the core number “1” has a usage rate of “20%”, and therefore, the remaining 130% of the resources for the performance are further virtualized. You can see that the machine can be assigned.
  • a plurality of virtual machines can share the virtual CPU core 12 of each virtual machine of the virtual network functions 21B to 26B of the standby system SBY as shown in FIG. 1A in the operating state.
  • a physical CPU core 11 can be assigned. Therefore, it is possible to reduce the physical resources allocated to the standby SBY virtual machine that is not normally used, and to increase the resource utilization efficiency of the entire system.
  • FIGS. 3A and 3B since the allocation of physical resources is changed after each virtual machine is activated, each physical resource can be efficiently allocated in response to a change in the situation.
  • each virtual machine is started using the startup core 11B, and then the resource allocation of each virtual machine of the active system ACT and the standby system SBY is changed as shown in FIG. 3B.
  • the system performance can be stabilized.
  • a very large load may be applied when the virtual machine is started, which may affect the operation of other virtual machines that are already operating.
  • the physical CPU core 11 of another virtual machine that is already operating is not affected by this load fluctuation.
  • the resource allocation of each virtual machine of the active system ACT and the standby system SBY is changed as shown in FIG. 5B.
  • the service can be started as it is without changing the resource allocation, so that the delay time associated with the resource allocation change can be reduced.
  • resource allocation is performed so that the shared core 11-Y allocated to the virtual network function 21B of the standby SBY is switched to “occupied”. By changing, it becomes easier to guarantee performance after failover.
  • each function of the resource allocation system 40 shown in FIG. 2 can be realized by dedicated hardware, or can be realized as a program executed by a general-purpose computer that manages the system.

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Software Systems (AREA)
  • Quality & Reliability (AREA)
  • Computing Systems (AREA)
  • Mathematical Physics (AREA)
  • Computer Hardware Design (AREA)
  • Hardware Redundancy (AREA)

Abstract

【課題】現用系の仮想マシンの性能保証を可能にすると共に、待機系の仮想マシンを含むシステム全体についてのリソース利用効率を改善すること。 【解決手段】システムが稼働している状態において、現用系ＡＣＴの仮想マシンの仮想ＣＰＵコア１２に占有の物理ＣＰＵコア１１を割り当て、待機系ＳＢＹの仮想マシンの仮想ＣＰＵコア１２には共有の物理ＣＰＵコア１１を割り当てて物理リソースの利用効率を改善する。各仮想マシンを起動する際には、専用の起動用コア、共有コア、占有コアのいずれかを割り当て、各仮想マシンが起動した後で、リソース割り当てを変更し、共有コア及び占有コアを現用系ＡＣＴ及び待機系ＳＢＹに適切に振り分ける。現用系ＡＣＴの仮想マシンに障害が発生した場合には、ペアの他方の仮想マシンに割り当てられた共有コアの割り当てを占有状態に変更して性能の低下を避ける。

Description

サービス提供システム、資源割り当て方法、及び資源割り当てプログラム
　本発明は、サービス提供システム、資源割り当て方法、及び資源割り当てプログラムに関する。
　通信サービスを提供するキャリア網などにおいては、以前は、必要とされる様々な通信機能、例えば、ファイアウォール、パケット交換機、音声交換機などをそれぞれ独立した専用のネットワーク装置、すなわち個別のハードウェアで実現し、これらのハードウェア装置を接続してネットワークを構成していた。
　一方、近年では仮想化技術を適用したネットワーク機能の仮想化（ＮＦＶ：Network Functions Virtualization）の採用が進展している。ネットワークの仮想化は、従来専用のハードウェアを用いて実現されていたネットワーク機能をソフトウェア化して汎用サーバ上で動作させるように構成する。仮想化技術をキャリア網に適用することで、経済的にスケーラビリティと信頼性を両立させることや、迅速なサービス提供、サービス毎の需要に応じた柔軟なリソース割り当てと、ハードウェアの寿命に縛られないサービス展開が実現できると期待されている。
　また、システムを２４時間、３６５日休みなく稼動させるためには、まずそのシステムの可用性（Availability）を向上させることが重要になる。そこで、ＨＡ（High Availability）クラスタと呼ばれるシステムの構成が採用される。ＨＡクラスタは、サーバマシンを冗長化してシステムダウンタイムを最小化するものである。
　上記のようなネットワーク機能の仮想化を実現するためには、各サーバのハードウェア上に仮想マシン（ＶＭ：Virtual Machine）を構築し、必要とされるそれぞれの通信機能のアプリケーションを、構築された各仮想マシン上で実行されるソフトウェアとして実現する。つまり、仮想ネットワーク機能（ＶＮＦ：Virtual Network Function）として各アプリケーションを構成する。
　また、ＨＡクラスタのような冗長構成を採用する場合において、例えばアクティブ/スタンバイ構成であれば、同じ機能を実現する仮想ネットワーク機能のペアを予め用意して、ペアの一方をアクティブ側、すなわち現用系とし、ペアの他方をスタンバイ側、すなわち待機系とする。そして、アクティブ側の仮想ネットワーク機能に何らかの障害が発生した場合には、それとペアになっている他方の仮想ネットワーク機能をスタンバイ状態からアクティブ状態に切り替えることにより瞬時のフェイルオーバを可能にする。
　一方、各サーバのハードウェア上に各仮想マシンや上記の仮想ネットワーク機能を構成するためには、実際に存在しているハードウェア、すなわち物理リソース、特に演算機能を、仮想マシンが必要とする仮想リソースに割り当てる必要がある。具体的には、サーバ内の各プロセッサ（ＣＰＵ）がチップ毎に複数の中核回路、すなわちＣＰＵコアを内蔵しているので、コア単位で、物理ＣＰＵコアを仮想ＣＰＵコアに割り当てることが必要になる。
　性能要件が高い通信ソフトウェアへネットワーク仮想化技術を適用することを考えると、リアルタイム性を追求するとともに性能のゆらぎを抑えることが求められる。このような仮想化において、高い性能要件を満たすために仮想ＣＰＵを物理的なＣＰＵ（ＣＰＵコア）に固定的に対応付ける割り付け方法が用いられる。これがＣＰＵピニング（Pinning）技術である。
　例えば、非特許文献１は、オープンソースで開発されているクラウド環境構築用のソフトウェア群である「OpenStack」において、ＣＰＵピニングを設定することを示している。具体的には、「OpenStack」においてフレーバー（flavor）と呼ばれる仮想ハードウェアのテンプレートの「Extra Specs」の項目に「hw_cpu_policy=dedicated」という形式でＣＰＵの固定割り付けポリシーを記述できることを示している。ＣＰＵの固定割り付けポリシーが設定されたフレーバーを用いることで、ＣＰＵの固定割り付けが実現できる。ただし、フレーバーは仮想マシン毎の指定である。
　また、非特許文献２はリナックス（Linux（登録商標））カーネル仮想化基盤（ＫＶＭ：Kernel-based Virtual Machine）におけるＣＰＵピニング設定を示している。具体的には、仮想マシンの設定ファイル（ＸＭＬファイル）内の「vcpupin」の設定項目にて、仮想ＣＰＵに割り当てる物理的なＣＰＵを指定できることを示している。
　また、例えば非特許文献３は、ＨＡ技術を示している。すなわち、通信ソフトウェアの多くはアクティブ/スタンバイ（ACT/SBY）構成や「Ｎ＋Ｍ構成」のようなＨＡ構成を採用することで可用性を高めることを示している。アクティブ/スタンバイ構成は、同じシステムを複数用意して耐障害性を高めたシステムで、幾つか(2系統の場合は片方)を待機状態にして、障害時に切り替えて処理を引き継ぐ方式である。一方、「Ｎ＋Ｍ構成」では、エラー発生時に現用ブレードの代わりに予備ブレードが稼働されるように、多数の現用ブレード（Ｎ）に対して複数の予備ブレード（Ｍ）を電源オフの状態で用意しておく。
　例えばアクティブ/スタンバイ構成では、動作中(Active)コンポーネントと、待機中(Standby)コンポーネントが存在し、Activeコンポーネントに障害が発生した場合には、Standbyコンポーネントが処理を引き継ぐことで、サービスの停止を防ぐ、あるいは停止時間を極めて短い時間にすることが可能である。
"Ｆｌａｖｏｒｓ"、[online]、OpenStack Docs、[２０１８年１月２２日検索]、インターネット<URL:https://docs.openstack.org/nova/pike/admin/flavors.html> "ｌｉｂｖｉｒｔ"、[online]、Domain XML format、[２０１８年１月２２日検索]、インターネット<URL:https://libvirt.org/formatdomain.html#elementsCPUTuning/> "Service Availability(TM) Forum, Application Interface Specification", [online]、 Availability Management Framework, SAI-AIS-AMF-B.04.01、[２０１８年１月２２日検索]、インターネット<URL:http://devel.opensaf.org/SAI-AIS-AMF-B.04.01.AL.pdf>
　上記のＨＡ構成を採用する場合、ハードウェアの障害発生を考慮すると、ＨＡ構成をとる複数のコンポーネントをそれぞれ異なるハードウェア上で動作させる必要がある。また、通信ソフトウェアに仮想化技術を適用してアクティブ/スタンバイ構成を採用する場合には、アクティブ側の仮想ネットワーク機能を実現するアクティブ側の仮想マシンと、スタンバイ側の仮想ネットワーク機能を実現するスタンバイ側の仮想マシンとをそれぞれ準備して、これらを別々のハードウェア上に配置することになる。
　また、上記のような構成において適用する通信ソフトウェアの性能要件が高いと、例えば上記のＣＰＵピニングのような手法を採用し、ハードウェアのリソースを占有する状態でアクティブ側の仮想マシンを構築することが必要になる。また、スタンバイ側の仮想マシンについても、アクティブ側と同じ性能を確保するために同じだけのリソースを準備する必要が生じる。
　しかしながら、障害が発生していない時にはスタンバイ側の仮想マシンは稼働していないので、スタンバイ側の仮想マシンに大きな性能を有するハードウェアリソースを固定的に割り当てておくと無駄が多くなる。つまり、アクティブ側およびスタンバイ側に同じハードウェアリソースを準備することにより、リソースの利用効率が上がらなくなり、仮想化技術のメリットが阻害される。
　本発明は、上記の状況に鑑みてなされたものであり、現用系の仮想マシンの性能保証を可能にすると共に、待機系の仮想マシンを含むシステム全体についてのリソース利用効率を改善することが可能なサービス提供システム、資源割り当て方法、及び資源割り当てプログラムを提供することを目的とする。
（１）所望のサービスを提供可能なアプリケーション機能を、互いにペアをなす第１仮想マシン及び第２仮想マシンにより構成し、少なくとも初期状態では前記第１仮想マシンをアクティブ状態、前記第２仮想マシンをスタンバイ状態に定め、アクティブ状態の前記第１仮想マシン又は前記第２仮想マシンを利用してサービスを提供するサービス提供システムであって、
　前記第１仮想マシン及び前記第２仮想マシンに割り当て可能な複数のハードウェア計算機資源と、
　前記第１仮想マシン及び前記第２仮想マシンを起動する際に、事前に定めた初期条件に従って前記複数のハードウェア計算機資源のいずれかを前記第１仮想マシン及び前記第２仮想マシンに割り当てる初期リソース割り当て部と、
　少なくともサービスを開始する前に、前記第１仮想マシンに割り当てるハードウェア計算機資源は、前記第１仮想マシンの占有又は実行優先度が高い状態に定め、前記第２仮想マシンに割り当てるハードウェア計算機資源は、前記第２仮想マシンと他の仮想マシンとの共有が可能な状態に定めるリソース割り当て変更部と、
　を備えたサービス提供システム。
　このサービス提供システムによれば、前記リソース割り当て変更部が前記第１仮想マシンに例えば占有の計算機資源を割り当てることにより、前記第１仮想マシンが要求される性能を満たすように十分な計算機資源を割り当てることができる。また、前記リソース割り当て変更部が前記第２仮想マシンに共有の計算機資源を割り当てることにより、システム全体について計算機資源の利用効率を改善できる。しかも、初期状態では事前に定めた初期条件に従って、前記初期リソース割り当て部が計算機資源を割り当てるので、各仮想マシンの起動時にシステム全体の動作を安定化したり、計算機資源の利用効率を高めることが可能になる。
（２）前記初期リソース割り当て部は、前記複数のハードウェア計算機資源の中から事前に定めた起動用コアを選択し、前記起動用コアを初期状態の前記第１仮想マシン及び前記第２仮想マシンに割り当て、
　前記リソース割り当て変更部は、前記第１仮想マシン及び前記第２仮想マシンに対して計算機資源の割り当てを変更する、
　上記（１）に記載のサービス提供システム。
　このサービス提供システムによれば、前記第１仮想マシン及び前記第２仮想マシンに初期状態で割り当てる計算機資源が特定の起動用コアのみに限定されるので、各仮想マシンの起動時にシステム全体の動作を安定化することができる。すなわち、仮想マシンを起動する際にはＣＰＵなどの計算機資源に非常に大きな負荷がかかる可能性がある。しかし、既に稼働している他の仮想マシンに割り当てた計算機資源から独立した起動用コアで新たな仮想マシンを起動することで、起動時の負荷変動が他の仮想マシンに影響するのを避けることができる。更に前記第１仮想マシン及び前記第２仮想マシンについては、前記リソース割り当て変更部が計算機資源の割り当てを変更する。これにより、システム全体について計算機資源の利用効率を改善できる。
（３）前記初期リソース割り当て部は、前記複数のハードウェア計算機資源の中から複数の仮想マシンが共通に利用可能な共有コアを選択し、前記共有コアを初期状態の前記第１仮想マシン及び前記第２仮想マシンに割り当て、
　前記リソース割り当て変更部は、前記第１仮想マシン及び前記第２仮想マシンに対して計算機資源の割り当てを変更する、
　上記（１）に記載のサービス提供システム。
　このサービス提供システムによれば、前記第１仮想マシン及び前記第２仮想マシンのいずれを起動する場合であっても、複数の仮想マシンが共有可能な共有コアを使用するので、計算機資源の利用効率を高めることが可能になる。また、起動時の負荷変動が、既に稼働しているアクティブ状態の他の仮想マシンに与える影響を抑制できる。更に前記第１仮想マシン及び前記第２仮想マシンについては、前記リソース割り当て変更部が計算機資源の割り当てを変更する。これにより、システム全体について計算機資源の利用効率を改善できる。
（４）前記初期リソース割り当て部は、前記複数のハードウェア計算機資源の中から単一の仮想マシンの占有又は実行優先度が高い占有コアを選択し、前記占有コアを初期状態の前記第１仮想マシン及び前記第２仮想マシンに割り当て、
　前記リソース割り当て変更部は、前記第１仮想マシンに対して計算機資源の割り当てを変更せず、且つ前記第２仮想マシンに対して計算機資源の割り当てを変更する、
　上記（１）に記載のサービス提供システム。
　このサービス提供システムによれば、前記第１仮想マシンについては、前記リソース割り当て変更部が計算機資源の割り当てを変更することなく、割り当て動作を完了しそのままサービス提供を開始できる。したがって、サービスを要求してからサービスを開始するまでの遅延時間を短縮できる。また、前記第２仮想マシンに対しては前記リソース割り当て変更部が計算機資源の割り当てを変更するが、前記第２仮想マシンはスタンバイ状態なので、この割り当て変更の所要時間は、サービス開始までの遅延時間には影響しない。
（５）アクティブ状態の前記第１仮想マシンにおける障害発生を検知し、前記第２仮想マシンに割り当てられている前記ハードウェア計算機資源が複数の仮想マシンで共有可能な共有コアである場合には、前記第２仮想マシン以外の他の仮想マシンを前記共有コアの割り当て先から排除する障害時制御部、
　を備えた上記（１）乃至（４）のいずれかに記載のサービス提供システム。
　このサービス提供システムによれば、前記第１仮想マシンに障害が発生した場合に、前記第２仮想マシンがスタンバイ状態からアクティブ状態に切り替わるだけであり、前記第２仮想マシンに対する計算機資源の割り当てを変更する必要がない。しかも、前記第２仮想マシンに割り当てた共有コアからこれを利用する他の仮想マシンが排除されるので、アクティブ状態の前記第２仮想マシンに必要な性能を満たす計算機資源が結果的に割り当てられる。したがって、障害時のフェイルオーバに伴うサービスの中断や遅延を最小化できる。
（６）アクティブ状態の前記第１仮想マシンにおける障害発生を検知し、前記第２仮想マシンに割り当てられている前記ハードウェア計算機資源が複数の仮想マシンで共有可能な共有コアである場合には、前記複数のハードウェア計算機資源の中から占有又は優先利用可能な新たな占有コアを確保して前記第２仮想マシンに割り当てる障害時制御部、
　を備えた上記（１）乃至（４）のいずれかに記載のサービス提供システム。
　このサービス提供システムによれば、障害発生直後に前記第２仮想マシンに割り当てられている計算機資源を、他の多数の仮想マシンが共有した状態で使用している場合であっても、前記第２仮想マシンに対する新たな占有コアの再割り当てを短時間で完了できる。したがって、同じ計算機資源の共有により生じる前記第２仮想マシンの性能低下を短時間で回復できる。
（７）所望のサービスを提供可能なアプリケーション機能を、互いにペアをなす第１仮想マシン及び第２仮想マシンにより構成し、少なくとも初期状態では前記第１仮想マシンをアクティブ状態、前記第２仮想マシンをスタンバイ状態に定め、アクティブ状態の前記第１仮想マシン又は前記第２仮想マシンを利用してサービスを提供するシステムを制御するための資源割り当て方法であって、
　前記第１仮想マシン及び前記第２仮想マシンを起動する際に、事前に定めた初期条件に従って予め用意された複数のハードウェア計算機資源のいずれかを前記第１仮想マシン及び前記第２仮想マシンに割り当て、
　少なくともサービスを開始する前に、前記第１仮想マシンに割り当てるハードウェア計算機資源は、前記第１仮想マシンの占有又は実行優先度が高い状態に定め、前記第２仮想マシンに割り当てるハードウェア計算機資源は、前記第２仮想マシンと他の仮想マシンとの共有が可能な状態に定める、
　資源割り当て方法。
　この資源割り当て方法によれば、前記第１仮想マシンに占有の計算機資源を割り当てることにより、前記第１仮想マシンが要求される性能を満たすように十分な計算機資源を割り当てることができる。また、前記第２仮想マシンに共有の計算機資源を割り当てることにより、システム全体について計算機資源の利用効率を改善できる。しかも、初期状態では事前に定めた初期条件に従って計算機資源を割り当てるので、各仮想マシンの起動時にシステム全体の動作を安定化したり、計算機資源の利用効率を高めることが可能になる。
（８）所望のサービスを提供可能なアプリケーション機能を、互いにペアをなす第１仮想マシン及び第２仮想マシンにより構成し、少なくとも初期状態では前記第１仮想マシンをアクティブ状態、前記第２仮想マシンをスタンバイ状態に定め、アクティブ状態の前記第１仮想マシン又は前記第２仮想マシンを利用してサービスを提供するシステムを制御する計算機が実行可能な資源割り当てプログラムであって、
　前記第１仮想マシン及び前記第２仮想マシンを起動する際に、事前に定めた初期条件に従って予め用意された複数のハードウェア計算機資源のいずれかを前記第１仮想マシン及び前記第２仮想マシンに割り当てる初期リソース割り当て手順と、
　少なくともサービスを開始する前に、前記第１仮想マシンに割り当てるハードウェア計算機資源は、前記第１仮想マシンの占有又は実行優先度が高い状態に定め、前記第２仮想マシンに割り当てるハードウェア計算機資源は、前記第２仮想マシンと他の仮想マシンとの共有が可能な状態に定めるリソース割り当て変更手順と、
　を有する資源割り当てプログラム。
　この資源割り当てプログラムを所定のコンピュータで実行して前記システムを制御する場合には、例えば前記第１仮想マシンに占有の計算機資源を割り当てるので、前記第１仮想マシンが要求される性能を満たすように十分な計算機資源を割り当てることができる。また、前記第２仮想マシンに共有の計算機資源を割り当てることにより、システム全体について計算機資源の利用効率を改善できる。しかも、初期状態では事前に定めた初期条件に従って計算機資源を割り当てるので、各仮想マシンの起動時にシステム全体の動作を安定化したり、計算機資源の利用効率を高めることが可能になる。
　本発明のサービス提供システム、資源割り当て方法、及び資源割り当てプログラムによれば、現用系の仮想マシンの性能保証を可能にすると共に、待機系の仮想マシンを含むシステム全体についてのリソース利用効率を改善することが可能である。
本実施形態における通信サービスを提供するシステムの構成例を示すブロック図である。 比較例における通信サービスを提供するシステムの構成例を示すブロック図である。 本発明を実施するために必要な構成要素を備えたサービス提供システムの構成例を示すブロック図である。 仮想マシン起動時において、各仮想マシンを構成する仮想コアと物理コアとの割り当て状態の例を示すブロック図である。 割り当て変更後において、各仮想マシンを構成する仮想コアと物理コアとの割り当て状態の例を示すブロック図である。 リソース割り当てを実現するための動作例を示すフローチャートである。 仮想マシン起動時において、各仮想マシンを構成する仮想コアと物理コアとの割り当て状態の例を示すブロック図である。 割り当て変更後において、各仮想マシンを構成する仮想コアと物理コアとの割り当て状態の例を示すブロック図である。 リソース割り当てを実現するための動作例を示すフローチャートである。 仮想マシン起動時の各仮想マシンを構成する仮想コアと物理コアとの割り当て状態の例を示すブロック図である。 図７及び図５Ｂに示したようなリソース割り当てを実現するための動作例を示すフローチャートである。 仮想マシン起動時における仮想マシン設定ファイルの内容の記述例を表す模式図である。 仮想マシン起動時における仮想マシン設定ファイルの内容の記述例を表す模式図である。 仮想マシン起動時における仮想マシン設定ファイルの内容の記述例を表す模式図である。 割り当てを変更した後のアクティブ側仮想マシン設定ファイルの内容の記述例を表す模式図である。 割り当てを変更した後のスタンバイ側仮想マシン設定ファイルの内容の記述例を表す模式図である。 リソース管理テーブルに従って各仮想マシンにリソースを割り当てる場合の動作例を示すフローチャートである。 障害発生直後におけるシステムの構成及びリソース割り当て状態の例を表すブロック図である。 フェイルオーバの途中におけるシステムの構成及びリソース割り当て状態の例を表すブロック図である。 フェイルオーバ後におけるシステムの構成及びリソース割り当て状態の例を表すブロック図である。 障害発生時のフェイルオーバのための動作例－１を示すフローチャートである。 障害発生時のフェイルオーバのための動作例－２を示すフローチャートである。 冗長構成管理テーブルの構成例を示す模式図である。 リソース管理テーブルの構成例を示す模式図である。
　本発明の実施形態について各図を参照しながら以下に説明する。
＜通信システムの基本的な構成例＞
　通信サービスを提供するシステムの定常状態における基本的な構成例を図１Ａ及び図１Ｂにそれぞれ示す。なお、このシステムを管理する装置は図１Ａ及び図１Ｂにおいては省略されている。
　図１Ｂに示す構成が一般的に想定される構成であり、図１Ａは図１Ｂの構成を改良した場合に想定される構成を表している。理解を容易にするために、まず図１Ｂに示す構成について説明する。
　図１Ｂに示す比較例のサービス提供システム１００Ａは複数台のサーバ３１、３２、３３、及び３４を備えている。サーバ３１～３４は、物理リソース１０－１、１０－２、１０－３、及び１０－４、すなわち計算機の動作に必要な電子回路のハードウェアをそれぞれ内蔵している。
　また、各物理リソース１０－１～１０－４は、独立した複数の物理ＣＰＵコア１１をそれぞれ内蔵している。実際のプロセッサ（ＣＰＵ）のハードウェアは、１つ又は複数の回路基板上に搭載された１つ又は複数の半導体集積回路のチップとして存在している。また、各チップのパッケージの中には互いに独立して動作可能な複数の中核回路、すなわち複数の物理ＣＰＵコアを含む場合が多い。したがって、このような計算機資源を管理する場合には、ＣＰＵコア毎に独立した状態で管理する必要がある。
　図１Ｂに示した例では、サーバ３１上に仮想ネットワーク機能２１及び２２が配置され、サーバ３２上に仮想ネットワーク機能２３及び２４が配置され、サーバ３３上に仮想ネットワーク機能２１Ｂ及び２２Ｂが配置され、サーバ３４上に仮想ネットワーク機能２３Ｂ及び２４Ｂが配置されている。
　これらの仮想ネットワーク機能２１～２４及び２１Ｂ～２４Ｂの各々は、通信サービスを提供するキャリア網などが必要とする様々な通信機能、例えばファイアウォール、パケット交換機、音声交換機などに対応する。但し、ここではネットワーク機能の仮想化技術ＮＦＶを採用しているので、各仮想ネットワーク機能２１～２４及び２１Ｂ～２４Ｂは、仮想ネットワーク機能ＶＮＦとして存在している。
　すなわち、汎用サーバのハードウェア上で稼働する仮想マシン（ＶＭ：Virtual Machine）がそれに組み込まれたアプリケーションソフトウェアを実行することにより、各仮想ネットワーク機能ＶＮＦが実現する。例えば、図１Ｂに示した仮想ネットワーク機能２１～２４は、互いに異なる機能を実現する仮想ネットワーク機能ＶＮＦ１、ＶＮＦ２、ＶＮＦ３、およびＶＮＦ４として利用される。
　一方、システムを休みなく稼働させる必要があるので、図１Ｂに示したサービス提供システム１００Ａは、ＨＡクラスタのような冗長構成を採用した場合を想定している。つまり、同じ機能を実現する仮想ネットワーク機能のペアを予め用意して、ペアの一方をアクティブ側、すなわち現用系ＡＣＴとし、ペアの他方をスタンバイ側、すなわち待機系ＳＢＹとする。そして、アクティブ側の仮想ネットワーク機能に何らかの障害が発生した場合には、それとペアになっている他方の仮想ネットワーク機能をスタンバイ状態からアクティブ状態に切り替えることにより瞬時のフェイルオーバを可能にする。
　図１Ｂの例では、仮想ネットワーク機能２１～２４のそれぞれが現用系ＡＣＴとして稼働し、仮想ネットワーク機能２１Ｂ～２４Ｂが待機系ＳＢＹになっている状態を想定している。したがって、例えば現用系ＡＣＴの仮想ネットワーク機能ＶＮＦ１に何らかの障害が発生した場合には、これとペアの待機系ＳＢＹの想化ネットワーク機能ＶＮＦ１、すなわち仮想ネットワーク機能２１Ｂが待機系ＳＢＹから現用系ＡＣＴに切り替わり、仮想ネットワーク機能２１の代わりに同じ通信サービスの提供を継続することができる。
　一方、仮想ネットワーク機能２１～２４及び２１Ｂ～２４Ｂを実際に構成するためには、各々のアプリケーションソフトウェアを実行可能な仮想マシンを各サーバ３１～３４上に構築する必要がある。図１Ｂの例では、仮想ネットワーク機能２１～２４及び２１Ｂ～２４Ｂはそれぞれ独立した仮想マシン上で実現されている。
　また、各仮想マシンを実現するためには、それぞれが利用可能なハードウェアの機能を確保する必要がある。したがって、各仮想マシンに含まれる１つ又は複数の仮想ＣＰＵコア１２のそれぞれに対して、物理ＣＰＵコア１１を割り当てる。図１Ｂに示した構成においては、物理ＣＰＵコア１１と仮想ＣＰＵコア１２とが１対１で個別に対応付けられ、リンク１３により関連付けられている。
　したがって、図１Ｂに示した構成においては、仮想ネットワーク機能２１～２４及び２１Ｂ～２４Ｂのいずれの仮想マシンにおいても、それぞれ独立した物理ＣＰＵコア１１をそれ自身の占有状態で使用することができる。つまり、各々の物理ＣＰＵコア１１の性能は変化しないので、それを仮想ＣＰＵコア１２として使用する各仮想マシンの性能も、他の仮想マシンの影響を受けることがなく変化しない。そのため、仮想ネットワーク機能２１～２４に要求される性能を容易に保証できる。
　また、図１Ｂの例では現用系ＡＣＴだけでなく、待機系ＳＢＹの仮想ネットワーク機能２１Ｂ～２４Ｂに対しても、それぞれ占有状態で仮想ＣＰＵコア１２に物理ＣＰＵコア１１を割り当てている。そのため、各仮想ネットワーク機能２１Ｂ～２４Ｂが待機系ＳＢＹから現用系ＡＣＴに切り替わった場合においても、これらに要求される性能を容易に保証できる。
　しかし、障害が全く発生しない場合を想定すると、待機系ＳＢＹの各仮想ネットワーク機能２１Ｂ～２４Ｂが現用系ＡＣＴに切り替わることはないので、各仮想ネットワーク機能２１Ｂ～２４Ｂに割り当てられた全ての物理ＣＰＵコア１１は不使用状態になる。そのため、システム全体としてリソース、すなわち計算機ハードウェアの利用効率が著しく低下する。但し、実際には障害が発生した時の性能を保証する必要があるので、待機系ＳＢＹの各仮想ネットワーク機能２１Ｂ～２４Ｂに対しても、現用系ＡＣＴと同様に十分なリソースを割り当てておく必要がある。
　そこで、リソースの利用効率を改善するために、図１Ｂの構成の代わりに、図１Ａに示したサービス提供システム１００Ｂのような構成を採用することが想定される。図１Ａの構成について以下に説明する。
　図１Ａに示す本実施形態のサービス提供システム１００Ｂは、図１Ｂの構成と同様に、複数台のサーバ３１、３２、３３、及び３４を備えている。サーバ３１～３４は、物理リソース１０－１、１０－２、１０－３、及び１０－４、すなわち計算機の動作に必要な電子回路のハードウェアをそれぞれ内蔵している。また、各物理リソース１０－１～１０－４は、独立した複数の物理ＣＰＵコア１１をそれぞれ内蔵している。
　図１Ａに示した例では、サーバ３１上に仮想ネットワーク機能２１及び２２が配置され、サーバ３２上に仮想ネットワーク機能２３及び２４が配置され、サーバ３３上に仮想ネットワーク機能２５及び２６が配置されている。また、サーバ３４上に仮想ネットワーク機能２１Ｂ、２２Ｂ、２３Ｂ、２４Ｂ、２５Ｂ、及び２６Ｂが配置されている。
　図１Ａの構成ではネットワーク機能の仮想化技術ＮＦＶを採用しているので、各仮想ネットワーク機能２１～２６及び２１Ｂ～２６Ｂは、仮想ネットワーク機能ＶＮＦとして存在している。また、現用系ＡＣＴの仮想ネットワーク機能２１と待機系ＳＢＹの仮想ネットワーク機能２１Ｂとがペアになり冗長化した仮想ネットワーク機能ＶＮＦ１を形成している。
　同様に、仮想ネットワーク機能２２及び２２Ｂがペアになり冗長化した仮想ネットワーク機能ＶＮＦ２を形成している。また、仮想ネットワーク機能２３及び２３Ｂがペアになり冗長化した仮想ネットワーク機能ＶＮＦ３を形成している。また、仮想ネットワーク機能２４及び２４Ｂがペアになり冗長化した仮想ネットワーク機能ＶＮＦ４を形成している。また、仮想ネットワーク機能２５及び２５Ｂがペアになり冗長化した仮想ネットワーク機能ＶＮＦ５を形成している。また、仮想ネットワーク機能２６及び２６Ｂがペアになり冗長化した仮想ネットワーク機能ＶＮＦ６を形成している。
　汎用サーバのハードウェア上で稼働する仮想マシンが、それに組み込まれたアプリケーションソフトウェアを実行することにより、図１Ａに示した各仮想ネットワーク機能ＶＮＦ１～ＶＮＦ６が実現する。
　図１Ａに示した構成では、仮想ネットワーク機能２１の各仮想ＣＰＵコア１２に、物理リソース１０－１の物理ＣＰＵコア１１が１対１で割り当てられている。また、仮想ネットワーク機能２２の各仮想ＣＰＵコア１２に、物理リソース１０－１の物理ＣＰＵコア１１が１対１で割り当てられている。つまり、仮想ネットワーク機能２１及び２２の各仮想マシンは、物理リソース１０－１の物理ＣＰＵコア１１を占有した状態で使用できる。
　同様に、仮想ネットワーク機能２３の各仮想ＣＰＵコア１２に、物理リソース１０－２の物理ＣＰＵコア１１が１対１で割り当てられ、仮想ネットワーク機能２４の各仮想ＣＰＵコア１２に、物理リソース１０－２の物理ＣＰＵコア１１が１対１で割り当てられている。また、仮想ネットワーク機能２５の各仮想ＣＰＵコア１２に、物理リソース１０－３の物理ＣＰＵコア１１が１対１で割り当てられ、仮想ネットワーク機能２６の各仮想ＣＰＵコア１２に、物理リソース１０－３の物理ＣＰＵコア１１が１対１で割り当てられている。
　一方、仮想ネットワーク機能２１Ｂ、２２Ｂ、２３Ｂ、２４Ｂ、２５Ｂ、及び２６Ｂの仮想マシンの仮想ＣＰＵコア１２は、物理リソース１０－４上の共通の物理ＣＰＵコア１１に割り当てられ、それぞれ個別にリンク１３で関連付けられている。つまり、現用系ＡＣＴの仮想ネットワーク機能２１～２６については、いずれも物理ＣＰＵコア１１が単一の仮想マシンの占有状態で割り当てられている。また、待機系ＳＢＹの仮想ネットワーク機能２１Ｂ～２６Ｂについては、共有の物理ＣＰＵコア１１を複数の仮想マシンが共有する状態で割り当てられている。なお、共有の物理コアとは、実際に複数の仮想マシンによって共有されているものだけではなく、アイドル状態であり複数の仮想マシンによって共有可能なものを含む。
　つまり、待機系ＳＢＹの仮想ネットワーク機能２１Ｂ～２６Ｂが待機系のままである状況においては、これらは能力の高いハードウェアの計算機資源を必要としない。したがって図１Ａに示すように共通の物理ＣＰＵコア１１を複数の仮想マシンで共有するように、待機系ＳＢＹの仮想ネットワーク機能２１Ｂ～２６Ｂにリソース割り当てを行うことができる。
　図１Ａの構成ではシステム全体のリソース利用効率が改善されているので、図１Ｂと同じハードウェアを用いて、仮想ネットワーク機能ＶＮＦ１～ＶＮＦ６の数を４から６に増やすことができる。
　しかし、実際のシステムにおいては、状況の変化に伴い、仮想ネットワーク機能ＶＮＦ１～ＶＮＦ６の数が増減する。また、障害の発生に伴って現用系ＡＣＴと待機系ＳＢＹとが切り替わったり、新たな現用系ＡＣＴや待機系ＳＢＹを用意する必要が生じる。つまり、図１Ａに示した構成のように最初から固定的にリソースを割り当てておくことはできない。また、各仮想ネットワーク機能ＶＮＦ１～ＶＮＦ６の待機系ＳＢＹが現用系ＡＣＴに切り替わった場合には、共有リソースの割り当てにより必要な性能が得られなくなる可能性がある。
＜サービス提供システムの構成例＞
　本発明を実施するために必要な構成要素を備えたサービス提供システムの構成例を図２に示す。つまり、図２に示したサービス提供システムは、例えば図１Ａに示したようなシステム構成を実現するために必要なハードウェアの他に、各仮想マシンや仮想ネットワーク機能ＶＮＦを実現し、これらにリソースを割り当てるための管理機能を含んでいる。
　図２に示したリソース割当システム４０は、リソース要求部５０からの要求に従い、制御対象の物理リソース１０－１～１０－４から各仮想マシンに割り当てる。また、リソース割当システム４０は、状況の変化に応じて物理リソース１０－１～１０－４の割り当てを自動的に変更する。
　物理リソース１０－１～１０－４は、互いに独立して動作する複数の物理ＣＰＵコア１１を内蔵している。また、図２の構成では、仮想マシン起動時のために予め用意された起動用コア１１Ｂも物理リソース１０－１～１０－４に含まれている。各物理ＣＰＵコア１１及び起動用コア１１Ｂは、例えば図１Ａに示したサーバ３１～３４の内部にハードウェアとして実在している。
　また、図２の構成では、仮想マシン設定ファイル１４が物理リソース１０－１～１０－４に含まれている。この仮想マシン設定ファイル１４は、構築した各仮想マシンの設定状態を表す情報を保持するために利用される。リソース割当システム４０が各仮想マシンに物理リソースを割り当てると、その結果が仮想マシン設定ファイル１４の内容に反映される。
　図２に示したリソース割当システム４０は、リソース要求受付部４１、ＶＭ管理部４２、リソース払出し制御部４３、監視機能部４４、及び記憶部４５を備えている。リソース要求受付部４１は、リソース要求部５０からの要求を受け付けて、該当する仮想マシンの管理や物理リソースの割り当ての動作を開始する。
　ＶＭ管理部４２は、ＶＭ情報取得部４２ａ及びリソース操作指示部４２ｂを含む。ＶＭ管理部４２のＶＭ情報取得部４２ａは、現用系ＡＣＴ及び待機系ＳＢＹのそれぞれの仮想マシン（ＶＭ）の稼働状態の情報を取得する。また、リソース操作指示部４２ｂは、リソース払出し制御部４３に対してＣＰＵピニング設定の指示を出す。すなわち、例えば図１Ａに示した状態や、図１Ｂに示した状態のように各物理ＣＰＵコア１１を各仮想ＣＰＵコア１２に事前に定めた状態に固定的に割り当てるための指示をＶＭ管理部４２が出す。
　リソース払出し制御部４３は、リソース管理部４３ａ、リソース抽出・選定部４３ｂ、及び仮想マシン制御部４３ｃを含んでいる。リソース管理部４３ａは利用可能な各物理リソースを管理する。リソース抽出・選定部４３ｂは、割り当て可能な物理リソースの抽出及び選定を実施する。このリソース払出し制御部４３は、リソース要求部５０からの払い出し要求と、ＶＭ管理部４２からのＣＰＵピニング設定の指示に基づき、リソース払い出し制御を行う。また、リソース払出し制御部４３は各仮想マシンの起動、終了等の制御を行う。
　監視機能部４４は、ＶＭ監視機能部４４ａ及びリソース監視機能部４４ｂを含んでいる。この監視機能部４４は、各仮想マシン及び物理リソースの監視を行う。例えば、現用系ＡＣＴの仮想マシンと待機系ＳＢＹの仮想マシンとの間で、ハートビート（heart beat）と呼ばれる稼働情報を定期的に送受信している。この稼働情報をＶＭ監視機能部４４ａが確認することにより、各仮想マシンが正常に稼働しているか否かを識別できる。リソース監視機能部４４ｂは、物理リソース１０－１～１０－４における各物理ＣＰＵコア１１及び１１Ｂの割り当て状態や故障の有無などを監視する。
　記憶部４５は、リソース情報リポジトリ４５ａ及び仮想マシンイメージリポジトリ４５ｂを含んでいる。この記憶部４５は、物理リソース１０－１～１０－４のリソース利用状況、及び各仮想マシンイメージを一元的に管理するためのデータベースである。
＜リソース割り当ての動作例－１＞
　各仮想マシンを構成する仮想コアと物理コアとの割り当て状態の例を図３Ａ及び図３Ｂに示す。図３Ａは仮想マシン起動時の割り当て状態を表し、図３Ｂは割り当て変更後の状態を表す。この動作例において、リソース払出し制御部４３は、複数のハードウェア計算機資源の中から事前に定めた起動用コアを選択する初期リソース割り当て部として機能する。リソース割り当て変更部は更に、現用系ＡＣＴの仮想マシン及び待機系ＳＢＹの仮想マシンに対して計算機資源の割り当てを変更するリソース割り当て変更部として機能する。
　図３Ａに示した構成においては、物理リソース１０－１～１０－４の上の物理ＣＰＵコア１１の中で、予め用意された起動用コア１１Ｂが、仮想ネットワーク機能２０及び２０Ｂに割り当てられている。つまり、同じ機能を果たす現用系ＡＣＴの仮想ネットワーク機能２０、及び待機系ＳＢＹの仮想ネットワーク機能２０Ｂの全ての仮想ＣＰＵコア１２が共通の起動用コア１１Ｂのみを共有するようにリソースを割り当ててある。したがって、起動用コア１１Ｂと、仮想ネットワーク機能２０、２０Ｂの各仮想ＣＰＵコア１２とがリンク１３で互いに関連付けられている。
　仮想マシンを起動する際には、物理ＣＰＵコア１１などのリソースに一時的に非常に大きな負荷がかかる可能性が高い。したがって、例えば既に稼働している他の仮想マシンが同じ物理ＣＰＵコア１１を共有している場合には、新たに起動する仮想マシンが既に稼働している他の仮想マシンの性能を低下させる可能性がある。しかし、図３Ａのように起動時に使用するリソースを起動用コア１１Ｂのみに限定することにより、既に稼働している他の仮想マシンに影響を及ぼすことはなくなり、安定した状態でサービス提供を継続することが可能になる。
　一方、図３Ｂに示した構成では、物理リソース１０－１～１０－４上の複数の占有コア１１－Ｘが、仮想ネットワーク機能２０の仮想ＣＰＵコア１２に割り当てられ、これらがリンク１３で互いに関連付けられている。また、物理リソース１０－１～１０－４上の複数の共有コア１１－Ｙが、仮想ネットワーク機能２０Ｂの仮想ＣＰＵコア１２に割り当てられ、これらがリンク１３で互いに関連付けられている。
　占有コア１１－Ｘは、割り当てた物理ＣＰＵコア１１と仮想ＣＰＵコア１２とを１対１の状態のみで利用できるように、ＣＰＵピニングの手法により条件付けられたものである。したがって、既に１つの仮想ＣＰＵコア１２に割り当てられた占有コア１１－Ｘは、他の仮想ＣＰＵコア１２に割り当てることはできない。
　共有コア１１－Ｙは、複数の仮想マシンの仮想ＣＰＵコア１２が共有できるように条件付けられている。したがって、リソース割り当てを行う際に、既に他の仮想ＣＰＵコア１２に割り当てられた共有コア１１－Ｙを、更に他の仮想ＣＰＵコア１２にも同時に割り当てることができる。
　なお、上記各占有コア１１－Ｘ及び共有コア１１－Ｙは、事前に固定的に割り当てる必要はない。すなわち、状況に応じて各物理ＣＰＵコア１１に対する条件付けを行うことで、必要に応じて占有コア１１－Ｘ及び共有コア１１－Ｙを確保できる。例えば、占有コア１１－Ｘでも共有コア１１－Ｙでもない空の物理ＣＰＵコア１１があり、そこに仮想マシンを配置することで占有コア１１－Ｘや共有コア１１－Ｙとなるようにしてもよい。
　また、ＣＰＵピニング以外の手法を用いて占有コア１１－Ｘと同じようなリソース割り当てを行うことも可能である。例えば、各物理ＣＰＵコア１１の実行優先度が、現用系ＡＣＴと待機系ＳＢＹとの間で異なる状態になるように調整すれば、占有コア１１－Ｘ及び共有コア１１－Ｙと同等の性能を有するリソースを実現できる。具体的には、カーネル仮想化基盤（ＫＶＭ）の環境であれば、仮想マシンの設定ファイル、すなわちＸＭＬファイル内の＜cputune＞項目配下の「share」の値を調整することで実現できる。
　図３Ｂに示した構成は、図１Ａに示した構成と同等である。つまり、図３Ｂの構成において、現用系ＡＣＴの仮想ネットワーク機能２０の仮想マシンはその仮想ＣＰＵコア１２に割り当てられた占有コア１１－Ｘを占有できるので、必要とされる性能を保証するために十分なリソースを確保できる。また、待機系ＳＢＹの仮想ネットワーク機能２０Ｂの仮想マシンの仮想ＣＰＵコア１２に割り当てられた共有コア１１－Ｙは、同時に他の仮想マシンに割り当てて共有することもできるため、物理リソースの利用効率を上げることができる。
　しかし、実際のシステムにおいては、状況の変化に伴い、例えば図１Ａに示した仮想ネットワーク機能ＶＮＦ１～ＶＮＦ６の数が増減する。また、障害の発生に伴って現用系ＡＣＴと待機系ＳＢＹとが切り替わったり、新たな現用系ＡＣＴや待機系ＳＢＹを用意する必要が生じる。したがって、図３Ｂに示した構成のように最初から固定的にリソースを割り当てておくことはできない。また、仮想ネットワーク機能ＶＮＦの待機系ＳＢＹが現用系ＡＣＴに切り替わった場合には、共有リソースの割り当てにより必要な性能が得られなくなる可能性がある。
　そこで、本実施形態においては、各仮想マシンを起動する際に、図３Ａに示したような構成になるようにリソースを割り当てる。そして、図３Ａに示した状態から、リソースの割り当てを変更して図３Ｂに示した状態に切り替える。つまり、以下に示すように制御する。
　図３Ａ及び図３Ｂに示したようなリソース割り当てを実現するための動作例を図４に示す。すなわち、図２に示したリソース割当システム４０が図４に示した手順に従って動作を実行することにより、図３Ａに示した状態のようにリソースを割り当て、更に図３Ｂに示した状態のようにリソースを割り当てることができる。図４に示した動作について以下に説明する。
　リソース割当システム４０内のリソース要求受付部４１は、リソース要求部５０からのリソース割り当て要求をステップＳ１１で受け付けて、ＶＭ管理部４２及びリソース払出し制御部４３に指示を与える。
　リソース払出し制御部４３は、今回のリソース割り当て要求に対して割り当て可能なリソースを、ステップＳ１２で物理リソース１０－１～１０－４上から抽出する。
　また、リソース払出し制御部４３は割り当て可能なリソースの中から、より適切なリソースをステップＳ１３で選定する。例えば、障害の発生を考慮する場合は現用系ＡＣＴと待機系ＳＢＹとを別々のハードウェア上に搭載することが望ましい。したがって、例えば現用系ＡＣＴの仮想ＣＰＵコア１２に割り当てる物理ＣＰＵコア１１をサーバ３１上で選定した場合は、待機系ＳＢＹの仮想ＣＰＵコア１２に割り当てる物理ＣＰＵコア１１は別のサーバ３２～３４上などから選定する。また、本実施形態では各仮想マシンの起動時は常に起動用コア１１Ｂを選定する。
　リソース払出し制御部４３は、ステップＳ１１～Ｓ１３の内容を反映するように、ステップＳ１４で管理テーブルを更新する。この管理テーブルには、例えば後述する冗長構成管理テーブルＴＢ１及びリソース管理テーブルＴＢ２が含まれる。
　ＶＭ管理部４２は、管理テーブルの内容に従い、ステップＳ１５で現用系ＡＣＴ及び待機系ＳＢＹのそれぞれについて新たな仮想マシンを起動する。ここで起動する各仮想マシンの仮想ＣＰＵコア１２には上記管理テーブル上で起動用コア１１Ｂが割り当てられている。したがって、例えば図３Ａに示すようなリソース割り当て状態で、仮想ネットワーク機能２０及び２０Ｂの各仮想マシンがステップＳ１５で起動する。
　ＶＭ管理部４２のＶＭ情報取得部４２ａは、ステップＳ１５で起動した各仮想マシンの起動状態をステップＳ１６でそれぞれ確認する。すなわち、現用系ＡＣＴとして起動した仮想マシンと、待機系ＳＢＹとして起動した仮想マシンとを区別する。また、その結果を反映して各仮想マシンに対するリソース割り当てを変更するように、ステップＳ１６でリソース操作指示部４２ｂがリソース払出し制御部４３に指示を与える。
　リソース払出し制御部４３は、リソース操作指示部４２ｂの指示に従い、該当する仮想マシンに割り当て可能なリソースを、ステップＳ１７で物理リソース１０－１～１０－４上から抽出する。
　また、リソース払出し制御部４３は割り当て可能なリソースの中から、より適切なリソースをステップＳ１８で選定する。例えば、障害の発生を考慮する場合は現用系ＡＣＴと待機系ＳＢＹとを別々のハードウェア上に搭載することが望ましい。したがって、例えば現用系ＡＣＴの仮想ＣＰＵコア１２に割り当てる物理ＣＰＵコア１１をサーバ３１上で選定した場合は、待機系ＳＢＹの仮想ＣＰＵコア１２に割り当てる物理ＣＰＵコア１１は別のサーバ３２～３４上などから選定する。
　また、本実施形態では現用系ＡＣＴの仮想ＣＰＵコア１２に対しては占有コア１１－Ｘを割り当て、待機系ＳＢＹの仮想ＣＰＵコア１２に対しては共有コア１１－Ｙを割り当てるように選定する。占有コア１１－Ｘを割り当てる場合は、例えばＣＰＵピニングの手法を用いて１対１で、占有コア１１－Ｘと仮想ＣＰＵコア１２とを対応付ける。なお、例えば実際に物理ＣＰＵコア１１のリソース割り当てを行った後で、これを占有コア１１－Ｘ、又は共有コア１１－Ｙとして機能するように条件付けを変更してもよい。
　リソース払出し制御部４３は、ステップＳ１５～Ｓ１８の内容を反映するように、ステップＳ１９で管理テーブルを更新する。また、Ｓ１９で更新した管理テーブルの内容に従い、ＶＭ管理部４２がステップＳ２０で仮想マシン設定ファイル１４内の該当する仮想マシンの記述内容を更新する。更に、ＶＭ管理部４２の指示に従い、リソース払出し制御部４３内の仮想マシン制御部４３ｃが該当する仮想マシン（ＶＭ）をステップＳ２１で再起動する。なお、例えばカーネル仮想化基盤（ＫＶＭ）を利用している環境であれば、「virsh edit」コマンドを利用することにより、仮想マシン設定ファイル１４の内容を編集できる。
　リソース割当システム４０内のリソース要求受付部４１は、ステップＳ１１で受け付けたリソース割り当て要求に対するリソース払い出し応答を、ステップＳ２２でリソース要求部５０に通知する。
　したがって、図３Ａに示したようなリソース割り当て状態を経由して、図３Ｂに示したようなリソース割り当て状態で、サービス提供システムを構成するように、リソース割当システム４０が制御することができる。
＜リソース割り当ての動作例－２＞
　各仮想マシンを構成する仮想コアと物理コアとの割り当て状態の例を図５Ａ及び図５Ｂに示す。図５Ａは仮想マシン起動時の割り当て状態を表し、図５Ｂは割り当て変更後の状態を表す。この動作例において、リソース払出し制御部４３は、ハードウェア計算機資源の中から複数の仮想マシンが共通に利用可能な共有コアを選択する初期リソース割り当て部として機能する。リソース割り当て変更部は更に、現用系ＡＣＴの仮想マシン及び待機系ＳＢＹの仮想マシンに対して計算機資源の割り当てを変更するリソース割り当て変更部として機能する。
　図５Ａに示した構成においては、物理リソース１０－１～１０－４の上の物理ＣＰＵコア１１の中で、共有コア１１－Ｙのみが同じ機能を果たす仮想ネットワーク機能２０及び２０Ｂの各仮想ＣＰＵコア１２に割り当てられている。共有コア１１－Ｙは複数の仮想マシンが共有するように割り当てることができるので、図５Ａの構成では各共有コア１１－Ｙは、リンク１３により同時に複数の仮想ＣＰＵコア１２と関連付けられている。
　なお、同じ機能を果たす現用系ＡＣＴの仮想ＣＰＵコア１２と待機系ＳＢＹの仮想ＣＰＵコア１２に同じ共有コア１１－Ｙを同時に割り当ててもよいし、互いに異なる共有コア１１－Ｙを現用系ＡＣＴ及び待機系ＳＢＹの仮想ＣＰＵコア１２に割り当ててもよい。
　新たな仮想マシンの起動時に図５Ａに示した構成を採用する場合には、各仮想マシンが使用するリソースとして共有コア１１－Ｙのみが割り当てられるので、限られた物理リソースを有効に活用して仮想マシンを起動できる。したがって、物理リソースの利用効率が上がり、物理リソースを増設しなくても、より多くの仮想マシンを同時に起動することが可能になる。
　一方、図５Ｂに示した構成では、物理リソース１０－１～１０－４上の複数の占有コア１１－Ｘが、仮想ネットワーク機能２０の仮想ＣＰＵコア１２に割り当てられ、これらがリンク１３で互いに関連付けられている。また、物理リソース１０－１～１０－４上の複数の共有コア１１－Ｙが、仮想ネットワーク機能２０Ｂの仮想ＣＰＵコア１２に割り当てられ、これらがリンク１３で互いに関連付けられている。
　図５Ｂに示した構成は、図１Ａに示した構成と同等である。つまり、図５Ｂの構成において、現用系ＡＣＴの仮想ネットワーク機能２０の仮想マシンはその仮想ＣＰＵコア１２に割り当てられた占有コア１１－Ｘを占有できるので、必要とされる性能を保証するために十分なリソースを確保できる。また、待機系ＳＢＹの仮想ネットワーク機能２０Ｂの仮想マシンの仮想ＣＰＵコア１２に割り当てられた共有コア１１－Ｙは、同時に他の仮想マシンに割り当てて共有することもできるため、物理リソースの利用効率を上げることができる。
　しかし、実際のシステムにおいては、状況の変化に伴い、例えば図１Ａに示した仮想ネットワーク機能ＶＮＦ１～ＶＮＦ６の数が増減する。また、障害の発生に伴って現用系ＡＣＴと待機系ＳＢＹとが切り替わったり、新たな現用系ＡＣＴや待機系ＳＢＹを用意する必要が生じる。したがって、図５Ｂに示した構成のように最初から固定的にリソースを割り当てておくことはできない。また、仮想ネットワーク機能ＶＮＦの待機系ＳＢＹが現用系ＡＣＴに切り替わった場合には、共有リソースの割り当てにより必要な性能が得られなくなる可能性がある。
　そこで、本実施形態においては、各仮想マシンを起動する際に、図５Ａに示したような構成になるようにリソースを割り当てる。そして、図５Ａに示した状態から、リソースの割り当てを変更して図５Ｂに示した状態に切り替える。つまり、以下に示すように制御する。
　図５Ａ及び図５Ｂに示したようなリソース割り当てを実現するための動作例を図６に示す。すなわち、図２に示したリソース割当システム４０が図６に示した手順に従って動作を実行することにより、図５Ａに示した状態のようにリソースを割り当て、更に図５Ｂに示した状態のようにリソースを割り当てることができる。図６に示した動作について以下に説明する。
　リソース割当システム４０内のリソース要求受付部４１は、リソース要求部５０からのリソース割り当て要求をステップＳ３１で受け付けて、ＶＭ管理部４２及びリソース払出し制御部４３に指示を与える。
　リソース払出し制御部４３は、今回のリソース割り当て要求に対して割り当て可能なリソースを、ステップＳ３２で物理リソース１０－１～１０－４上から抽出する。
　また、リソース払出し制御部４３は割り当て可能なリソースの中から、より適切なリソースをステップＳ３３で選定する。例えば、障害の発生を考慮する場合は現用系ＡＣＴと待機系ＳＢＹとを別々のハードウェア上に搭載することが望ましい。したがって、例えば現用系ＡＣＴの仮想ＣＰＵコア１２に割り当てる物理ＣＰＵコア１１をサーバ３１上で選定した場合は、待機系ＳＢＹの仮想ＣＰＵコア１２に割り当てる物理ＣＰＵコア１１は別のサーバ３２～３４上などから選定する。また、図６の動作を行う場合は、各仮想マシンの起動時に現用系ＡＣＴ及び待機系ＳＢＹのいずれについても常に共有コア１１－Ｙを選定する。
　リソース払出し制御部４３は、ステップＳ３１～Ｓ３３の内容を反映するように、ステップＳ３４で管理テーブルを更新する。この管理テーブルには、例えば後述する冗長構成管理テーブルＴＢ１及びリソース管理テーブルＴＢ２が含まれる。
　ＶＭ管理部４２は、管理テーブルの内容に従い、ステップＳ３５で現用系ＡＣＴ及び待機系ＳＢＹのそれぞれについて新たな仮想マシンを起動する。ここで起動する各仮想マシンの仮想ＣＰＵコア１２には上記管理テーブル上で共有コア１１－Ｙが割り当てられている。したがって、例えば図５Ａに示すようなリソース割り当て状態で、仮想ネットワーク機能２０及び２０Ｂの各仮想マシンがステップＳ３５で起動する。
　ＶＭ管理部４２のＶＭ情報取得部４２ａは、ステップＳ３５で起動した各仮想マシンの起動状態をステップＳ３６でそれぞれ確認する。すなわち、現用系ＡＣＴとして起動した仮想マシンと、待機系ＳＢＹとして起動した仮想マシンとを区別する。また、その結果を反映して各仮想マシンに対するリソース割り当てを変更するように、ステップＳ３６でリソース操作指示部４２ｂがリソース払出し制御部４３に指示を与える。
　リソース払出し制御部４３は、リソース操作指示部４２ｂの指示に従い、該当する仮想マシンに割り当て可能なリソースを、ステップＳ３７で物理リソース１０－１～１０－４上から抽出する。
　また、リソース払出し制御部４３は割り当て可能なリソースの中から、より適切なリソースをステップＳ３８で選定する。例えば、障害の発生を考慮する場合は現用系ＡＣＴと待機系ＳＢＹとを別々のハードウェア上に搭載することが望ましい。したがって、例えば現用系ＡＣＴの仮想ＣＰＵコア１２に割り当てる物理ＣＰＵコア１１をサーバ３１上で選定した場合は、待機系ＳＢＹの仮想ＣＰＵコア１２に割り当てる物理ＣＰＵコア１１は別のサーバ３２～３４上などから選定する。
　また、図６の動作を行う場合には、現用系ＡＣＴの仮想ＣＰＵコア１２に対しては占有コア１１－Ｘを割り当て、待機系ＳＢＹの仮想ＣＰＵコア１２に対しては共有コア１１－Ｙを割り当てるように選定する。占有コア１１－Ｘを割り当てる場合は、例えばＣＰＵピニングの手法を用いて１対１で、占有コア１１－Ｘと仮想ＣＰＵコア１２とを対応付ける。なお、例えば実際に物理ＣＰＵコア１１のリソース割り当てを行った後で、これを占有コア１１－Ｘ、又は共有コア１１－Ｙとして機能するように条件付けを変更してもよい。
　リソース払出し制御部４３は、ステップＳ３５～Ｓ３８の内容を反映するように、ステップＳ３９で管理テーブルを更新する。また、Ｓ３９で更新した管理テーブルの内容に従い、ＶＭ管理部４２がステップＳ４０で仮想マシン設定ファイル１４内の該当する仮想マシンの記述内容を更新する。更に、ＶＭ管理部４２の指示に従い、リソース払出し制御部４３内の仮想マシン制御部４３ｃが該当する仮想マシン（ＶＭ）をステップＳ４１で再起動する。
　リソース割当システム４０内のリソース要求受付部４１は、ステップＳ３１で受け付けたリソース割り当て要求に対するリソース払い出し応答を、ステップＳ４２でリソース要求部５０に通知する。
　したがって、図５Ａに示したようなリソース割り当て状態を経由して、図５Ｂに示したようなリソース割り当て状態で、サービス提供システムを構成するように、リソース割当システム４０が制御することができる。
＜リソース割り当ての動作例－３＞
　各仮想マシンを構成する仮想コアと物理コアとの割り当て状態の例を図７に示す。図７は仮想マシン起動時における割り当て状態を表す。なお、割り当て変更後の状態は、既に説明した図５Ｂの内容と同様である。この動作例において、リソース払出し制御部４３は、複数のハードウェア計算機資源の中から単一の仮想マシンの占有又は実行優先度が高い占有コアを選択し、この占有コアを初期状態の仮想マシンに割り当てる初期リソース割り当て部として機能する。更にリソース払出し制御部４３は、現用系ＡＣＴの仮想マシンについては、計算機資源の割り当てを変更することなく割り当て動作を完了するリソース割り当て変更部として機能する。リソース払出し制御部４３は、待機系ＳＢＹの仮想マシンについては、計算機資源の割り当てを変更するリソース割り当て変更部として機能する。
　図７に示した構成においては、物理リソース１０－１～１０－４の上の物理ＣＰＵコア１１の中で、占有コア１１－Ｘのみが同じ機能を果たす仮想ネットワーク機能２０及び２０Ｂの各仮想ＣＰＵコア１２に割り当てられている。占有コア１１－Ｘは単一の仮想マシンのみが利用できるように割り当てられるので、図７の構成では独立した複数の占有コア１１－Ｘが、リンク１３により複数の仮想ＣＰＵコア１２とそれぞれ１対１で関連付けられている。
　なお、障害の発生を考慮すると、同じ機能を果たす現用系ＡＣＴの仮想ＣＰＵコア１２と待機系ＳＢＹの仮想ＣＰＵコア１２のそれぞれに対しては、互いに独立した別のハードウェア、例えば互いに異なるサーバの中から占有コア１１－Ｘを選定して割り当てることが望ましい。
　新たな仮想マシンの起動時に図７に示した構成を採用する場合には、各仮想マシンが使用するリソースとして占有コア１１－Ｘのみが割り当てられるので、最終的なリソース割り当てを完了するまでの所要時間を短縮できる。すなわち、現用系ＡＣＴの仮想マシンについては、図７に示す状態からリソース割り当てを変更しなくてもそのままサービスを開始できるので、リソース割り当ての変更に伴う処理の遅延を抑制できる。
　実際のシステムにおいては、状況の変化に伴い、例えば図１Ａに示した仮想ネットワーク機能ＶＮＦ１～ＶＮＦ６の数が増減する。また、障害の発生に伴って現用系ＡＣＴと待機系ＳＢＹとが切り替わったり、新たな現用系ＡＣＴや待機系ＳＢＹを用意する必要が生じる。したがって、図７に示した構成のように最初から固定的にリソースを割り当てておくことはできない。また、図７に示した構成のままだと、待機系ＳＢＹの仮想マシンも現用系ＡＣＴと同様に占有コア１１－Ｘのリソースを占有してしまうので、物理リソースの利用効率が上がらなくなる。
　そこで、本実施形態においては、各仮想マシンを起動する際に、図７に示したような構成になるようにリソースを割り当てる。そして、図７に示した状態から、リソースの割り当てを変更して図５Ｂに示した状態に切り替える。つまり、以下に示すように制御する。
　図７及び図５Ｂに示したようなリソース割り当てを実現するための動作例を図８に示す。すなわち、図２に示したリソース割当システム４０が図８に示した手順に従って動作を実行することにより、図７に示した状態のようにリソースを割り当て、更に例えば図５Ｂに示した状態のようにリソース割り当てを変更できる。図８に示した動作について以下に説明する。
　リソース割当システム４０内のリソース要求受付部４１は、リソース要求部５０からのリソース割り当て要求をステップＳ５１で受け付けて、ＶＭ管理部４２及びリソース払出し制御部４３に指示を与える。
　リソース払出し制御部４３は、今回のリソース割り当て要求に対して割り当て可能なリソースを、ステップＳ５２で物理リソース１０－１～１０－４上から抽出する。
　また、リソース払出し制御部４３は割り当て可能なリソースの中から、より適切なリソースをステップＳ５３で選定する。例えば、障害の発生を考慮する場合は現用系ＡＣＴと待機系ＳＢＹとを別々のハードウェア上に搭載することが望ましい。したがって、例えば現用系ＡＣＴの仮想ＣＰＵコア１２に割り当てる物理ＣＰＵコア１１をサーバ３１上で選定した場合は、待機系ＳＢＹの仮想ＣＰＵコア１２に割り当てる物理ＣＰＵコア１１は別のサーバ３２～３４上などから選定する。また、図８の動作を行う場合は、各仮想マシンの起動時に現用系ＡＣＴ及び待機系ＳＢＹのいずれについても常に占有コア１１－Ｘを選定する。
　リソース払出し制御部４３は、ステップＳ５１～Ｓ５３の内容を反映するように、ステップＳ５４で管理テーブルを更新する。この管理テーブルには、例えば後述する冗長構成管理テーブルＴＢ１及びリソース管理テーブルＴＢ２が含まれる。
　ＶＭ管理部４２は、管理テーブルの内容に従い、ステップＳ５５で現用系ＡＣＴ及び待機系ＳＢＹのそれぞれについて新たな仮想マシンを起動する。ここで起動する各仮想マシンの仮想ＣＰＵコア１２には上記管理テーブル上で占有コア１１－Ｘが割り当てられている。したがって、例えば図７に示すようなリソース割り当て状態で、仮想ネットワーク機能２０及び２０Ｂの各仮想マシンがステップＳ５５で起動する。
　ＶＭ管理部４２のＶＭ情報取得部４２ａは、ステップＳ５５で起動した各仮想マシンの起動状態をステップＳ５６でそれぞれ確認する。すなわち、現用系ＡＣＴとして起動した仮想マシンと、待機系ＳＢＹとして起動した仮想マシンとを区別する。また、その結果を反映して各仮想マシンに対するリソース割り当てを変更するように、ステップＳ５６でリソース操作指示部４２ｂがリソース払出し制御部４３に指示を与える。
　リソース払出し制御部４３は、リソース操作指示部４２ｂの指示に従い、該当する仮想マシンに割り当て可能なリソースを、ステップＳ５７で物理リソース１０－１～１０－４上から抽出する。
　また、リソース払出し制御部４３は割り当て可能なリソースの中から、より適切なリソースをステップＳ５８で選定する。例えば、障害の発生を考慮する場合は現用系ＡＣＴと待機系ＳＢＹとを別々のハードウェア上に搭載することが望ましい。したがって、例えば現用系ＡＣＴの仮想ＣＰＵコア１２に割り当てる物理ＣＰＵコア１１をサーバ３１上で選定した場合は、待機系ＳＢＹの仮想ＣＰＵコア１２に割り当てる物理ＣＰＵコア１１は別のサーバ３２～３４上などから選定する。
　また、図８の動作を行う場合には、現用系ＡＣＴの仮想ＣＰＵコア１２に対しては占有コア１１－Ｘを割り当て、待機系ＳＢＹの仮想ＣＰＵコア１２に対しては共有コア１１－Ｙを割り当てるように選定する。占有コア１１－Ｘを割り当てる場合は、例えばＣＰＵピニングの手法を用いて１対１で、占有コア１１－Ｘと仮想ＣＰＵコア１２とを対応付ける。なお、例えば実際に物理ＣＰＵコア１１のリソース割り当てを行った後で、これを占有コア１１－Ｘ、又は共有コア１１－Ｙとして機能するように条件付けを変更してもよい。
　実際には、最初に仮想マシンを起動した状態、例えば図７に示した状態で、現用系ＡＣＴの仮想マシンには占有コア１１－Ｘが割り当てられているのでこれを変更する必要はない。つまり、起動時の状態で占有コア１１－Ｘが割り当てられている待機系ＳＢＹのみについて、リソース割り当て変更のための選定をステップＳ５８で実施する。
　リソース払出し制御部４３は、ステップＳ５５～Ｓ５８の内容を反映するように、ステップＳ５９で管理テーブルを更新する。また、Ｓ５９で更新した管理テーブルの内容に従い、ＶＭ管理部４２がステップＳ６０で仮想マシン設定ファイル１４内の該当する仮想マシンの記述内容を更新する。更に、ＶＭ管理部４２の指示に従い、リソース払出し制御部４３内の仮想マシン制御部４３ｃが該当する仮想マシン（ＶＭ）をステップＳ６１で再起動する。
　リソース割当システム４０内のリソース要求受付部４１は、ステップＳ５１で受け付けたリソース割り当て要求に対するリソース払い出し応答を、ステップＳ６２でリソース要求部５０に通知する。
　したがって、図７に示したようなリソース割り当て状態を経由して、図５Ｂに示したようなリソース割り当て状態で、サービス提供システムを構成するように、リソース割当システム４０が制御することができる。
＜仮想マシン設定ファイル１４の記述例＞
　仮想マシンの初期起動時における仮想マシン設定ファイル１４の内容の記述例を図９Ａ、図９Ｂ、及び図９Ｃにそれぞれ示す。
　図９Ａに示した仮想マシン設定ファイル１４Ａの内容は、例えば図３Ａに示したようなリソース割り当てを実現するための記述例である。すなわち、図９Ａの記述例は、仮想マシン設定ファイル１４Ａ中の＜cputune＞項目において、０番、１番、２番の「vcpu」で示された各仮想マシンの仮想ＣＰＵコア１２に対して、起動用コア１１Ｂとして用意された０番の物理ＣＰＵコア１１を割り当てることを意味している。
　また、図９Ｂに示した仮想マシン設定ファイル１４Ｂの内容は、例えば図５Ａに示したようなリソース割り当てを実現するための記述例である。すなわち、図９Ｂの記述例は、仮想マシン設定ファイル１４Ｂ中の＜cputune＞項目において、０番、１番、２番の「vcpu」で示された各仮想マシンの仮想ＣＰＵコア１２に対して、共有コア１１－Ｙに相当する７番の物理ＣＰＵコア１１を割り当てることを意味している。
　また、図９Ｃに示した仮想マシン設定ファイル１４Ｃの内容は、例えば図７に示したようなリソース割り当てを実現するための記述例である。すなわち、図９Ｃの記述例は、仮想マシン設定ファイル１４Ｃ中の＜cputune＞項目において、０番、１番、２番の「vcpu」で示された各仮想マシンの仮想ＣＰＵコア１２に対して、占有コア１１－Ｘに相当する１番、２番、３番の各物理ＣＰＵコア１１を割り当てることを意味している。
　一方、割り当てを変更した後の仮想マシン設定ファイル１４の内容の記述例を図１０Ａ及び図１０Ｂにそれぞれ示す。
　図１０Ａに示した仮想マシン設定ファイル１４Ｄの記述例は、例えば図３Ｂに示す割り当て状態のように、リソース割り当てを変更した後の、現用系ＡＣＴの仮想マシンに対するリソース割り当ての内容を表している。
　すなわち、図１０Ａの記述例では、仮想マシン設定ファイル１４Ｄ中の＜cputune＞項目において、０番、１番、２番の「vcpu」で示された各仮想マシンの仮想ＣＰＵコア１２に対して、占有コア１１－Ｘに相当する１番、２番、３番の独立した物理ＣＰＵコア１１を個別に割り当てることを意味している。
　図１０Ｂに示した仮想マシン設定ファイル１４Ｅの記述例は、例えば図３Ｂに示す割り当て状態のように、リソース割り当てを変更した後の、待機系ＳＢＹの仮想マシンに対するリソース割り当ての内容を表している。
　すなわち、図１０Ｂの記述例では、仮想マシン設定ファイル１４Ｅ中の＜cputune＞項目において、０番、１番、２番の「vcpu」で示された各仮想マシンの仮想ＣＰＵコア１２に対して、共有コア１１－Ｙに相当する７番、８番、９番の各物理ＣＰＵコア１１を割り当てることを意味している。なお、同じ１つの共有コア１１－Ｙを待機系ＳＢＹの複数又は全ての仮想ＣＰＵコア１２に割り当ててもよい。つまり、実際の物理リソースのキャパシティを超える仮想リソースを仮想マシンに割り当てること、すなわちオーバーコミットを実施することができる。
＜詳細なリソース割り当て動作の具体例＞
　リソース管理テーブルに従って各仮想マシンにリソースを割り当てる場合の動作例を図１１に示す。すなわち、図４中のステップＳ１６～Ｓ１８、図６中のステップＳ３６～Ｓ３８、図８中のステップＳ５６～Ｓ５８に相当する処理の詳細が図１１に示されている。したがって、リソース割当システム４０が図１１に示した動作を実行することにより、例えば図３Ｂ、図５Ｂに示すような望ましい状態にリソースの割り当てを変更することができる。図１１の動作について以下に説明する。
　リソース払出し制御部４３は、ステップＳ７１でリソース選定テーブルを作成し、ステップＳ７２で変数Ｘを１に初期化した後、ステップＳ７３以降の処理をループ状に繰り返し実行する。
　リソース払出し制御部４３は、ステップＳ７３で図１６に示したようなリソース管理テーブルＴＢ２から変数Ｘの値で特定される行のリソースを選択する。なお、リソース管理テーブルＴＢ２については後で説明する。
　リソース払出し制御部４３は、ステップＳ７４～Ｓ８４の間の処理を、処理対象の仮想ＣＰＵコア１２の数に相当する回数だけ繰り返し実行する。
　ステップＳ７５では、リソース払出し制御部４３は割当先の仮想マシンが現用系ＡＣＴの仮想マシン「Active VM」か否かを識別する。割当先が現用系ＡＣＴであればステップＳ７６に進み、待機系ＳＢＹであればステップＳ８０に進む。
　ステップＳ７６では、リソース払出し制御部４３は割り当てる物理ＣＰＵコア１１が「占有」状態か否かを識別し、「占有」状態であればステップＳ７７に進み、「占有」状態でなければステップＳ７９に進む。
　ステップＳ７７では、リソース払出し制御部４３は「多重率」から「使用率」を減算した結果が「要求使用率」以上か否かを識別し、この条件を満たす場合はステップＳ７８に進み、条件を満たさない場合はステップＳ７９に進む。
　ステップＳ７８では、リソース払出し制御部４３は、ステップＳ７１で作成したリソース選定テーブルの該当行の位置に、「割り当て可」を表す情報を書き込む。またステップＳ７９では、リソース払出し制御部４３はリソース選定テーブルの該当行の位置に「割り当て不可」を表す情報を書き込む。
　ステップＳ８０では、リソース払出し制御部４３は割り当てる物理ＣＰＵコア１１が「共有」状態か否かを識別し、「共有」状態であればステップＳ８１に進み、「共有」状態でなければステップＳ８３に進む。
　ステップＳ８１では、リソース払出し制御部４３は「多重率」から「使用率」を減算した結果が「要求使用率」以上か否かを識別し、この条件を満たす場合はステップＳ８２に進み、条件を満たさない場合はステップＳ８３に進む。
　ステップＳ８２では、リソース払出し制御部４３は、リソース選定テーブルの該当行の位置に、「割り当て可」を表す情報を書き込む。またステップＳ８３では、リソース払出し制御部４３はリソース選定テーブルの該当行の位置に「割り当て不可」を表す情報を書き込む。
　ステップＳ８５では、リソース払出し制御部４３がリソース管理テーブルＴＢ２の最後の行まで処理が完了したか否かを識別し、完了した場合はステップＳ８７に進む。完了してなければステップＳ８６に進み、変数Ｘの値をインクリメントしてからステップＳ７３に戻って上記の処理を繰り返す。
　ステップＳ８７では、リソース払出し制御部４３は、上記の処理の結果がハードウェア（ＨＷ）の条件を満たすか否かを識別し、条件を満たす場合はそのまま図１１の処理を終了する。ハードウェアの条件を満たさない場合は、リソース払出し制御部４３はステップＳ８８に進み、リソース選定テーブルに「割り当て不可」の情報を書き込む。ここでハードウェア条件を満たすとは、「anti-affinity」属性等のＨＷ割当条件を満足することを意味する。anti-affinity属性は、特定の仮想マシンが常に違う物理サーバで実行される必要があることを指定するものである。
＜障害発生時のフェイルオーバ（failover）動作＞
　システムの構成及びリソース割り当て状態の例を図１２Ａ～図１２Ｃに示す。図１２Ａは現用系ＡＣＴの仮想ネットワーク機能２１に障害が発生した直後の状態を表し、図１２Ｂはフェイルオーバの途中の状態を表し、図１２Ｃはフェイルオーバした後の状態を表す。
　例えば図１Ａに示した構成のように、仮想ネットワーク機能２１および２２が稼働している状況において、図１２Ａのように現用系ＡＣＴの仮想ネットワーク機能２１に障害１９が発生する場合がある。このシステムにおいては、冗長構成として、現用系ＡＣＴの仮想ネットワーク機能２１とペアになる待機系ＳＢＹの仮想ネットワーク機能２１Ｂが存在しているので、障害発生時でも現用系ＡＣＴから待機系ＳＢＹに切り替えて、すなわちフェイルオーバしてサービスの提供をそのまま継続することが可能である。
　但し、図１２Ａの構成において、仮想ネットワーク機能２１Ｂの仮想ＣＰＵコア１２には共有コア１１－Ｙが割り当てられているので、このままでは使用可能なリソースの能力が不足し、フェイルオーバした後で必要な性能が得られない。したがって、フェイルオーバの際にリソースの割り当てを変更する必要がある。
　図１２Ａの状態から、フェイルオーバおよびリソースの割り当ての変更を実施すると、例えば図１２Ｂの状態を経て図１２Ｃに示すような状態になる。すなわち、図１２Ｂの構成では、機能を停止した仮想ネットワーク機能２１の代わりになる、新たな現用系ＡＣＴの仮想ネットワーク機能２１Ｃが用意されている。また、仮想ネットワーク機能２１Ｃは現用系ＡＣＴなのでその仮想ＣＰＵコア１２にはハードウェアリソースとして占有コア１１－Ｘが割り当てられる。また、図１２Ｂの状態では別の仮想ネットワーク機能２２Ｂがまだ同じ占有コア１１－Ｘを共有している。そこで、例えば図１２Ｃに示すように仮想ネットワーク機能２２Ｂが他の共有コア１１－Ｙを使用するようにリソース割り当てを変更する。
　実際には、図１２Ａの状態から図１２Ｃの状態に切り替えるために、以下に示す各ステップＳｆ１～Ｓｆ４のような動作が実行される。
Ｓｆ１：障害１９の検出動作
　監視機能部４４が障害の発生を検出するか、又は該当する仮想ネットワーク機能ＶＮＦ１のアプリケーションソフトウェアが障害の発生を検出し、それをＶＭ管理部４２に通知する。
Ｓｆ２：フェイルオーバ動作
　待機系ＳＢＹの仮想ネットワーク機能ＶＮＦ１のアプリケーションソフトウェアの機能により、待機系ＳＢＹから現用系ＡＣＴの仮想マシンに切り替わる。この動作は、上記のステップＳｆ１の障害検出動作より先に発生する可能性もある。
Ｓｆ３：仮想マシンの起動状態確認およびＣＰＵリソース再割り当て動作
＿Ｓｆ３１：ＶＭ管理部４２が障害１９の発生した仮想マシンと冗長構成のペアを組んでいる他方の仮想マシンを冗長構成管理テーブルＴＢ１（図１５に示す）から特定してその起動状態を確認し、更にＣＰＵリソースの共有状況をリソース管理テーブルＴＢ２により確認する。例えば、リソース管理テーブルＴＢ２において「状態」が「共有」の場合には、図１２Ａのように現用系ＡＣＴで障害が発生したことをＶＭ管理部４２が確認できる。例えば図１２Ａの場合は、障害が発生した仮想ネットワーク機能２１とペアの仮想ネットワーク機能２１Ｂの仮想ＣＰＵコア１２に共有コア１１－Ｙが割り当てられているので、これを占有コア１１－Ｘに変更する必要がある。したがって、以下のステップＳｆ３１Ａ、Ｓｆ３１Ｂのいずれかを実行する。
＿＿Ｓｆ３１Ａ：現用系ＡＣＴに切り替えた仮想ネットワーク機能２１Ｂの仮想マシンに割り当てた共有コア１１－Ｙを共有している他の待機系ＳＢＹの仮想マシンを、この共有コア１１－Ｙの割当先から追い出して排除する。これにより、該当する共有コア１１－Ｙを新たな占有コア１１－Ｘとして仮想ネットワーク機能２１Ｂの仮想マシンがそのまま利用できる。
＿＿Ｓｆ３１Ｂ：新たにＣＰＵリソースを払い出し、物理ＣＰＵコア１１と仮想ＣＰＵコア１２とを１対１の関係でＣＰＵピニングにより固定的に占有するように、該当する仮想マシンの定義ファイルの内容を更新する。
＿Ｓｆ３２：上記ステップＳｆ３１Ａを実行した場合には、共有コア１１－Ｙから追い出した他の仮想マシンを使用可能な所定の状態に戻す必要がある。したがって、以下のステップＳｆ３２Ａ、Ｓｆ３２Ｂのいずれかを実行する。
＿＿Ｓｆ３２Ａ：該当する他の仮想マシンをサスペンドおよびシャットオフして、新たに待機系ＳＢＹの仮想マシンのためにＣＰＵリソースを払い出し、この仮想マシンの定義ファイルの内容を更新する。
＿＿Ｓｆ３２Ｂ：該当する他の仮想マシンを一度削除した後、再度該当する待機系ＳＢＹの仮想マシンを起動する。
Ｓｆ４：新たな待機系ＳＢＹの仮想マシンの起動および組み込み動作
　ＶＭ管理部４２がリソース払出し制御部４３に新たな待機系ＳＢＹの仮想マシンの起動を指示する。
　一方、待機系ＳＢＹの仮想マシンに障害が発生した場合には、フェイルオーバは不要なので、上記ステップＳｆ１、Ｓｆ３、及びＳｆ４のみを実行する。また、その場合のステップＳｆ３では次のように処理する。
　ＶＭ管理部４２が障害１９の発生した仮想マシンと冗長構成のペアを組んでいる他方の仮想マシンを冗長構成管理テーブルＴＢ１から特定してその起動状態を確認し、更にＣＰＵリソースの共有状況をリソース管理テーブルＴＢ２により確認する。例えば、リソース管理テーブルＴＢ２において「状態」が「占有」の場合には、待機系ＳＢＹで障害が発生したことをＶＭ管理部４２が確認できる。その場合は、リソースの再割り当ては行わない。
＜フェイルオーバの具体的な動作例－１＞
　障害発生時のフェイルオーバのための動作例－１を図１３に示す。すなわち、上記のステップＳｆ３１Ａをリソース割当システム４０が実行する場合の動作例が図１３に示されている。図１３の動作について以下に説明する。
　ステップＳ１０１で、監視機能部４４が障害１９の発生を検出する。例えば、正常時は現用系ＡＣＴと待機系ＳＢＹとの間で互いに通知されるハートビートの稼働情報を監視することで障害１９を検出できる。
　ステップＳ１０２で、ＶＭ管理部４２が、冗長構成管理テーブルＴＢ１を参照して、障害１９が発生した仮想マシンと冗長構成のペアになる正常な方の仮想マシンを特定する情報を抽出する。また、ステップＳ１０２で抽出した正常な仮想マシンの起動状態をＶＭ管理部４２がステップＳ１０３、Ｓ１０４で確認する。すなわち、該当する正常な仮想マシンの稼働状態がアクティブ状態（Active VM）か否かをステップＳ１０４で識別する。
　該当する正常な仮想マシンの稼働状態がアクティブ状態でない場合は、ステップＳ１０４からＳ１０５に進み、一定時間（Ｘ秒）のスリープ（Ｓｌｅｅｐ）により待機し、アクティブ状態になるまで待つ。
　該当する正常な仮想マシンの稼働状態がアクティブ状態になった場合には、ステップＳ１０６でリソース払出し制御部４３がリソース管理テーブルＴＢ２の内容を参照し、該当するリソースの「状態」が「共有」か否かを識別する。つまり、該当する仮想マシンの仮想ＣＰＵコア１２に割り当てられた物理ＣＰＵコア１１が共有コア１１－Ｙか否かを識別する。該当するリソースの「状態」が「共有」の場合はステップＳ１０７に進み、「共有」でない場合はステップＳ１１３に進む。
　ステップＳ１０７では、同じ物理ＣＰＵコア１１を共有している他の仮想マシンを、ＶＭ管理部４２がリソース管理テーブルＴＢ２上の「割当先」の情報により特定し、他の仮想マシンをサスペンドおよびシャットオフする。これにより、フェイルオーバにより新たな現用系ＡＣＴとして動作する仮想マシンに割り当てられた共有コア１１－Ｙの割当先から他の仮想マシンを追い出すことができ、この共有コア１１－Ｙを占有コア１１－Ｘとして使用できる。
　一方、ステップＳ１０７の処理により共有コア１１－Ｙの割当先から追い出した他の仮想マシンを使用可能な通常の状態に戻すために、リソース払出し制御部４３が各ステップＳ１０８～Ｓ１１２を実行する。
　ステップＳ１０８では、リソース抽出・選定部４３ｂが該当する仮想マシンに割り当て可能な物理ＣＰＵコア１１をリソースとして抽出する。また、ステップＳ１０９ではリソース抽出・選定部４３ｂが該当する仮想マシンに割り当てる適切な物理ＣＰＵコア１１を選定する。
　また、ステップＳ１０９の選定結果を反映するように、ステップＳ１１０でリソース払出し制御部４３が冗長構成管理テーブルＴＢ１およびリソース管理テーブルＴＢ２の内容を更新する。更に、ステップＳ１１１でリソース払出し制御部４３が仮想マシン設定ファイル１４の内容を更新する。
　また、ステップＳ１１１で更新された仮想マシン設定ファイル１４の内容を反映した状態で該当する仮想マシンが動作するように、ステップＳ１１２でリソース払出し制御部４３が該当する仮想マシンを再起動する。
　一方、障害１９が発生した仮想マシンが待機系ＳＢＹであった場合には、それとペアの現用系ＡＣＴの仮想マシンは現状のまま継続して利用できるので、フェイルオーバは不要である。但し、障害１９が発生した待機系ＳＢＹの仮想マシンの代わりを、これ以降の障害発生に備えて準備しておく必要がある。
　したがって、ステップＳ１１３で、ＶＭ管理部４２が待機系ＳＢＹとして動作可能な新規仮想マシン（Standby VM）を起動するための指示をリソース払出し制御部４３に与える。リソース払出し制御部４３は、ステップＳ１１４でＶＭ管理部４２からの指示に従い、待機系ＳＢＹとして動作可能な新規仮想マシンについて、所定の起動シーケンスを実行する。例えば、図４、図６、および図８のいずれかに示した動作を実行する。
＜フェイルオーバの具体的な動作例－２＞
　障害発生時のフェイルオーバのための動作例－２を図１４に示す。すなわち、上記のステップＳｆ３１Ｂをリソース割当システム４０が実行する場合の動作例が図１４に示されている。図１４の動作について以下に説明する。
　ステップＳ１２１で、監視機能部４４が障害１９の発生を検出する。例えば、正常時は現用系ＡＣＴと待機系ＳＢＹとの間で互いに通知されるハートビートの稼働情報を監視することで障害１９を検出できる。
　ステップＳ１２２で、ＶＭ管理部４２が、冗長構成管理テーブルＴＢ１を参照して、障害１９が発生した仮想マシンと冗長構成のペアになる正常な方の仮想マシンを特定する情報を抽出する。また、ステップＳ１２２で抽出した正常な仮想マシンの起動状態をＶＭ管理部４２がステップＳ１２３、Ｓ１２４で確認する。すなわち、該当する正常な仮想マシンの稼働状態がアクティブ状態（Active VM）か否かをステップＳ１２４で識別する。
　該当する正常な仮想マシンの稼働状態がアクティブ状態でない場合は、ステップＳ１２４からＳ１２５に進み、一定時間（Ｘ秒）のスリープ（Ｓｌｅｅｐ）により待機し、アクティブ状態になるまで待つ。
　該当する正常な仮想マシンの稼働状態がアクティブ状態になった場合には、ステップＳ１２６でリソース払出し制御部４３がリソース管理テーブルＴＢ２の内容を参照し、該当するリソースの「状態」が「共有」か否かを識別する。つまり、該当する仮想マシンの仮想ＣＰＵコア１２に割り当てられた物理ＣＰＵコア１１が共有コア１１－Ｙか否かを識別する。該当するリソースの「状態」が「共有」の場合はステップＳ１２７に進み、「共有」でない場合はステップＳ１３１に進む。
　ステップＳ１２７～Ｓ１３０では、フェイルオーバにより新たな現用系ＡＣＴとして稼働させる仮想マシンに対して、共有コア１１－Ｙの代わりに適切な占有コア１１－Ｘを割り当てるためのリソース割り当てをリソース払出し制御部４３が実行する。
　ステップＳ１２７では、リソース抽出・選定部４３ｂが該当する仮想マシンに割り当て可能な物理ＣＰＵコア１１をリソースとして抽出する。また、ステップＳ１２８ではリソース抽出・選定部４３ｂが該当する仮想マシンに割り当てる適切な物理ＣＰＵコア１１として占有コア１１－Ｘを選定する。
　また、ステップＳ１２８の選定結果を反映するように、ステップＳ１２９でリソース払出し制御部４３が冗長構成管理テーブルＴＢ１およびリソース管理テーブルＴＢ２の内容を更新する。更に、ステップＳ１３０でリソース払出し制御部４３が仮想マシン設定ファイル１４の内容を更新する。
　一方、障害１９が発生した仮想マシンが待機系ＳＢＹであった場合には、それとペアの現用系ＡＣＴの仮想マシンは現状のまま継続して利用できるので、フェイルオーバは不要である。但し、障害１９が発生した待機系ＳＢＹの仮想マシンの代わりを、これ以降の障害発生に備えて準備しておく必要がある。
　したがって、ステップＳ１３１で、ＶＭ管理部４２が待機系ＳＢＹとして動作可能な新規仮想マシン（Standby VM）を起動するための指示をリソース払出し制御部４３に与える。リソース払出し制御部４３は、ステップＳ１３２でＶＭ管理部４２からの指示に従い、待機系ＳＢＹとして動作可能な新規仮想マシンについて、所定の起動シーケンスを実行する。例えば、図４、図６、および図８のいずれかに示した動作を実行する。
＜管理テーブルの構成例＞
　冗長構成管理テーブルＴＢ１の構成例を図１５に示す。この冗長構成管理テーブルＴＢ１は、障害発生時に、障害の発生した仮想マシンと冗長構成のペアになるもう一方の仮想マシンを特定するために利用される。
　図１５に示した冗長構成管理テーブルＴＢ１は、仮想ネットワーク機能ＶＮＦのアプリケーションソフトウェア（Ａｐｐ）毎に、アプリケーションの識別子（Ａｐｐ ＩＤ）、仮想マシン番号（ＶＭ　Ｎｕｍｂｅｒ）、仮想マシン識別子（ＶＭ ＩＤ）、および仮想ＩＰアドレス（Ｖｉｒｔｕａｌ　ＩＰ）の情報を保持する領域を有している。
　なお、図１５の冗長構成管理テーブルＴＢ１において、仮想ＩＰアドレスの情報はなくてもよい。また、例えば仮想ＩＰアドレスの代わりに、所属する全ての仮想マシンのＩＰアドレスを管理することにより、冗長構成のペアになるもう一方の仮想マシンを把握可能である。
　図１５に示した例では、例えば１番目の仮想ネットワーク機能ＶＮＦ１については、仮想マシン識別子の項目に含まれている２つの情報「＃０１」、「＃０２」から、１番目の仮想マシンと２番目の仮想マシンとが冗長構成のペアとして割り当てられていることを把握できる。つまり、この場合は１番目の仮想マシンと２番目の仮想マシンの一方が現用系ＡＣＴになり、他方が待機系ＳＢＹになる。
　リソース管理テーブルＴＢ２の構成例を図１６に示す。このリソース管理テーブルＴＢ２は、各仮想マシンの仮想ＣＰＵコア１２に対する物理ＣＰＵコア１１の割り当て状況を管理するために利用される。
　図１６に示したリソース管理テーブルＴＢ２は、各物理リソース１０を示すハードウェア識別子（ＨＷ　Ｉｄ）、物理ＣＰＵコア１１のコア番号、多重率、使用率、状態、および割当先の各情報を保持する領域を有している。
　多重率とは、或る物理リソース１０が備える物理ＣＰＵコア１１の性能を基準として、各物理ＣＰＵコア１１の演算能力を示す指標である。ここでは、ハードウェア識別子が#0、コア番号が0の物理ＣＰＵコア１１が基準として選択されている。
　使用率とは、多重率で示される物理ＣＰＵコア１１の性能のうち、どれだけが使用されているかを示す指標である。
　状態とは、各物理ＣＰＵコア１１が、いずれかの仮想マシンによって占有されているか否かと、起動用として割り当てられているか否かを示すものである。図１６の例では、各物理リソース１０の物理ＣＰＵコア１１のうち１つが、起動用の専用CPUコアとして選択されている。
　割当先とは、各物理ＣＰＵコア１１が、いずれかの仮想マシンに割り当てられているかを示すものである。ここでは、割り当てられていないことを示す“－”と、“Host OS”と、各仮想マシンの各仮想ＣＰＵとが記載されている。
　なお、多重率、および使用率の情報は必要不可欠ではない。しかし、多重率および使用率の情報を利用することにより、待機系ＳＢＹの仮想マシンの多重度、すなわち、同一の物理ＣＰＵコア１１に何個の仮想ＣＰＵコア１２を割り当てるかを制御することが容易になる。また、多重度により、性能の異なるハードウェア間の性能の違いを吸収することが可能になる。
　図１６に示したリソース管理テーブルＴＢ２の例では、ハードウェア識別子が「＃０」、コア番号が「０」の物理ＣＰＵコア１１は、「起動用」の専用コア、すなわち起動用コア１１Ｂとして割り当てられている。また、ハードウェア識別子が「＃０」、コア番号が「１～３」の各物理ＣＰＵコア１１は、「占有」状態のコア、すなわち占有コア１１－Ｘとして割り当てられている。また、例えばハードウェア識別子が「＃０」、コア番号が「２」の物理ＣＰＵコア１１は、仮想マシン識別子が「＃０１」の０番の仮想ＣＰＵコア１２（ｖＣＰＵ０）に割り当てられている。
　また、ハードウェア識別子が「＃１」、コア番号が「１」の各物理ＣＰＵコア１１は、「共有」状態のコア、すなわち共有コア１１－Ｙとして割り当てられている。また、例えばハードウェア識別子が「＃１」、コア番号が「１」の物理ＣＰＵコア１１は、仮想マシン識別子が「＃０２」の０番の仮想ＣＰＵコア１２（ｖＣＰＵ０）、および仮想マシン識別子が「＃０４」の０番の仮想ＣＰＵコア１２（ｖＣＰＵ０）に、これらが共有する状態で割り当てられている。
　また、例えばハードウェア識別子が「＃１」、コア番号が「１」の物理ＣＰＵコア１１は、多重率が「１５０％」であるので、ハードウェア識別子が「＃０」の物理ＣＰＵコア１１と比べて１．５倍の性能比であることが分かる。また、例えばハードウェア識別子が「＃１」、コア番号が「１」の物理ＣＰＵコア１１は、使用率が「２０％」であるので、残りの１３０％の性能分のリソースを更に他の仮想マシンに割り当て可能な状態であることが分かる。
＜サービス提供システムの利点＞
　上述のサービス提供システムにおいては、稼働状態で例えば図１Ａに示したように待機系ＳＢＹの仮想ネットワーク機能２１Ｂ～２６Ｂの各仮想マシンの仮想ＣＰＵコア１２に対して、複数の仮想マシンで共有可能な物理ＣＰＵコア１１を割り当てることができる。したがって、通常は使用されない待機系ＳＢＹの仮想マシンに割り当てる物理リソースを減らし、システム全体のリソース利用効率を上げることができる。しかも、例えば図３Ａ、図３Ｂに示したように各仮想マシンを起動した後で物理リソースの割り当てを変更するので、状況の変化に対応して各物理リソースを効率よく割り当てることができる。
　また、例えば図３Ａに示したように、起動用コア１１Ｂを用いて各仮想マシンを起動し、その後で図３Ｂに示したように現用系ＡＣＴおよび待機系ＳＢＹの各仮想マシンのリソース割り当てを変更する場合には、システムの性能を安定化することができる。すなわち、仮想マシンの起動時には非常に大きな負荷がかかる可能性があり、既に稼働している他の仮想マシンの動作に影響を及ぼす可能性がある。しかし、仮想マシンの起動時に起動用コア１１Ｂのみを使用することにより、既に稼働している他の仮想マシンの物理ＣＰＵコア１１がこの負荷変動の影響を受けなくなる。
　また、例えば図５Ａに示したように共有コア１１－Ｙを用いて各仮想マシンを起動した後で、図５Ｂに示したように現用系ＡＣＴおよび待機系ＳＢＹの各仮想マシンのリソース割り当てを変更する場合には、システム全体のリソース利用効率を更に上げることができる。
　また、例えば図７に示したように占有コア１１－Ｘを用いて各仮想マシンを起動した後で、図５Ｂに示したように現用系ＡＣＴおよび待機系ＳＢＹの各仮想マシンのリソース割り当てを変更する場合には、最終的にリソース割り当てを完了するまでの所要時間を短縮できる。例えば図７に示した仮想ネットワーク機能２０の仮想マシンについては、リソース割り当てを変更しなくてもそのままサービスを開始できるので、リソース割り当ての変更に伴う遅延時間を削減できる。
　また、例えば図１２に示した障害１９の発生に伴いフェイルオーバを実施する際に、待機系ＳＢＹの仮想ネットワーク機能２１Ｂに割り当てられている共有コア１１－Ｙを「占有」に切り替えるようにリソース割り当てを変更することにより、フェイルオーバ後の性能保証が容易になる。
　更に、リソース割り当てを変更する際に、図１３に示した動作を実施して共有コア１１－Ｙから他の仮想マシンを追い出す場合には、フェイルオーバにより新たな現用系ＡＣＴになった仮想マシンに対してリソース割り当てを変更する必要がない。したがって、リソース割り当ての変更に伴う遅延時間を削減できる。
　また、リソース割り当てを変更する際に、図１４に示した動作を実施する場合には、共有コア１１－Ｙに多数の仮想マシンが割り当てられている場合であっても、リソース割り当ての変更を比較的少ない処理量で実現できる。
　なお、図２に示したリソース割当システム４０の各機能については、専用のハードウェアで実現することも可能であるし、システムを管理する汎用のコンピュータが実行するプログラムとして実現することもできる。
　１０，１０－１～１０－４　物理リソース（ハードウェア計算機資源）
　１１　物理ＣＰＵコア
　１１Ｂ　起動用コア
　１１－Ｘ　占有コア
　１１－Ｙ　共有コア
　１２　仮想ＣＰＵコア
　１３　リンク
　１４，１４Ａ，１４Ｂ，１４Ｃ，１４Ｄ，１４Ｅ　仮想マシン設定ファイル
　１９　障害
　２０，２１，２２，２３，２４，２５，２６　仮想ネットワーク機能
　２０Ｂ，２１Ｂ，２２Ｂ，２３Ｂ，２４Ｂ，２５Ｂ，２６Ｂ　仮想ネットワーク機能
　３１，３２，３３，３４　サーバ
　４０　リソース割当システム
　４１　リソース要求受付部
　４２　ＶＭ管理部（障害時制御部）
　４２ａ　ＶＭ情報取得部
　４２ｂ　リソース操作指示部
　４３　リソース払出し制御部（初期リソース割り当て部、リソース割り当て変更部）
　４３ａ　リソース管理部
　４３ｂ　リソース抽出・選定部
　４３ｃ　仮想マシン制御部
　４４　監視機能部
　４４ａ　ＶＭ監視機能部
　４４ｂ　リソース監視機能部
　４５　記憶部
　４５ａ　リソース情報リポジトリ
　４５ｂ　仮想マシンイメージリポジトリ
　５０　リソース要求部
　１００Ａ，１００Ｂ　サービス提供システム
　ＴＢ１　冗長構成管理テーブル
　ＴＢ２　リソース管理テーブル

Claims (8)

  1. 　所望のサービスを提供可能なアプリケーション機能を、互いにペアをなす第１仮想マシン及び第２仮想マシンにより構成し、少なくとも初期状態では前記第１仮想マシンをアクティブ状態、前記第２仮想マシンをスタンバイ状態に定め、アクティブ状態の前記第１仮想マシン又は前記第２仮想マシンを利用してサービスを提供するサービス提供システムであって、
    　前記第１仮想マシン及び前記第２仮想マシンに割り当て可能な複数のハードウェア計算機資源と、
    　前記第１仮想マシン及び前記第２仮想マシンを起動する際に、事前に定めた初期条件に従って前記複数のハードウェア計算機資源のいずれかを前記第１仮想マシン及び前記第２仮想マシンに割り当てる初期リソース割り当て部と、
    　少なくともサービスを開始する前に、前記第１仮想マシンに割り当てるハードウェア計算機資源は、前記第１仮想マシンの占有又は実行優先度が高い状態に定め、前記第２仮想マシンに割り当てるハードウェア計算機資源は、前記第２仮想マシンと他の仮想マシンとの共有が可能な状態に定めるリソース割り当て変更部と、
    　を備えたサービス提供システム。
  2. 　前記初期リソース割り当て部は、前記複数のハードウェア計算機資源の中から事前に定めた起動用コアを選択し、前記起動用コアを初期状態の前記第１仮想マシン及び前記第２仮想マシンに割り当て、
    　前記リソース割り当て変更部は、前記第１仮想マシン及び前記第２仮想マシンに対して計算機資源の割り当てを変更する、
    　請求項１に記載のサービス提供システム。
  3. 　前記初期リソース割り当て部は、前記複数のハードウェア計算機資源の中から複数の仮想マシンが共通に利用可能な共有コアを選択し、前記共有コアを初期状態の前記第１仮想マシン及び前記第２仮想マシンに割り当て、
    　前記リソース割り当て変更部は、前記第１仮想マシン及び前記第２仮想マシンに対して計算機資源の割り当てを変更する、
    　請求項１に記載のサービス提供システム。
  4. 　前記初期リソース割り当て部は、前記複数のハードウェア計算機資源の中から単一の仮想マシンの占有又は実行優先度が高い占有コアを選択し、前記占有コアを初期状態の前記第１仮想マシン及び前記第２仮想マシンに割り当て、
    　前記リソース割り当て変更部は、前記第１仮想マシンに対して計算機資源の割り当てを変更せず、且つ前記第２仮想マシンに対して計算機資源の割り当てを変更する、
    　請求項１に記載のサービス提供システム。
  5. 　アクティブ状態の前記第１仮想マシンにおける障害発生を検知し、前記第２仮想マシンに割り当てられている前記ハードウェア計算機資源が複数の仮想マシンで共有可能な共有コアである場合には、前記第２仮想マシン以外の他の仮想マシンを前記共有コアの割り当て先から排除する障害時制御部、
    　を備えた請求項１乃至請求項４のいずれか１項に記載のサービス提供システム。
  6. 　アクティブ状態の前記第１仮想マシンにおける障害発生を検知し、前記第２仮想マシンに割り当てられている前記ハードウェア計算機資源が複数の仮想マシンで共有可能な共有コアである場合には、前記複数のハードウェア計算機資源の中から占有又は優先利用可能な新たな占有コアを確保して前記第２仮想マシンに割り当てる障害時制御部、
    　を備えた請求項１乃至請求項４のいずれか１項に記載のサービス提供システム。
  7. 　所望のサービスを提供可能なアプリケーション機能を、互いにペアをなす第１仮想マシン及び第２仮想マシンにより構成し、少なくとも初期状態では前記第１仮想マシンをアクティブ状態、前記第２仮想マシンをスタンバイ状態に定め、アクティブ状態の前記第１仮想マシン又は前記第２仮想マシンを利用してサービスを提供するシステムを制御するための資源割り当て方法であって、
    　前記第１仮想マシン及び前記第２仮想マシンを起動する際に、事前に定めた初期条件に従って予め用意された複数のハードウェア計算機資源のいずれかを前記第１仮想マシン及び前記第２仮想マシンに割り当て、
    　少なくともサービスを開始する前に、前記第１仮想マシンに割り当てるハードウェア計算機資源は、前記第１仮想マシンの占有又は実行優先度が高い状態に定め、前記第２仮想マシンに割り当てるハードウェア計算機資源は、前記第２仮想マシンと他の仮想マシンとの共有が可能な状態に定める、
    　資源割り当て方法。
  8. 　所望のサービスを提供可能なアプリケーション機能を、互いにペアをなす第１仮想マシン及び第２仮想マシンにより構成し、少なくとも初期状態では前記第１仮想マシンをアクティブ状態、前記第２仮想マシンをスタンバイ状態に定め、アクティブ状態の前記第１仮想マシン又は前記第２仮想マシンを利用してサービスを提供するシステムを制御する計算機が実行可能な資源割り当てプログラムであって、
    　前記第１仮想マシン及び前記第２仮想マシンを起動する際に、事前に定めた初期条件に従って予め用意された複数のハードウェア計算機資源のいずれかを前記第１仮想マシン及び前記第２仮想マシンに割り当てる初期リソース割り当て手順と、
    　少なくともサービスを開始する前に、前記第１仮想マシンに割り当てるハードウェア計算機資源は、前記第１仮想マシンの占有又は実行優先度が高い状態に定め、前記第２仮想マシンに割り当てるハードウェア計算機資源は、前記第２仮想マシンと他の仮想マシンとの共有が可能な状態に定めるリソース割り当て変更手順と、
    　を有する資源割り当てプログラム。
PCT/JP2019/005325 2018-02-19 2019-02-14 サービス提供システム、資源割り当て方法、及び資源割り当てプログラム WO2019160030A1 (ja)

Priority Applications (1)

Application Number Priority Date Filing Date Title
US16/970,591 US11640314B2 (en) 2018-02-19 2019-02-14 Service provision system, resource allocation method, and resource allocation program

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
JP2018-026723 2018-02-19
JP2018026723A JP6840099B2 (ja) 2018-02-19 2018-02-19 サービス提供システム、資源割り当て方法、及び資源割り当てプログラム

Publications (1)

Publication Number Publication Date
WO2019160030A1 true WO2019160030A1 (ja) 2019-08-22

Family

ID=67619481

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2019/005325 WO2019160030A1 (ja) 2018-02-19 2019-02-14 サービス提供システム、資源割り当て方法、及び資源割り当てプログラム

Country Status (3)

Country Link
US (1) US11640314B2 (ja)
JP (1) JP6840099B2 (ja)
WO (1) WO2019160030A1 (ja)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN113032101A (zh) * 2021-03-31 2021-06-25 深信服科技股份有限公司 虚拟机的资源分配方法、服务器及计算机可读存储介质
JP7432916B2 (ja) 2020-02-10 2024-02-19 国立大学法人福井大学 複数ネットワークスライスの障害復旧システム、障害復旧方法及びバックアップ用ネットワークスライス作製プログラム

Families Citing this family (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11113115B2 (en) * 2019-08-28 2021-09-07 Adva Optical Networking Se Dynamic resource optimization
US20220342719A1 (en) * 2019-11-04 2022-10-27 NEC Laboratories Europe GmbH Autonomous virtual radio access network control
US11429424B2 (en) * 2020-07-22 2022-08-30 Vmware, Inc. Fine-grained application-aware latency optimization for virtual machines at runtime
JP7126534B2 (ja) * 2020-09-29 2022-08-26 株式会社日立製作所 計算機システム、リソース再割当方法
US11704609B2 (en) 2021-06-10 2023-07-18 Bank Of America Corporation System for automatically balancing anticipated infrastructure demands
US11252036B1 (en) 2021-06-10 2022-02-15 Bank Of America Corporation System for evaluating and tuning resources for anticipated demands
JP2023180849A (ja) 2022-06-10 2023-12-21 富士通株式会社 資源管理プログラム、資源管理方法、および資源管理装置

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2009524863A (ja) * 2006-02-28 2009-07-02 インテル・コーポレーション 多数コアプロセッサの信頼性強化
JP2011141609A (ja) * 2010-01-05 2011-07-21 Hitachi Ltd 計算機システム及びその可用化方法
JP2017027166A (ja) * 2015-07-16 2017-02-02 富士通株式会社 運用管理装置、運用管理プログラムおよび情報処理システム

Family Cites Families (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP4622474B2 (ja) 2004-11-17 2011-02-02 横河電機株式会社 フィールド機器及びこれを用いたシステム
JP2009110404A (ja) * 2007-10-31 2009-05-21 Toshiba Corp 仮想計算機システム及び同システムにおけるゲストｏｓスケジューリング方法
US8892916B2 (en) * 2008-08-06 2014-11-18 International Business Machines Corporation Dynamic core pool management
JP5773065B2 (ja) * 2012-03-19 2015-09-02 富士通株式会社 スケジューリングプログラム、マルチコアプロセッサシステム、およびスケジューリング方法

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2009524863A (ja) * 2006-02-28 2009-07-02 インテル・コーポレーション 多数コアプロセッサの信頼性強化
JP2011141609A (ja) * 2010-01-05 2011-07-21 Hitachi Ltd 計算機システム及びその可用化方法
JP2017027166A (ja) * 2015-07-16 2017-02-02 富士通株式会社 運用管理装置、運用管理プログラムおよび情報処理システム

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP7432916B2 (ja) 2020-02-10 2024-02-19 国立大学法人福井大学 複数ネットワークスライスの障害復旧システム、障害復旧方法及びバックアップ用ネットワークスライス作製プログラム
CN113032101A (zh) * 2021-03-31 2021-06-25 深信服科技股份有限公司 虚拟机的资源分配方法、服务器及计算机可读存储介质
CN113032101B (zh) * 2021-03-31 2023-12-29 深信服科技股份有限公司 虚拟机的资源分配方法、服务器及计算机可读存储介质

Also Published As

Publication number Publication date
US11640314B2 (en) 2023-05-02
JP6840099B2 (ja) 2021-03-10
JP2019144717A (ja) 2019-08-29
US20210117219A1 (en) 2021-04-22

Similar Documents

Publication Publication Date Title
WO2019160030A1 (ja) サービス提供システム、資源割り当て方法、及び資源割り当てプログラム
US11392400B2 (en) Enhanced migration of clusters based on data accessibility
US10050850B2 (en) Rack awareness data storage in a cluster of host computing devices
EP3252608B1 (en) Node system, server device, scaling control method, and program
US8909698B2 (en) Grid-enabled, service-oriented architecture for enabling high-speed computing applications
EP1763749B1 (en) Facilitating access to input/output resources via an i/o partition shared by multiple consumer partitions
US11740921B2 (en) Coordinated container scheduling for improved resource allocation in virtual computing environment
WO2012068867A1 (zh) 虚拟机管理系统及其使用方法
JP2007272263A (ja) 計算機の管理方法、計算機システム、及び管理プログラム
CN113382077B (zh) 微服务调度方法、装置、计算机设备和存储介质
EP3087483B1 (en) System and method for supporting asynchronous invocation in a distributed data grid
US9836322B1 (en) Methods and apparatus for virtualizing switch control plane engine
JPWO2007072544A1 (ja) 情報処理装置、計算機、リソース割り当て方法及びリソース割り当てプログラム
WO2017107483A1 (zh) 一种虚拟化网管文件下载负载均衡的方法及网管服务器
CN113886089A (zh) 一种任务处理方法、装置、系统、设备及介质
JP2007304845A (ja) 仮想計算機システムおよびソフトウェア更新方法
JP2008107966A (ja) 計算機システム
JP6543219B2 (ja) 仮想マシン配置装置およびリソース管理方法
EP4443291A1 (en) Cluster management method and device, and computing system
US12086643B2 (en) Critical workload management in container-based computing environment
JP6277069B2 (ja) 仮想機器管理装置、仮想機器管理方法及び仮想機器管理プログラム
WO2022130005A1 (en) Granular replica healing for distributed databases
US20240061698A1 (en) Managing the assignment of virtual machines to non-uniform memory access nodes
JP2010205207A (ja) ホストコンピュータ、マルチパスシステム、パス割当方法およびプログラム
JP6696947B2 (ja) 仮想マシンエミュレートシステム、仮想マシンエミュレート方法およびコンピュータプログラム

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: 19754878

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: 19754878

Country of ref document: EP

Kind code of ref document: A1