WO2014118961A1 - 仮想計算機管理プログラム,仮想計算機管理方法及び仮想計算機システム - Google Patents

仮想計算機管理プログラム,仮想計算機管理方法及び仮想計算機システム Download PDF

Info

Publication number
WO2014118961A1
WO2014118961A1 PCT/JP2013/052276 JP2013052276W WO2014118961A1 WO 2014118961 A1 WO2014118961 A1 WO 2014118961A1 JP 2013052276 W JP2013052276 W JP 2013052276W WO 2014118961 A1 WO2014118961 A1 WO 2014118961A1
Authority
WO
WIPO (PCT)
Prior art keywords
virtual machine
time correction
virtual
correction information
information
Prior art date
Application number
PCT/JP2013/052276
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 PCT/JP2013/052276 priority Critical patent/WO2014118961A1/ja
Priority to JP2014559452A priority patent/JP6102949B2/ja
Priority to EP13873624.4A priority patent/EP2953032A4/en
Publication of WO2014118961A1 publication Critical patent/WO2014118961A1/ja
Priority to US14/810,784 priority patent/US20150339150A1/en

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements 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/44Arrangements for executing specific programs
    • G06F9/455Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533Hypervisors; Virtual machine monitors
    • G06F9/45558Hypervisor-specific management and integration aspects
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements 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/44Arrangements for executing specific programs
    • G06F9/4401Bootstrapping
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements 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/44Arrangements for executing specific programs
    • G06F9/455Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533Hypervisors; Virtual machine monitors
    • G06F9/45558Hypervisor-specific management and integration aspects
    • G06F2009/45595Network integration; Enabling network access in virtual machine instances

Definitions

  • the present invention relates to a virtual machine management program, a virtual machine management method, and a virtual machine system.
  • a cloud service virtualizes a group of hardware such as a plurality of physical machines (or physical servers and physical computers) and physical storage in a data center based on a service contract with a cloud user, and the virtual machines (or virtual computers). ) And virtual storage infrastructure as a service via the network.
  • a hypervisor (or virtualization software) running on a physical machine allocates physical machine hardware resources to multiple virtual machines to operate, and services are provided by application programs installed on each virtual machine. Enables the provision of Therefore, a plurality of physical machines provided in the data center are created (or deployed) by allocating a plurality of virtual machines by the respective hypervisors, and the virtual machines are operated by starting the virtual machines. It becomes a state.
  • Standard (or default) setting information such as standard time information is set for each hypervisor operating on the physical machine. For this reason, when a virtual machine is newly created and started on a physical machine, the virtual machine is started with time information that is standard setting information.
  • cloud users who operate systems in multiple regions globally can be flexibly adapted to the convenience of cloud users' systems, regardless of the difference of physical machines in each region and the time zone of the cloud service providing region. There is a need to set the time.
  • the same time may be set for a plurality of virtual machines created and started on physical machines in cloud service centers in different time zones.
  • a virtual machine is added to a physical machine in a different time zone for reasons such as overloading. It may be necessary to set the same time as that of the system.
  • virtual machines with the same attributes such as system, network segment, SLB (Server Level Balancer) may need to be set in the same time zone.
  • SLB Server Level Balancer
  • an object of one embodiment is to provide a virtual computer management program, a virtual computer management method, and a virtual computer system that can set desired time correction information in a virtual computer generated in a physical computer.
  • a virtual machine management program for causing a computer to execute a virtual machine management process for managing a virtual machine operating on any of a plurality of physical computers
  • the virtual machine management process is: Extraction for extracting time correction information corresponding to the attribute of the virtual machine to be started from time correction registration information having time correction information corresponding to the attribute of the virtual machine when starting the virtual machine generated in the physical computer Process, A starting step of transmitting a start command for starting the virtual computer with the extracted time correction information to a physical computer that generates the virtual computer to be started.
  • the management server common to different hypervisors registers time correction information, a new virtual machine can be automatically started with the time correction information.
  • FIG. 4 is a diagram illustrating an example of a system (VSYS) information table, a virtual machine information table, and an SLB information table in a management information table 322 of the management server 3.
  • VSYS system
  • SLB SLB information table
  • FIG. 18 is a diagram showing a management information table that is referred to in the virtual machine generation and activation processing of FIG. 17. It is a figure which shows the production
  • FIG. 1 is a diagram illustrating an example of a physical machine, a hypervisor, and a virtual machine.
  • the physical machine PM has one or a plurality of CPUs, a memory, and an input / output device I / O.
  • the physical machine PM is connected to the hard disk HDD.
  • the hard disk HDD may be built in the physical machine PM or may be externally attached.
  • Hypervisor HV virtualization software
  • the hypervisor HV creates a new virtual machine VM
  • information about the virtual machine VM to be created for example, CPU clock frequency, memory capacity (GB), hard disk capacity (MB / sec, IOPS), and network bandwidth (Width (Gbps), etc.
  • This VM information file is stored in the hard disk HDD.
  • the hypervisor HV starts up after creating the virtual machine VM
  • the hypervisor HV starts up the virtual machine VM with the standard setting information of the hypervisor HV.
  • the virtual machine VM realizes a desired function by executing the OS and application program installed in each.
  • the hypervisor HV stores the changed setting information in the hypervisor VM information file in the hard disk HDD.
  • the virtual machine VM is started with the stored change setting information.
  • This setting information is, for example, time setting information.
  • FIG. 2 is a diagram showing an example in which the same time correction is performed in units of systems.
  • two virtual machines VM1 and VM2 are generated and started on the physical machine PM1.
  • a system VSYS that provides a desired service is constructed by these virtual machines VM1 and VM2.
  • the virtual machines VM1 and VM2 generated on the physical machine PM1 are initially started according to the standard time setting of the hypervisor. However, after starting, the virtual machines VM1 and VM2 are timed to the hypervisor.
  • the correction information T1 is set, and the time correction information T1 is set in the setting file that the hypervisor stores in the hard disk. In the figure, the time correction information T1 is set in the hypervisor setting file. This setting file is stored in the VM information file in the disk area of the physical machine PM1 of the hypervisor.
  • the new virtual machines VM3, VM4 are assigned to the physical machine PM1. May be generated and started on a different physical machine PM2, and new virtual machines VM5 and VM6 may be generated and started on a physical machine PM3 that is different from the physical machines PM1 and PM2.
  • the virtual machines VM3 and VM4 are activated by the standard time setting information TD3 of the hypervisor of the physical machine PM2
  • the virtual machines VM5 and VM6 are activated by the standard time setting information TD3 of the hypervisor of the physical machine PM3.
  • the time correction information T1 of the existing virtual machines VM1 and VM2, the standard time setting information TD2 of the new virtual machines VM3 and VM4, and the standard time setting information TD3 of the new virtual machines VM5 and VM6 are inconsistent. become.
  • the time settings of the virtual machines VM3-VM6 are different from the desired time information T1.
  • the operator of the system VSYS needs to set the time correction information T1 for the hypervisor for each new virtual machine VM3-VM6. Such a setting is usually done manually by the system VSYS operator.
  • FIG. 3 is a diagram illustrating an example in which the same time correction is performed in the request distribution destination virtual machine group under the server load balancer.
  • two virtual machines VM1 and VM2 are created and started on the physical machine PM1, one virtual machine VM3 is created and started on the physical machine PM2, and the server load balancer SLB functions on the physical machine PM4.
  • a virtual machine VM6 having is created and started.
  • the server load balancer SLB (VM6) distributes requests to the two virtual machines VM4 and VM7 under the SLB in a balanced manner.
  • the virtual machines VM4 and VM7 to which the request is distributed are created and started on the physical machines PM2 and PM3, respectively.
  • a system VSYS that provides a desired service is constructed by these virtual machines.
  • time correction information T1 is set for the hypervisors of the virtual machines VM1-VM3 and VM6, and time correction information T2 is set for the hypervisors of the SLB distribution destination virtual machines VM4 and VM7.
  • Fig. 3 (A) shows, for example, that the system VSYS provides a Web system, and only the virtual machines VM4 and VM7 that make up the HTTP server that accepts requests are corrected to the time T2 in the area where the Web service is provided. This is an example of setting.
  • FIG. 3B shows an example in which SLB (VM6) automatically scales out and adds a new virtual machine VM5 to the request distribution destination virtual machine group due to an increase in the number of requests.
  • SLB VM6
  • FIG. 4 is a diagram illustrating an example in which the same time correction is performed within the same network segment.
  • four virtual machines VM1 to VM4 are created and activated to configure the system VSYS.
  • a virtual machine VM1 that has the function of an HTTP server for the UK as a server to be published on the Internet has a time correction T2 in the UK set for its hypervisor
  • a virtual machine VM1 that has the function of a back office server in Japan -VM3 is an example in which Japanese time correction T1 is set for each hypervisor.
  • the virtual machine VM4 of the HTTP server that is published to the Internet is DMZ (DeMilitarized) Zone) is provided in a network segment located between the Internet and the internal network, while the virtual machines VM1-VM3 of the back office servers are provided in a secure network segment. In this way, it is assumed that the same time correction is performed within the same network segment and different time corrections are performed between different network segments.
  • the same attribute is used for each attribute of a virtual machine in the same system, a virtual machine in the same network segment, and an attribute of a request distribution destination virtual machine of SLB.
  • virtual machines with other attributes may require the same time setting.
  • a new virtual machine is created and started by the hypervisor of a single or different physical machine, it is started by the standard time setting information of each hypervisor. It is necessary to set the same time correction information in the hypervisor, and setting such time correction information is complicated.
  • time correction information is registered in advance for each attribute in the management server that manages the virtual machine, which is different from the hypervisor that manages the virtual machine information, and is stored in a database.
  • the management server starts a new virtual machine, it sends the start command having the registered time correction information to the physical machine of the virtual machine to start, and sends the standard time setting information to the hypervisor of the physical machine.
  • the virtual machine is started with the time correction information included in the start command. Therefore, when creating and starting a virtual machine on a single or different physical machine, the virtual machine is started with the time correction information registered in the management server. Therefore, it is necessary to unify the desired time correction information for each virtual machine attribute. There is no need to manually set the time correction after startup.
  • this embodiment will be described.
  • FIG. 5 is a diagram showing the overall configuration of the cloud system in the present embodiment.
  • a virtual machine group VM-G generated in hardware such as a physical machine PM
  • a cloud service portal site 2A for providing a management console to a cloud user
  • a management server 3 are provided.
  • the cloud user terminal 1 and the client terminal 6 of the cloud user service can be connected to the data center 8 via a network 7 such as the Internet or an intranet.
  • an API endpoint 2B for transmitting a command (a kind of API) directly from the cloud user terminal 1 to the management server 3 is also provided.
  • the virtual machine group (or virtual machine group) VM-G has a plurality of physical machines PM (or physical servers and physical computers), and each physical machine PM has a large capacity such as a CPU, memory (DRAM), and hard disk (HDD). It has a capacity memory and a network. Resources of the physical machine PM, which is hardware, are allocated to a plurality of virtual machines VM.
  • the cloud service portal site 2 and the management server 3 may be constructed by these virtual machines VM, for example.
  • a cloud service provided to a cloud user by a cloud system is a service that provides a base for constructing and operating a computer system, that is, an infrastructure such as a virtual machine or a network via the network 7.
  • the cloud user accesses the cloud service portal site 2 from the terminal 1 and uses the management console to specify the specifications required for the virtual machine, such as CPU clock frequency, memory capacity (GB), hard disk capacity (MB / sec, Select IOPS) and network bandwidth (Gbps) and conclude a cloud usage agreement for them.
  • the cloud user terminal 1 accesses the cloud service portal site 2 to monitor the operation status of the virtual machine and operate the operation of the virtual machine.
  • the management server 3 manages the physical machine PM in cooperation with the hypervisor (virtualization software) HV, and further generates and manages the virtual machine VM by assigning the physical machine hardware to the virtual machine VM.
  • the management server 3 includes a management information table including a time correction information table (or time correction registration information) (TB), a system (VSYS) information table (TB), a VM information table (TB), and an SLB information table (TB). 322.
  • the management information table 322 is also a time correction information table because it stores time correction information.
  • the management server 3 registers in the management information table 322 when a new virtual machine or system is created. In response to a request from the cloud user to set the time correction information of the virtual machine, the management server 3 registers the time correction information in the time correction information table TB, and the system (VSYS) information table TB, VM information Reflect in table TB and SLB information table TB.
  • VSYS system
  • VM information Reflect in table TB SLB information table TB.
  • the hypervisor HV is basic software that operates on a physical machine and operates a virtual machine by allocating the CPU, memory, hard disk, and network of the hardware physical machine PM in accordance with an instruction from the management server 3.
  • the virtual machine VM has an image file having an OS, middleware MW, application AP, database DB, etc. in its hard disk in addition to the physical machine PM which is the hardware described above.
  • the image file is written from the hard disk to the memory and the desired service is provided.
  • the client terminal 6 is a client terminal that receives a service of a system operated by a cloud user.
  • the client terminal 6 normally accesses the virtual machine VM of the cloud user via the network 7 and receives a service operated by the cloud user.
  • the management server 3 monitors the load state of the virtual machine VM in the system, and when it becomes overloaded, the hypervisor is passed through the physical machine to newly scale the virtual machine VM to the same physical machine or another physical machine. Instruct HV to create and start a new virtual machine. In response to an instruction from SBL to scale out a virtual machine that is a new distribution destination, the management server 3 generates and starts the new virtual machine on the same physical machine or another physical machine, To the hypervisor HV.
  • FIG. 6 is a diagram illustrating an example of the functions of the hypervisor.
  • the hypervisor HV operates on a physical machine, allocates resources of a hardware group such as a physical machine to the virtual machine VM, and operates the virtual machine VM. Therefore, the hypervisor HV includes, for example, a virtual machine generation unit 401 that generates a virtual machine, a virtual machine activation unit 402 that activates a virtual machine, a virtual machine shutdown unit 403 that shuts down a virtual machine, and a virtual machine that is activated
  • a virtual machine suspend unit 404 that suspends, that is, suspends, a virtual machine resume unit 405 that resumes, that is, resumes a suspended virtual machine, and a virtual machine operation information collection unit 406 that collects virtual machine operation information. .
  • the hypervisor HV includes a time correction processing unit 408 that corrects the time setting value at the time of activation in response to the setting of the time correction information from the management server 3. Then, the hypervisor HV saves a VM information file 409 that stores information about the generated virtual machine VM in a disk (not shown). The hypervisor HV refers to this VM information file and starts the virtual machine.
  • the virtual machine starting unit 402 executes the start command with time correction information received from the management server via the physical machine, starts the virtual machine with the time correction information, and stores the time correction information in the VM information file 409. Save to.
  • the above startup command is one of the APIs published by the hypervisor.
  • FIG. 7 is a diagram illustrating a configuration example of the management server.
  • the management server 3 includes software 300 and a storage unit 320 in addition to hardware such as a CPU (not shown).
  • the software 300 in the management server includes, for example, a cloud user management unit 301 that performs cloud user management such as billing processing for a cloud user who has concluded a cloud contract at the cloud service portal site 2A, and a cloud contract based on the cloud contract.
  • a virtual machine generation unit 302 that allocates hardware resources such as a physical machine to generate a virtual machine VM, a virtual machine management unit 303 that manages the virtual machine, and a virtual machine monitoring unit 304 that monitors the operation of the virtual machine are included.
  • the virtual machine generation unit 302 transmits a generation command having VM information to the hypervisor HV via, for example, a physical machine, and stores the VM information in a VM information file.
  • the software 300 further includes a virtual machine activation control unit 305 that instructs the hypervisor HV to start the virtual machine via the physical machine, and a virtual machine shutdown control unit 306 that instructs the hypervisor HV to shut down the activated virtual machine.
  • a virtual machine suspend control unit 307 for instructing the hypervisor HV to suspend the active virtual machine, a virtual machine resume control unit 308 for instructing the hypervisor HV to resume the virtual machine, and time correction information for the virtual machine are set.
  • a virtual machine time correction control unit 309, a virtual machine scale-out control unit 310 that instructs the hypervisor HV to scale out a new virtual machine, and the like.
  • the virtual machine activation control unit 305 When the virtual machine activation control unit 305 receives a virtual machine activation instruction via the management console 2A or the API endpoint 2B or when an autoscale command is activated by SLB or the like, the attribute of the virtual machine to be activated is determined. When the time correction information is registered, a start command with the time correction information is transmitted to the hypervisor via the physical machine.
  • the storage unit 320 in the management server includes, for example, a virtual machine operation information table 321 including virtual machine operation information reported from the hypervisor HV, and a system / virtual machine / SLB reflecting time correction information and time correction information.
  • a management information table 322 having an information table is included.
  • the management server 3 in the present embodiment responds to a request for registration of time correction information for a certain attribute of a virtual machine transmitted from a cloud service user terminal or the like before starting a new virtual machine.
  • a registration process for registering the first time correction information for the attribute in the time correction information table in 322 is performed.
  • time correction information corresponding to the attribute of the virtual machine to be started is extracted from time correction registration information having time correction information corresponding to the attribute of the virtual machine.
  • the start command for starting the virtual machine with the extracted time correction information is transmitted to the physical machine that generates the virtual machine to be started.
  • the management server causes the hypervisor to start the virtual machine with the time correction information by this start processing.
  • the above startup process includes a process of starting a virtual machine generated when the system is first constructed, and a process of starting an additional virtual machine generated in response to an autoscale command or the like on an already configured system.
  • the time correction information corresponding to a certain attribute is registered in the management server before startup, the registered time correction information is included as an option in the start command for the virtual machine belonging to that attribute.
  • the hypervisor HV starts the virtual machine with the time correction information. Once activated in such a manner, the hypervisor HV stores the time correction information in the VM information file, so that subsequent activation processing is activated with the time correction information.
  • FIG. 8 is a diagram showing an example of a time correction setting screen on the management console.
  • FIG. 8 shows a list of virtual machines and firewalls constituting the system. Here, it is assumed that a virtual machine or the like constituting the system has already been generated in a physical machine.
  • FIG. 8 is displayed as a time correction setting screen.
  • This screen is a state in which a certain system is selected and the time correction setting screen is displayed.
  • a check box 20 for performing time correction setting for all virtual machines in the system at once (1) a check box 20 for performing time correction setting for all virtual machines in the system at once; (2) A check box 21 for setting time correction individually for each virtual machine, network segment, and SLB, not for the system batch, (3) a check box 22 for performing time correction setting for all virtual machines in the DMZ that is one of the network segments; (4) a check box 24 for performing time correction setting for all virtual machines in the secure network that is one of the network segments; (5) Line 23 for performing time correction setting for the request distribution destination virtual machines of SLB1 in a batch; (6) In addition, a firewall and an individual virtual machine (WEB Server1, WEB Server2, AP (Application) Server, DB Server) shows the line for setting the time correction.
  • WEB Server1, WEB Server2, AP (Application) Server, DB Server shows the line for setting the time correction.
  • an area 26 for setting time correction information is provided on the right side so that it can be set in GMT notation.
  • the management server sends a start command that starts with the time correction information (GMT) set here to the hypervisor.
  • GTT time correction information
  • the management server transmits a start command for starting the virtual machine with the time correction information set here to the hypervisor via the physical machine.
  • a startup command that starts the virtual machine with the time correction information set by the management server is also sent to the virtual machine to which requests are distributed by SLB1 via the physical machine. Sent to the hypervisor.
  • FIG. 9 is a diagram illustrating a specific example of a target system controlled by the management server in the present embodiment.
  • System A has virtual machines VM1 and VM2 in DMZ-A and SECURE, respectively.
  • System B has two virtual machines VM3 and VM4 in DMZ-B, and then adds two virtual machines VM13 and VM14 by an autoscale command.
  • System C has virtual machine VM5 in DMZ-C, and then adds virtual machine VM15.
  • System D has SLB1 and virtual machines VM6 and VM7 to which requests are distributed from SLB1 in DMX-D, and then adds virtual machine VM16 to which requests are distributed from SLB1.
  • FIG. 10 is a diagram illustrating an example of a time correction information table in the management information table 322 of the management server 3.
  • the following time correction setting example is performed on the management server from the time correction setting screen in the management console shown in FIG. 8 for the system AD shown in the specific example of FIG. ing.
  • (1) Time correction setting to GMT-8 for system B (2) Time correction setting for GMT + 8 to DMZ-C of system C (3) Time of GMT + 9 to SLB1 of system D Correction setting (4)
  • the time correction settings of GMT + 9, GMT + 0, and GMT + 1 are also applied to the virtual machine machines VM1, VM2, and VM4, respectively.
  • FIG. 11 shows the system in the management information table 322 of the management server 3.
  • FIG. 1 It is a figure which shows the example of a (VSYS) information table, a virtual machine information table, and an SLB information table.
  • VSYS VSYS
  • the management server 3 registers the information in these tables. Furthermore, when the time correction information is set, the management server 3 reflects it in these tables.
  • the management server 3 starts after generating a virtual machine, it refers to these tables, and in addition to information on the newly started virtual machine, the time correction information set in the attribute of the virtual machine The start command with the option is sent to the hypervisor HV via the physical machine.
  • time correction information is registered in addition to the contractor ID and batch setting for all systems managed by the management server, and other system information not shown Has been.
  • time correction information GMT-8 is collectively set for the system B.
  • the virtual machine information table VM-TB in FIG. 11 includes information on all virtual machines managed by the management server, time correction information for each VM, the segment to which it belongs, and time correction information of the segment, SLB ID for distributing requests is registered.
  • VM time correction information is set for each of virtual machines VM1, VM2, and VM4
  • segment time correction information GMT + 8 is set for segment DMZ-C in virtual machine VM5
  • virtual machine VM6 VM7 is set to belong to the request distribution destination VM of SLB1.
  • SLB information table SLB-TB in FIG. 11 information not shown for all SLBs and SLB time correction information are registered.
  • SLB time correction information GMT + 9 is set only for SLB1.
  • FIG. 12 is a flowchart illustrating a virtual machine generation procedure.
  • the management server 3 receives the virtual machine generation command (YES in S10), the management server 3 sends a generation command with the VM information generated by the VM generation command as an option to the hypervisor HV on the physical machine that generates the virtual system ( S11).
  • This virtual machine (VM) generation command is received, for example, when a cloud user terminal generates a system from a management console or an API endpoint, or when an auto issue is issued by SLB to scale out a new virtual machine. Occurs when a scale command is received.
  • the hypervisor HV When the hypervisor HV receives the virtual machine creation command (S12), it saves the VM information included in the creation command in the hypervisor VM information file (S13). As described above, the VM information file is stored in the hard disk area for the hypervisor.
  • time correction information may be included in the generation command as described in step S11 of FIG.
  • the hypervisor stores the generated virtual machine information and time correction information together in the VM information file.
  • the management server may be able to start the virtual machine with the saved time correction information even if it is sent to the hypervisor without adding the time correction information to the start command.
  • FIG. 13 is a flowchart showing a procedure for starting a virtual machine.
  • the management server 3 receives the virtual machine start command (YES in S20)
  • the hypervisor HV starts a new virtual machine VM
  • the hypervisor HV of the virtual machine to be started is different from the previous start time (YES in S21) means that this is the first startup on that hypervisor, so the management server issues a startup command with the startup VM information and time correction value (or time correction information) as options on the hypervisor on the physical machine.
  • the hypervisor HV has already been started for the virtual machine VM to be started (NO in S21)
  • the management server will start with the startup VM information as an option if the time correction value has not changed since the previous startup.
  • the command is transmitted to the hypervisor HV on the physical machine (S22). If the time correction value has been changed since the previous start-up, the management server performs step S23 described above.
  • the hypervisor HV When the hypervisor HV receives the start command (YES in S24), if the start command specifies time correction as via S23 (YES in S25), the hypervisor HV selects the virtual machine based on the startup VM information and with the time correction value. The time information in the hypervisor VM information file is updated and saved (S27). On the other hand, if no time correction is specified in the start command as in S22 (YES in S25), the virtual machine is started based on the start VM information (S26). In this case, since it is not the first startup, the hypervisor HV starts the virtual machine with the time correction value stored in the VM information file in step S27 at the first startup.
  • the time correction information corresponding to the virtual machine attribute is registered in advance in the management machine management information table 322 so that the management machine can be managed when it is started for the first time after the virtual machine is generated.
  • a start command including time correction information in the information table 322 can be transmitted to the hypervisor on the physical machine to cause the hypervisor to start the virtual machine with the time correction information.
  • the management information table 322 is also a time correction information table that stores time correction information.
  • time correction information table is not necessarily registered in the management server. If stored in a storage area other than the management server, the management server refers to the time correction information table, extracts time correction information for the attribute of the virtual machine to be started, and starts the virtual machine with the time correction information. Can be sent to the physical machine.
  • FIG. 14 shows a case where a cloud service user manually generates and starts a virtual machine constituting a new system from the terminal (above ( It is a flowchart figure which shows the production
  • a new system is deployed from the management console 2A at the cloud user terminal 1 (S30).
  • the management console 2A commands the management server 3 to register the system (S31).
  • the management server 3 registers the system and the virtual machines constituting the system in the management information table 322, and sends a generation command with VM information as an option to the hypervisor HV on the physical machine ( S32).
  • the hypervisor HV saves the system VM information in the VM information file (S33).
  • the time correction information is registered from the management console 2A at the cloud user terminal 1 (S34).
  • the management console 2A transmits a time correction information registration command to the management server 3 (S35).
  • the management server 3 registers time correction information in the management information table.
  • the time correction information can be registered for each attribute (system, network segment, SLB, etc.) of the virtual machine.
  • the management console 2A transmits a virtual machine start command to the management server 3 (S38).
  • the management server 3 refers to the time correction information table in the management information table 322, extracts the time correction information applied to the start virtual machine in the table, and sets the time correction information.
  • a startup command with the startup VM information as an option (or parameter) is sent to the hypervisor HV on the physical machine (S39). This start command is one of the APIs of the hypervisor HV.
  • the hypervisor HV executes this start command, starts the virtual machine of the startup VM information with the time correction information, and saves the time correction information in the VM information file (S40). As a result, at the time of subsequent startup, the hypervisor starts the virtual machine with the time correction information stored in the VM information file.
  • the management console 2A transmits a virtual machine start command to the management server 3 ( S42).
  • the management server 3 refers to the time correction information table in the management information table 322, but the time correction information applied to the virtual machine to be started is not registered.
  • a start command with information as an option is transmitted to the hypervisor HV on the physical machine (S43). Therefore, the hypervisor HV starts the virtual machine of the startup VM information of this startup command at the standard time of the hypervisor (S44).
  • FIG. 15 is a flowchart showing a virtual machine generation procedure and a start procedure when a cloud service user manually generates and starts a virtual machine in the existing system manually from the terminal (in the case of (2) above). is there.
  • generation of the virtual machine of FIG. 14, registration of time correction information, and activation of the virtual machine are performed (S50).
  • an additional virtual machine is deployed or generated in the existing system from the management console 2A at the cloud user terminal 1 (S51).
  • the management console 2A instructs the management server 3 to register an additional virtual machine (S52).
  • the management server 3 registers a virtual machine to be additionally generated in the management information table 322, and transmits a generation command using the generated VM information as an option to the hypervisor HV on the physical machine (S53).
  • the hypervisor HV saves the generated VM information in the VM information file (S54).
  • the management console 2A transmits a virtual machine start command to the management server 3 (S56).
  • the management server 3 refers to the time correction information table in the management information table 322, extracts the time correction information applied to the start virtual machine in the table, and sets the time correction information.
  • a startup command with the startup VM information as an option (or parameter) is transmitted to the hypervisor HV on the physical machine (S57). Therefore, the hypervisor HV executes this start command, starts the virtual machine of the startup VM information with the time correction information, and saves the time correction information in the VM information file (S58).
  • the hypervisor HV starts a virtual machine for the first time, it saves the time correction information specified by the start command in the VM information file, and the subsequent startup of the same virtual machine is performed using the saved time correction information.
  • time correction information is registered corresponding to the attribute of the virtual machine
  • the hypervisor of which physical machine is the newly created virtual machine.
  • the management server 3 sends a startup command that uses the registered time correction information as an option to the hypervisor HV on the physical machine, so that it starts with the time correction information registered in the hypervisor HV. Can be controlled. Even if multiple virtual machines are created and started on different physical machines, the management server common to the different physical machines registers the time correction information, so it can be started with the set time correction information.
  • FIG. 16 is a flowchart showing a virtual machine generation procedure and a startup procedure when an additional virtual machine is generated and started by an autoscale command from SLB or the like (in the case of (3) above). Also in FIG. 16, as a premise, generation of the virtual machine of FIG. 14, registration of time correction information, and activation of the virtual machine are performed (S60).
  • an autoscale command is generated in the management server 3 (S61). For example, if the number of requests distributed by the SLB exceeds the threshold, or if the load on the virtual machine monitored by the monitoring server exceeds the threshold, the SLB or monitoring server (not shown) will execute the autoscale command of the management server. Start up.
  • This autoscale command includes information on the target system, segment, SLB, etc., and is sent from the SLB or monitoring server to the management server.
  • the management server 3 registers additional virtual machine information included in the autoscale command in the management information table (S62). Then, the management server 3 refers to the management information table 322, extracts the time correction information applied to the virtual machine to be generated and started, and generates the time correction value and the VM information to be generated / started as options. -Sends the start command to the hypervisor HV on the physical machine (S63).
  • the hypervisor In response to this, the hypervisor generates and starts a virtual machine to be generated / started by the generation / start command with the time correction value, and stores the time correction information and the virtual machine information to be generated / started in the VM information file. Save (S64).
  • the management server 3 sends a generation / start command to the hypervisor in response to the start of the autoscale command.
  • the management server 3 sends the generation command to the physical machine as shown in FIGS.
  • the startup command is sent to the hypervisor on the physical machine to start the virtual machine generated by the hypervisor with the time correction information. Good.
  • time correction information is associated with an attribute in advance in the management information table (time information table) 322 of the management server 3. Because it is registered, regardless of which physical machine the automatically generated virtual machine is generated on, it is newly generated on various physical machines by the start command with the time correction information sent by the management server 3 as an option The virtual machine can be started with the adapted time correction information.
  • FIG. 17 is a diagram illustrating virtual machine generation and activation processing when the system is collectively set as the first example.
  • FIG. 18 is a diagram showing a management information table referred to in the virtual machine generation and activation processing of FIG.
  • the first example is an example of the system B shown in FIG.
  • the management information table in FIG. 18 is the same as that in FIG. 11 and shows where to refer.
  • FIG. 17A shows an example in which the virtual machines VM3 and VM4 configuring the system VSYS-B are generated and started on the physical machine PM2.
  • a cloud user who intends to construct the system VSYS-B manually creates virtual machines VM3 and VM4 from the management console 2A on the terminal 1.
  • the cloud user cannot arbitrarily select a physical machine for generating the virtual machines VM3 and VM4, and an appropriate physical machine is selected by the management server 3 depending on the state of the physical machine group in the cloud center. . Therefore, it is unpredictable in which time zone the standard time TD2 of the physical machine PM2 will be.
  • the management server 3 selects the physical machine PM2 that generates the virtual machine of the system VSYS-B. Then, as shown in the flowchart of FIG. 14, the management server 3 registers the system VSYS-B including the virtual machines VM3 and VM4 in the management information table 322, and transmits a generation command to the hypervisor HV on the physical machine. Then, the hypervisor HV executes the generation command to save the information on the virtual machines VM3 and VM4 of the system VSYS-B in the hypervisor VM information file (S32, S33).
  • the management server 3 registers the time correction information GMT-8 in the information management table 322. (S36).
  • the management server 3 collects the system B in the virtual system information table VSYS-TB of the management information table 322 as shown in FIG. Detect that time correction information GMT-8 is registered, extract the time correction information GMT-8, and specify the virtual machine information to be started and the extracted time correction information GMT-8 as an option (parameter) Is sent to the hypervisor HV on the physical machine PM2 (S39).
  • the hypervisor HV of the physical machine PM2 starts the virtual machines VM3 and VM4 specified by the start command with the time correction information GMT-8, and saves the time correction information in the VM information file (S40). In this case, as shown in FIG.
  • the standard time of the hypervisor HV of the physical machine PM2 is TD2, but the time correction information registered in the management information table of the management server 3 for the system VSYS-B at once. Since the startup command with GMT-8 as an option is received, the startup command can be executed by the hypervisor to start the virtual machines VM3 and VM4 with the time correction information GMT-8. In the subsequent startup, the hypervisor starts the virtual machines VM3 and VM4 with the time correction information stored in the VM information file.
  • time correction information GMT + 4 is set for the virtual machine VM5, but batch time correction information GMT-8 for the system B is prioritized.
  • This logical priority does not particularly limit the present embodiment, and may not be prioritized. In this case, for example, setting of time correction information to the virtual machine VM5 is not permitted.
  • FIG. 17B shows an example in which virtual machines VM13 and VM14 are added to the system VSYS-B using virtual machines VM3 and VM4.
  • This addition of virtual machines VM13 and VM14 is performed manually by the cloud user of system VSYS-B, or for example, the processing amount of existing virtual machines VM3 and VM4 increases and the load on physical machine PM2 exceeds a certain time For example, when the management server 3 automatically activates an autoscale command.
  • the management server 3 selects the physical machine PM3 and manages the information of the virtual machines VM13 and VM14.
  • a generation command registered in the information table and using the VM information as an option is transmitted to the hypervisor on the physical machine PM3 (S53).
  • the hypervisor stores the VM information in a VM information file (S54).
  • the management server 3 refers to the management information table 322, and the time applied to the startup virtual machines VM13 and VM14 in the table.
  • the correction information GMT-8 is extracted, and a startup command with the time correction information and startup VM information as options is transmitted to the hypervisor HV on the physical machine (S57). Therefore, the hypervisor HV executes this start command, starts the virtual machines VM13 and VM14 of the startup VM information with the time correction information GMT-8, and saves the time correction information in the VM information file (S58).
  • the management server 3 registers the virtual machines VM13 and VM14 in the management information table according to the flowchart of FIG. 16, and generates / starts a command with the virtual machine information and time correction information GMT-8 as options.
  • FIG. 19 is a diagram illustrating virtual machine generation and activation processing in the case where the network segments as the second example are collectively set.
  • FIG. 20 is a diagram showing a management information table referred to in the virtual machine generation and activation processing of FIG.
  • the second example is an example of the system C shown in FIG.
  • the management information table in FIG. 20 is the same as that in FIG. 11 and shows where to refer.
  • FIG. 19A shows an example in which the virtual machine VM5 in DMZ-C in the system VSYS-C is generated and started on the physical machine PM4.
  • a cloud user who intends to construct the system VSYS-C manually creates a virtual machine VM5 on the terminal 1 from the management console 2A.
  • the cloud user cannot arbitrarily select a physical machine for generating the virtual machine VM5, and an appropriate physical machine is selected by the management server 3 depending on the state of the physical machine group in the cloud center. Therefore, it is unpredictable which time zone the standard time TD4 of the physical machine PM4 will be.
  • the management server 3 selects the physical machine PM4 that generates the virtual machine of the system VSYS-C, and the system VSYS including the virtual machines VM3 and VM4 in the management information table 322. -B is registered, a generation command is transmitted to the hypervisor HV on the physical machine, and the hypervisor HV executes the generation command and saves the information of the virtual machine VM5 in the VM information file (S32, S33).
  • the management server 3 sets the time correction information.
  • Information GMT + 8 is registered in the information management table 322 (S36).
  • the management server 3 searches the management information table 322 as shown in FIG.
  • the time correction information is not registered for the system C all at once in the virtual system information table VSYS-TB, and the virtual machine VM5 is assigned to the network segment DMZ- in the virtual machine information table VM-TB. It belongs to C, and it is detected that time correction information GMT + 8 is set in DMZ-C. Therefore, the management server 3 extracts the time correction information GMT + 8 and sends a start command with the virtual machine information to be started and the extracted time correction information GMT + 8 as options to the hypervisor HV on the physical machine PM4. (S39). By executing this, the hypervisor HV of the physical machine PM4 starts the virtual machine VM5 specified by the start command with the time correction information GMT + 8, and saves the time correction information in the VM information file (S40).
  • FIG. 19B shows an example in which a virtual machine VM15 is added to DMZ-C in the system VSYS-C.
  • the reason for adding is the same as in the first example of FIG.
  • the management server 3 selects the physical machine PM5 and registers the information of the virtual machine VM15 in the management information table. Then, a generation command including the VM information as an option is transmitted to the hypervisor on the physical machine PM5, and the hypervisor is saved in the VM information file (S53, S54).
  • the management server 3 refers to the management information table 322, and time correction information GMT + applied to the started virtual machine VM15 in the table. 8 is extracted, and the startup command with the time correction information and startup VM information as options is sent to the hypervisor HV on the physical machine, and the startup VM information virtual machine with the startup command time correction information GMT + 8 is sent to the hypervisor HV
  • the VM 15 is activated and the time correction information is saved in the VM information file (S57, S58).
  • registration of the virtual machine VM15 is omitted, but it is assumed that it is registered in the same manner as the virtual machine VM5.
  • the management server 3 registers the virtual machine VM15 in the management information table according to the flowchart of FIG. 16, and selects a generation / startup command with the virtual machine information and time correction information GMT + 8 as options. Sent to the hypervisor on the physical machine PM5, saved to the hypervisor in the VM information file of the virtual machine VM15, started with the time correction information GMT + 8, and saved in the VM information file of the time correction information GMT + 8 (S62, S63, S64).
  • FIG. 21 is a diagram illustrating virtual machine generation and activation processing when batch setting is performed in units of SLBs as a third example.
  • FIG. 22 is a diagram showing a management information table referred to in the virtual machine generation and activation processing of FIG.
  • the third example is an example of the system D shown in FIG.
  • the management information table in FIG. 22 is the same as that in FIG. 11 and indicates where to refer.
  • FIG. 21A shows an example in which virtual machines VM6 and VM7 (a group of virtual machines under SLB1) to which requests are distributed by SLB1 in the system VSYS-D are generated and started on the physical machine PM6.
  • VM6 and VM7 a group of virtual machines under SLB1 to which requests are distributed by SLB1 in the system VSYS-D are generated and started on the physical machine PM6.
  • a cloud user who wants to build the system VSYS-D manually creates virtual machines VM6 and VM7 from the management console 2A.
  • the cloud user cannot arbitrarily select a physical machine for generating the virtual machines VM6 and VM7, and an appropriate physical machine is selected by the management server 3 depending on the state of the physical machine group in the cloud center. . Therefore, it is unpredictable in which time zone the standard time TD6 of the physical machine PM6 will be.
  • the physical machine PM6 generated by the management server 3 is determined as described in the flowchart of FIG.
  • the virtual machines VM6 and VM7 are registered in the management information table 322, a generation command with the VM information as an option is transmitted to the hypervisor on the physical machine PM6, and the hypervisor is saved in a VM information file (S32, S33).
  • the management server 3 registers the time correction information GMT + 9 for the SLB 1 in the management information table 322 (S36).
  • the management server 3 refers to the management information table 322 and the time applied to the starting virtual machines VM6 and VM7 in the table.
  • the correction information GMT + 9 is extracted.
  • the virtual machines VM6 and VM7 are referred to as SLB1 by referring to the virtual system information table VSYS-TB, the virtual machine information table VM-TB, and the SLB information table SLB-TB in the management information table 322 in order. It is detected that it belongs and time correction information GMT + 9 is registered.
  • the management server 3 sends a start command with the time correction information and the start VM information as options to the hypervisor HV on the physical machine, and the start VM time update information GMT + 9 is sent to the hypervisor HV.
  • the virtual machines VM6 and VM7 are activated and the time correction information is saved in the VM information file (S39, S40). In this way, the virtual machines VM6 and VM7 can be started with the time correction information GMT + 9 registered in the management server different from the hypervisor standard time TD6. In the next and subsequent startups, the virtual machines VM6 and VM7 are started with the time correction information GMT + 9 saved by the hypervisor in the VM information file.
  • SLB1 in the system VSYS-D is an example in which the virtual machine VM16 is added by an autoscale command. That is, in this example, the management server 3 automatically adds the virtual machine VM16 by starting the autoscale command of the management server 3 when the total number of requests of the SLB1 exceeds the threshold for a certain time or more.
  • the management server 3 registers the virtual machine VM16 in the management information table, searches the management information table 322, and corrects the time correction information GMT + for SLB1 to which the virtual machine VM16 belongs. Detect 9 However, although the virtual machine VM16 is omitted in the management information table of FIG. 22, it is assumed that it is registered in the same manner as VM6 and VM7. Then, the management server 3 sends a generation / start command with the virtual machine information and time correction information GMT + 9 as options to the hypervisor HV on the selected physical machine PM7, and sends the VM of the virtual machine VM16 to the hypervisor. Save to the information file, start with the time correction information GMT + 9, and save the time correction information GMT + 8 to the VM information file (S62, S63, S64).
  • the time correction information for the virtual machine attributes is registered in the management information table of the management server 3 to be generated on the hypervisor on a different physical machine.
  • the plurality of virtual machines that have been registered can be started up with the registered time correction information at the first startup time. Since the hypervisor saves the time correction information activated first in the VM information file, the second and subsequent activations can be activated with the same time correction information.
  • a new virtual machine to be generated and started by registering time correction information of the management server and sending a start command using the management server as an option to the hypervisor on the physical machine is used as the time correction information. It can be started and does not require manual time correction settings for the virtual machine after startup.
  • FIG. 23 is a diagram illustrating an example in which virtual machines belonging to the same attribute are activated by registered time correction information.
  • virtual machines VM are generated and started on two different physical machines PM1 and PM2.
  • system B four virtual machines VM are created and started across two physical machines PM1 and PM2. Since the time correction information GMT-B is registered in a batch with respect to the system B, all four virtual machines VM are started with the same time correction information GMT-B in the first start operation. Since the time correction information GMT-B is stored in the hypervisor VM information file, the hypervisor is stored in the VM information file if the startup command does not include other time correction information as an option even after the second time. The virtual machine is started with the time correction information GMT-B.
  • system D four virtual machines VM are generated and started across two physical machines PM1 and PM2. Of the four virtual machines VM, three virtual machines VM belong to the same SLB1. Since the time correction information GMT-D is registered at once for the SLB 1 of the system D, the three virtual machines VM are all started up with the same time correction information GMT-D in the first startup operation. Since the time correction information GMT-D is stored in the hypervisor VM information file, the hypervisor starts the virtual machine with the time correction information GMT-D stored in the VM information file after the second time.
  • FIG. 24 is a diagram for explaining migration in the case of the management server in the present embodiment.
  • FIG. 25 is a flowchart showing migration processing.
  • FIG. 24 shows that the virtual machine VM1 generated and started on the physical machine PM1 is migrated to a different physical machine PM2.
  • the management server 3 commands the hypervisor HV1 of the physical machine PM1 to perform migration.
  • the hypervisor HV1 In response, the hypervisor HV1 generates the transfer destination virtual machine VM2 in the hypervisor HV2 of the transfer destination physical machine PM2, and secures a memory area (S70). Then, the hypervisor HV1 transfers and copies the memory contents of the transfer source virtual machine VM1 to the memory of the transfer destination virtual machine VM2 (S71). When the transfer of the memory contents is completed, the hypervisor HV1 transfers and copies the register value (context) in the CPU of the transfer source virtual machine VM1 to the register in the CPU of the transfer destination virtual machine VM2 (S72).
  • the hypervisor HV1 suspends the transfer source virtual machine VM1 and resumes the transfer destination virtual machine VM2 (S73, S74).
  • the transfer destination virtual machine VM2 is resumed by the memory information and context of the transfer source virtual machine VM1
  • the transfer destination virtual machine VM2 is resumed by the time correction information of the transfer source virtual machine VM1. This completes the migration.
  • the transfer destination virtual machine VM2 is shut down for some reason (S75).
  • the time correction information set by the management server 3 for the attribute of the transfer source virtual machine VM1 is extracted, and the time correction information is set as an option. Is sent to the hypervisor HV2, and as a result, the transfer destination virtual machine VM2 is started with the time correction information.
  • the management server of this embodiment can be started with the same time correction information by registering the time correction information in step 3 and issuing a start command using the time correction information as an option.

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Computer Security & Cryptography (AREA)
  • Stored Programmes (AREA)
  • Computer And Data Communications (AREA)

Abstract

 物理計算機にかかわらずある属性の仮想計算機をその属性に対する時刻補正情報で自動的に起動させる。複数の物理計算機上のいずれかで動作する仮想計算機を管理する仮想計算機管理処理をコンピュータに実行させる仮想計算機管理プログラムであって,仮想計算機管理処理は,物理計算機に生成される仮想計算機を起動する場合,仮想計算機の属性に対応する時刻補正情報を有する時刻補正登録情報から,起動対象の仮想計算機の属性に対応する時刻補正情報を抽出する抽出工程と,起動対象の仮想計算機を生成する物理計算機に,抽出した時刻補正情報で仮想計算機を起動させる起動コマンドを送信する起動工程とを有する。

Description

仮想計算機管理プログラム,仮想計算機管理方法及び仮想計算機システム
 本発明は,仮想計算機管理プログラム,仮想計算機管理方法及び仮想計算機システムに関する。
 クラウドサービスは,データセンタ内の複数の物理マシン(または物理サーバ,物理計算機)や物理ストレージなどのハードウエア群を,クラウド利用者とのサービス契約に基づいて仮想化し,その仮想マシン(または仮想計算機)や仮想ストレージ等のインフラをネットワーク経由のサービスとしてクラウド利用者に提供する。
 このようなクラウドサービスでは,物理マシン上で動作するハイパバイザ(または仮想化ソフトウエア)が物理マシンのハードウエアリソースを複数の仮想マシンに割り当てて動作させ,各仮想マシンにインストールされたアプリケーションプログラムによるサービスの提供を可能にする。したがって,データセンタに設けられた複数の物理マシンには,それぞれ,それぞれのハイパバイザにより複数の仮想マシンが割り当てられることで生成(または配備)され,その仮想マシンを起動することで,仮想マシンが動作状態になる。
 物理マシン上で動作するハイパバイザには,それぞれ標準の(またはデフォルトの)設定情報,例えば標準時刻情報が設定されている。そのため,新たに仮想マシンを物理マシン上に生成し起動すると,仮想マシンは,その標準設定情報である時刻情報で起動される。
特開平11-015558号公報
 一方で,グローバルに複数の地域でシステムを運用しているクラウド利用者は,地域ごとの物理マシンの差異やクラウドサービス提供地域のタイムゾーンにとらわれずに,クラウド利用者のシステムの都合で柔軟に時刻設定をすることが求められている。
 たとえば,異なるタイムゾーンのクラウドサービスセンタ内の物理マシン上にそれぞれ生成・起動した複数の仮想マシンに,同じ時刻設定を行う場合がある。または,あるタイムゾーンのクラウドサービスセンタ内の物理マシン上に生成・起動済みの仮想マシンによるシステムにおいて,過負荷状態解消などの理由で,異なるタイムゾーンの物理マシン上に仮想マシンを追加し,既存のシステムの設定時刻と同じ時刻設定を行わなければならない場合がある。
 しかしながら,上記の場合,前述したとおり,新たに仮想マシンを物理マシン上に生成・起動すると,ハイパバイザの標準時刻情報で起動されてしまう。そのため,クラウド利用者は,起動後に,仮想マシン毎にハイパバイザに所望の時刻補正情報の設定を手動にて行わなければならない。
 さらに,例えばシステム,ネットワークセグメント,SLB(Server Level Balancer)などの同じ属性の仮想マシンには,同じタイムゾーンの時刻設定をすることが必要な場合がある。その場合に,オートスケールによる新規の仮想マシンの生成・起動が発生すると,既存の仮想マシンのタイムゾーンとは異なるタイムゾーンの物理マシン上に新規の仮想マシンが生成された場合,前述のとおり,手動で仮想マシンの属性に応じた時刻補正情報の設定が必要になる。
 また,新規の複数の仮想マシンがそれぞれ異なる標準時刻情報で起動された場合,起動工程中に何らかの不具合が発生した場合,各仮想マシンの動作履歴情報の時間情報が整合していないので,不具合解析に支障を来す。
 そこで,一つの実施の形態の目的は,物理計算機に生成する仮想計算機に所望の時刻補正情報設定を行うことができる仮想計算機管理プログラム,仮想計算機管理方法及び仮想計算機システムを提供することにある。
 実施の形態の一つの側面によれば,複数の物理計算機上のいずれかで動作する仮想計算機を管理する仮想計算機管理処理をコンピュータに実行させる仮想計算機管理プログラムであって,
 前記仮想計算機管理処理は,
 前記物理計算機に生成される仮想計算機を起動する場合,仮想計算機の属性に対応する時刻補正情報を有する時刻補正登録情報から,前記起動対象の仮想計算機の属性に対応する時刻補正情報を抽出する抽出工程と,
 前記起動対象の仮想計算機を生成する物理計算機に,前記抽出した時刻補正情報で仮想計算機を起動させる起動コマンドを送信する起動工程とを有する。
 実施の形態によれば,異なるハイパバイザに共通の管理サーバが時刻補正情報を登録しているので,その時刻補正情報で新規の仮想計算機を自動的に起動することができる。
物理マシンとハイパバイザと仮想マシンの一例を示す図である。 システム単位で同じ時刻補正を行う例を示す図である。 サーバロードバランサのリクエスト振り分け先仮想マシン群で同じ時刻補正を行う例を示す図である。 同じネットワークセグメント内で同じ時刻補正を行う例を示す図である。 本実施の形態におけるクラウドシステムの全体構成を示す図である。 ハイパバイザが有する機能の一例を示す図である。 管理サーバの構成例を示す図である。 管理コンソールでの時刻補正設定画面の一例を示す図である。 本実施の形態において,管理サーバが制御する対象のシステムの具体例を示す図である。 管理サーバ3の管理情報テーブル322内の時刻補正情報テーブルの例を示す図である。 管理サーバ3の管理情報テーブル322内のシステム(VSYS)情報テーブル,仮想マシン情報テーブル,SLB情報テーブルの例を示す図である。 仮想マシンの生成手順を示すフローチャート図である。 仮想マシンの起動手順を示すフローチャート図である。 クラウドサービス利用者が端末から手動で新たなシステムを構成する仮想マシンを生成し起動する場合(上記(1)の場合)の仮想マシンの生成手順と起動手順を示すフローチャート図である。 クラウドサービス利用者が端末から手動で既存システムに更に追加的に仮想マシンを生成し起動する場合(上記(2)の場合)の仮想マシンの生成手順と起動手順を示すフローチャート図である。 SLBなどからのオートスケールコマンドにより追加の仮想マシンを生成し起動する場合(上記(3)の場合)の仮想マシンの生成手順と起動手順を示すフローチャート図である。 第1の例であるシステム一括設定されている場合の仮想マシンの生成と起動処理を示す図である。 図17の仮想マシンの生成と起動処理において参照される管理情報テーブルを示す図である。 第2の例であるネットワークセグメントで一括設定されている場合の仮想マシンの生成と起動処理を示す図である。 図19の仮想マシンの生成と起動処理において参照される管理情報テーブルを示す図である。 第3の例であるSLB単位で一括設定されている場合の仮想マシンの生成と起動処理を示す図である。 図21の仮想マシンの生成と起動処理において参照される管理情報テーブルを示す図である。 登録した時刻補正情報により同じ属性に属する仮想マシンが起動された例を示す図である。 本実施の形態における管理サーバの場合のマイグレーションを説明する図である。 マイグレーションの処理を示すフローチャート図である。
 [物理マシンとハイパバイザと仮想マシン]
 図1は,物理マシンとハイパバイザと仮想マシンの一例を示す図である。物理マシンPMは,単数若しくは複数のCPUと,メモリと,入出力装置I/Oとを有する。また,物理マシンPMは,ハードディスクHDDと接続されている。ハードディスクHDDは,物理マシンPM内に内蔵されてもよくまたは外付けでもよい。
 ハイパバイザHV(仮想化ソフトウエア)は,複数のCPUとメモリとI/O等の物理マシンPMのリソースを仮想化して割り当てることにより,物理マシン上で複数の仮想マシンVMを動作させる。したがって,生成できる仮想マシンVMの数は物理マシンPMの数やCPUの数に依存しない。
 ハイパバイザHVは,新規の仮想マシンVMを生成するとき,生成する仮想マシンVMの情報(例えばCPUのクロック周波数,メモリの容量(GB),ハードディスクの容量(MB/sec,IOPS),及びネットワークの帯域幅(Gbps)など)を,ハイパバイザHVのVM情報ファイルに保存する。このVM情報ファイルは,ハードディスクHDDに記憶される。
 ハイパバイザHVは,仮想マシンVMを生成した後,起動する時に,ハイパバイザHVが有している標準の設定情報で仮想マシンVMを起動する。そして,仮想マシンVMは,それぞれにインストールされたOSとアプリケーションプログラムを実行することにより,所望の機能を実現する。仮想マシン起動後に,ハイパバイザHVに対して仮想マシンの設定情報を変更すると,ハイパバイザHVは,変更された設定情報をハードディスクHDD内のハイパバイザのVM情報ファイルに記憶し,シャットダウン後の再起動時は,その記憶された変更設定情報で仮想マシンVMを起動する。この設定情報は,例えば時刻設定情報などである。
 このことは,ウインドウズOS(ウインドウズは登録商標)の物理マシンにおいても同様である。すなわち,物理マシンを最初に起動するとBIOSの標準時刻情報で起動される。そして,起動後に,OS上で標準時刻情報を補正または変更すると,その時刻補正情報がBIOSに記憶される。そして,次回の起動時には,OSがBIOSの時刻補正情報を読み出してその補正時刻で起動するので,起動の度に時刻補正を行う必要はない。
 [時刻補正設定の必要性]
 しかしながら,単一のまたは複数の物理マシンに生成される複数の仮想マシンで仮想システムを構築する場合,システムの都合によりそれら複数の仮想マシンを同じ時刻に設定する必要がある場合がある。異なる物理マシンに生成される複数の仮想マシンは,最初の起動時に各物理マシンのハイパバイザの標準時刻情報で起動されるため,時刻情報が不統一になるまたは所望の時刻情報と異なってしまうという不都合が生じる。そのため,仮想マシンの起動後に,システム運用者が手動で複数の仮想マシンに対して同じ時刻に補正設定されるように時刻補正情報を各ハイパバイザに設定する必要がある。
 図2は,システム単位で同じ時刻補正を行う例を示す図である。図2の(A)では,物理マシンPM1に2つの仮想マシンVM1,VM2が生成され起動されている。そして,これらの仮想マシンVM1,VM2によって所望のサービスを提供するシステムVSYSが構築される。
 クラウドサービスを利用して仮想マシンVM1,VM2を生成する場合,各仮想マシンがどの物理マシンPMに生成されるかは,クラウドサービスセンタの都合により決定されるので,予想困難である。例えば,日本のクラウドサービスセンタ内の物理マシンに生成された仮想マシンを利用してイギリス向けシステムVSYSを構築する場合もあれば,ドイツのクラウドサービスセンタ内の物理マシンに生成された仮想マシンを利用して日本向けシステムVSYSを構築する場合もある。
 図2の(A)の例では,物理マシンPM1に生成された仮想マシンVM1,VM2は,最初はハイパバイザの標準時刻設定によって起動されるが,起動後に,各仮想マシンVM1,VM2についてハイパバイザに時刻補正情報T1を設定して,ハイパバイザがハードディスクに格納する設定ファイルにその時刻補正情報T1が設定されている。図中,時刻補正情報T1がハイパバイザの設定ファイルに設定されていることを示している。この設定ファイルは,ハイパバイザの物理マシンPM1のディスク領域内のVM情報ファイルに格納されている。
 そこで,図2の(B)の例に示されるように,システムVSYSへのアクセス数の増大などの理由により仮想マシンVM3-VM6を増加させる場合,新たな仮想マシンVM3,VM4は物理マシンPM1とは異なる物理マシンPM2に生成され起動され,新たな仮想マシンVM5,VM6は物理マシンPM1,PM2とも異なる物理マシンPM3に生成され起動されることがある。その場合,仮想マシンVM3,VM4は物理マシンPM2のハイパバイザの標準時刻設定情報TD2で起動され,仮想マシンVM5,VM6は物理マシンPM3のハイパバイザの標準時刻設定情報TD3で起動される。その結果,既存の仮想マシンVM1,VM2の時刻補正情報T1と,新たな仮想マシンVM3,VM4の標準時刻設定情報TD2と,新たな仮想マシンVM5,VM6の標準時刻設定情報TD3とが,不統一になる。もしくは,仮想マシンVM3-VM6の時刻設定が所望の時刻情報T1と異なることになる。
 そのため,システムVSYSの運用者は,新たな仮想マシンVM3-VM6毎にハイパバイザに対して時刻補正情報T1に設定することが必要になる。このような設定は,通常,システムVSYSの運用者が手動で行うことになる。
 図3は,サーバロードバランサの配下のリクエスト振り分け先仮想マシン群で同じ時刻補正を行う例を示す図である。図3の(A)では,物理マシンPM1に2つの仮想マシンVM1,VM2が生成・起動され,物理マシンPM2に1つの仮想マシンVM3が生成・起動され,物理マシンPM4にサーバロードバランサSLBの機能を有する仮想マシンVM6が生成・起動されている。また,サーバロードバランサSLB(VM6)がリクエストをSLB配下の2つの仮想マシンVM4,VM7にバランスよく振り分けている。このリクエストの振り分け先の仮想マシンVM4,VM7は物理マシンPM2,PM3にそれぞれ生成・起動されている。そして,これらの仮想マシンによって所望のサービスを提供するシステムVSYSが構築される。また,仮想マシンVM1-VM3,VM6のハイパバイザには時刻補正情報T1が設定され,SLBの振り分け先仮想マシンVM4,VM7のハイパバイザには時刻補正情報T2が設定されている。
 図3の(A)は,例えば,システムVSYSがWebシステムを提供していて,リクエストを受け付けるHTTPサーバを構成する仮想マシンVM4,VM7だけが,Webサービスを提供している地域の時刻T2に補正設定されている例である。
 そして,図3の(B)は,SLB(VM6)がリクエスト数の増大などの理由で,自動でスケールアウトして新たな仮想マシンVM5をリクエストの振り分け先仮想マシン群に追加する例である。この場合,新たな仮想マシンVM5が物理マシンPM3に生成され起動されると,物理マシンPM3のハイパバイザの標準時刻TD3で起動されてしまう。したがって,起動後に仮想マシンVM5のハイパバイザに時刻補正情報T2を手動で設定することが必要になり,SLBが仮想マシンVM5を自動的にスケールアウトする意味がなくなる。
 図4は,同じネットワークセグメント内で同じ時刻補正を行う例を示す図である。図4の(A)では,4つの仮想マシンVM1-VM4が生成され起動されて,システムVSYSを構成している。たとえば,インターネットに公開するサーバとしてイギリス向けのHTTPサーバの機能を有する仮想マシンVM4にはイギリスの時刻補正T2がそのハイパバイザに対して設定され,日本でのバックオフィスのサーバの機能を有する仮想マシンVM1-VM3には日本の時刻補正T1がそれぞれのハイパバイザに対して設定される例である。インターネットに公開するHTTPサーバの仮想マシンVM4は,DMZ(DeMilitarized
Zone)などインターネットと内部ネットワークの中間に置かれるネットワークセグメント内に設けられ,一方バックオフィスのサーバの仮想マシンVM1-VM3は,セキュアなネットワークセグメント内に設けられる。このように,同じネットワークセグメント内では同じ時刻補正が行われ,異なるネットワークセグメント間では異なる時刻補正が行われる場合が想定される。
 図4の(B)では,ネットワークセグメントNW-SEG内の仮想マシンVM4だけでは過負荷状態になり,新たな仮想マシンVM5,VM6,VM7が自動でスケールアウトされている。しかし,仮想マシンVM5,VM6は物理マシンPM3に生成され起動されてハイパバイザの標準時刻TD3で起動され,仮想マシンVM7は物理マシンPM4に生成され起動されてハイパバイザの標準時刻TD4で起動されている。
 そのため,起動後に,仮想マシンVM5-VM7毎にハイパバイザに時刻補正情報T2を手動で設定する必要がある。
 以上のように,複数の仮想マシンによってシステムを構築する場合,同一システム内の仮想マシンという属性や,同一ネットワークセグメント内の仮想マシンという属性や,SLBのリクエスト振り分け先仮想マシンという属性毎に,同じ時刻設定にする必要性が生じることがある。それ以外の属性の仮想マシンも同様に同じ時刻設定が必要になる場合がある。しかし,新たな仮想マシンが,単一のまたは異なる物理マシンのハイパバイザによって生成され起動されると,それぞれのハイパバイザの標準時刻設定情報によって起動されてしまい,起動後に同じ属性に属する複数の仮想マシンそれぞれのハイパバイザに同じ時刻補正情報を設定する必要が生じ,そのような時刻補正情報の設定は煩雑である。
 そこで,本実施の形態では,仮想マシンの情報を管理するハイパバイザとは別の,仮想マシンを管理する管理サーバに,予め属性毎に時刻補正情報を登録してデータベース化しておく。そして,管理サーバが新たな仮想マシンを起動するとき,その登録された時刻補正情報を有する起動コマンドを起動する仮想マシンの物理マシンに送信して,その物理マシンのハイパバイザに,その標準時刻設定情報ではなく,起動コマンドが有する時刻補正情報で仮想マシンを起動させる。従って,単一のまたは異なる物理マシンに仮想マシンを生成し起動する場合,管理サーバに登録した時刻補正情報で仮想マシンを起動するので,仮想マシンの属性毎に所望の時刻補正情報に統一することができ,起動後に時刻補正の設定を手動で行う必要がない。以下,本実施の形態について説明する。
 [本実施の形態におけるクラウドシステムの構成]
 図5は,本実施の形態におけるクラウドシステムの全体構成を示す図である。データセンタ8内に,物理マシンPMなどのハードウエアに生成される仮想マシン群VM-Gと,クラウド利用者に管理コンソールを提供するクラウドサービスポータルサイト2Aと,管理サーバ3とが設けられている。そして,データセンタ8には,インターネットやイントラネット等のネットワーク7を介して,クラウド利用者端末1とクラウド利用者のサービスのクライアント端末6とが接続可能になっている。また,クラウドサービスポータルサイト2Aに加えて,クラウド利用者端末1から直接コマンド(一種のAPI)を管理サーバ3に送信するためのAPIエンドポイント2Bも設けられている。
 仮想マシン群(または仮想計算機群)VM-Gは,複数の物理マシンPM(または物理サーバ,物理計算機)を有し,各物理マシンPMはCPUとメモリ(DRAM)とハードディスク(HDD)等の大容量メモリとネットワークとを有する。ハードウエアである物理マシンPMのリソースは,複数の仮想マシンVMに割り当てられる。クラウドサービスポータルサイト2や管理サーバ3は,例えば,これらの仮想マシンVMによって構築されても良い。
 クラウドシステムによりクラウド利用者に提供されるクラウドサービスは,コンピュータシステムを構築し稼働させるための基盤,即ち,仮想マシンやネットワーク等のインフラストラクチャそのものを,ネットワーク7経由で提供するサービスである。
 クラウド利用者は,その端末1からクラウドサービスポータルサイト2にアクセスして,管理コンソールで仮想マシンに必要な仕様,例えばCPUのクロック周波数,メモリの容量(GB),ハードディスクの容量(MB/sec,IOPS),及びネットワークの帯域幅(Gbps)を選択し,それらについてクラウド利用契約を締結する。また,クラウド利用者端末1は,クラウドサービスポータルサイト2にアクセスして,仮想マシンの稼働状況を監視したり,仮想マシンの動作を操作したりする。
 管理サーバ3は,ハイパバイザ(仮想化ソフトウエア)HVと連携して,物理マシンPMなどを管理し,さらに,仮想マシンVMに物理マシンのハードウエアを割り当てて仮想マシンVMを生成し,管理する。そして,管理サーバ3は,時刻補正情報テーブル(または時刻補正登録情報)(TB),システム(VSYS)情報テーブル(TB),VM情報テーブル(TB),SLB情報テーブル(TB)を含む管理情報テーブル322を有する。この管理情報テーブル322は,時刻補正情報を保管するので時刻補正情報テーブルでもある。
 管理サーバ3は,新たに仮想マシンやシステムを生成する場合に,この管理情報テーブル322に登録する。また,管理サーバ3は,クラウド利用者から仮想マシンの時刻補正情報を設定する要求に応答して,その時刻補正情報を時刻補正情報テーブルTBに登録し,システム(VSYS)情報テーブルTB,VM情報テーブルTB,SLB情報テーブルTBに反映させる。
 ハイパバイザHVは,物理マシン上で動作し,管理サーバ3からの指示に応じて,ハードウエアの物理マシンPMのCPU,メモリ,ハードディスク,ネットワークを割り当てて仮想マシンを動作させる基盤ソフトウエアである。
 仮想マシンVMは,上記のハードウエアである物理マシンPMが割り当てられることに加えて,OS,ミドルウエアMW,アプリケーションAP,データベースDBなどを有するイメージファイルをそのハードディスク内に有し,例えば,起動時にイメージファイルをハードディスクからメモリに書き込み,所望のサービスを提供する動作を行う。
 クライアント端末6は,クラウド利用者によって運営されるシステムのサービスの提供を受けるクライアントの端末である。クライアント端末6は,通常,クラウド利用者の仮想マシンVMにネットワーク7を介してアクセスし,クラウド利用者が運営するサービスの提供を受ける。
 管理サーバ3は,システムの仮想マシンVMの負荷状態を監視し,過負荷状態になると,新たに仮想マシンVMを同じ物理マシンまたは別の物理マシンにスケールアウトするために,物理マシンを介してハイパバイザHVに対し新たな仮想マシンの生成と起動を指示する。また,SBLからの新たな振り分け先になる仮想マシンをスケールアウトする指示に応答して,管理サーバ3は,新たな仮想マシンを同じ物理マシンまたは別の物理マシンに生成と起動を,物理マシンを介してハイパバイザHVに対し指示する。
 図6は,ハイパバイザが有する機能の一例を示す図である。ハイパバイザHVは,物理マシン上で動作し,物理マシンなどのハードウエア群のリソースを仮想マシンVMに割り当てて,仮想マシンVMを動作させる。そのために,ハイパバイザHVは,例えば,仮想マシンを生成する仮想マシン生成部401と,仮想マシンを起動する仮想マシン起動部402と,仮想マシンをシャットダウンする仮想マシンシャットダウン部403と,起動状態の仮想マシンを一時停止,つまりサスペンドする仮想マシンサスペンド部404と,サスペンド状態の仮想マシンを再開,つまりリジュームする仮想マシンリジューム部405と,仮想マシンの動作情報を収集する仮想マシン動作情報収集部406とを有する。さらに,ハイパバイザHVは,管理サーバ3からの時刻補正情報の設定に応答して起動時の時刻設定値を補正する時刻補正処理部408を有する。そして,ハイパバイザHVは,生成した仮想マシンVMの情報を格納するVM情報ファイル409を,図示しないディスク内に保存する。ハイパバイザHVは,このVM情報ファイルを参照して,仮想マシンを起動する。
 上記の仮想マシン起動部402は,管理サーバから物理マシンを介して受信した時刻補正情報付き起動コマンドを実行して,その時刻補正情報で仮想マシンを起動させ,その時刻補正情報をVM情報ファイル409に保存する。尚,上記の起動コマンドは,ハイパバイザが公開しているAPIの一つである。
 図7は,管理サーバの構成例を示す図である。管理サーバ3は,図示しないCPUなどのハードウエアに加えて,ソフトウエア300と記憶部320とを有する。
 管理サーバ内のソフトウエア300は,例えば,クラウドサービスポータルサイト2Aでクラウド契約を締結したクラウド利用者への課金処理などのクラウド利用者管理を行うクラウド利用者管理部301と,クラウド契約に基づいて物理マシンなどハードウエアリソースを割り当てて仮想マシンVMを生成する仮想マシン生成部302と,仮想マシンを管理する仮想マシン管理部303と,仮想マシンの動作を監視する仮想マシン監視部304とを有する。仮想マシン生成部302は,例えば物理マシンを介してハイパバイザHVに対しVM情報を有する生成コマンドを送信して,VM情報をVM情報ファイルに保存させる。
 さらに,ソフトウエア300は,仮想マシンの起動を物理マシンを介してハイパバイザHVに対し指示する仮想マシン起動制御部305と,起動状態の仮想マシンのシャットダウンをハイパバイザHVに指示する仮想マシンシャットダウン制御部306と,起動状態の仮想マシンのサスペンドをハイパバイザHVに指示する仮想マシンサスペンド制御部307と,仮想マシンのリジュームをハイパバイザHVに指示する仮想マシンリジューム制御部308と,仮想マシンの時刻補正情報を設定する仮想マシン時刻補正制御部309と,新たな仮想マシンのスケールアウトをハイパバイザHVに指示する仮想マシンスケールアウト制御部310などを有する。
 上記の仮想マシン起動制御部305は,管理コンソール2AまたはAPIエンドポイント2B経由で仮想マシンの起動命令を受信すると,またはSLBなどによりオートスケールコマンドが起動されると,起動対象の仮想マシンの属性について時刻補正情報が登録されている場合は,その時刻補正情報付きの起動コマンドを物理マシンを介してハイパバイザに対し送信する。
 管理サーバ内の記憶部320には,例えば,ハイパバイザHVから報告される仮想マシンの動作情報を含む仮想マシン動作情報テーブル321と,時刻補正情報や時刻補正情報が反映されたシステム・仮想マシン・SLB情報テーブルを有する管理情報テーブル322などを有する。
 [本実施の形態における管理サーバでの時刻補正情報の設定]
 本実施の形態における管理サーバ3は,新たに仮想マシンを起動する前に,クラウドサービス利用者端末などから送信される仮想マシンのある属性に対する時刻補正情報の登録要求に応答して,管理情報テーブル322内の時刻補正情報テーブルに,その属性に対し第1の時刻補正情報を登録する登録処理を行う。そして,その後,物理マシンに生成される仮想マシンを起動する場合,仮想マシンの属性に対応する時刻補正情報を有する時刻補正登録情報から,起動対象の仮想マシンの属性に対応する時刻補正情報を抽出し,起動対象の仮想マシンを生成する物理マシンに,抽出した時刻補正情報で仮想マシンを起動させる起動コマンドを送信する。管理サーバは,この起動処理により,当該ハイパバイザに時刻補正情報で仮想マシンを起動させる。
 上記の起動処理は,最初にシステムを構築する時に生成した仮想マシンを起動する処理と,既に構築済みシステムにオートスケールコマンド等に応答して生成した追加の仮想マシンを起動する処理とを含む。いずれの場合も,管理サーバに,ある属性に対応する時刻補正情報を起動前に登録しておけば,その属性に属する仮想マシンの起動コマンドには登録した時刻補正情報がオプションとして含まれて,ハイパバイザHVは,その時刻補正情報で仮想マシンを起動する。一旦そのように起動すれば,ハイパバイザHVは,その時刻補正情報をVM情報ファイルに格納するので,その後の起動処理では,その時刻補正情報で起動される。
 上記の仮想マシンの生成と,時刻補正情報の登録と,生成した仮想マシンの起動について具体的な処理を以下説明する。
 図8は,管理コンソールでの時刻補正設定画面の一例を示す図である。図8には,システムを構成する仮想マシンやファイアウオールが一覧表で示されている。ここでは,システムを構成する仮想マシン等は既に物理マシンに生成されていることを前提としている。
 クラウド利用者端末1からクラウドサービスポータルサイトの管理コンソール2Aにアクセスすると,時刻補正設定画面として,図8が表示される。この画面は,あるシステムを選択して時刻補正設定画面を表示した状態である。
 時刻補正設定画面内には,
(1)システム内の全ての仮想マシン等を一括して時刻補正設定を行うチェックボックス20と,
(2)システム一括ではなく,仮想マシンやネットワークセグメントやSLB毎に個別に時刻補正設定を行うチェックボックス21と,
(3)ネットワークセグメントの一つであるDMZ内の全ての仮想マシンを一括して時刻補正設定を行うチェックボックス22と,
(4)ネットワークセグメントの一つであるセキュア内の全ての仮想マシンを一括して時刻補正設定を行うチェックボックス24と,
(5)SLB1のリクエスト振り分け先仮想マシンを一括して時刻補正設定する行23と,
(6)それ以外に,ファイアウオール(Firewall)と,個別の仮想マシン(WEB
Server1, WEB Server2, AP(Application) Server, DB Server)に時刻補正設定をする行が示されている。
 これらの項目に対して,時刻補正情報を設定する領域26が右側に設けられ,GMT表記で設定できるようになっている。
 もし,システム一括チェックボックス20にチェックを入れて,右側にGMT表記でタイムゾーンまたは時刻を設定すると,現在選択されているシステム内の全ての仮想マシンに対して,どの物理マシンのハイパバイザHVにより起動される場合でも,管理サーバが,ここで設定した時刻補正情報(GMT)で起動するような起動コマンドをハイパバイザに送信する。
 同様に,DMZ一括チェックボックス22,SECURE一括チェックボックス24にチェックを入れてGMTのタイムゾーンまたは時刻を設定すると,DMZ内の全ての仮想マシンに対して,またはSECURE内の全ての仮想マシンに対しても,同様に,管理サーバがここで設定した時刻補正情報で仮想マシンを起動させる起動コマンドを物理マシンを介してハイパバイザに対し送信する。
 さらに,SLB1にGMTのタイムゾーンまたは時刻を設定すると,そのSLB1によりリクエストを振り分けられる仮想マシンに対しても,管理サーバが設定した時刻補正情報で仮想マシンを起動させる起動コマンドを物理マシンを介してハイパバイザに対し送信する。
 図9は,本実施の形態において,管理サーバが制御する対象のシステムの具体例を示す図である。システムAは,DMZ-A内とSECURE内とにそれぞれ仮想マシンVM1,VM2とを有する。システムBは,DMZ-B内に2つの仮想マシンVM3,VM4を有し,その後2つの仮想マシンVM13,VM14をオートスケールコマンドにより追加する。システムCは,DMZ-C内に仮想マシンVM5を有し,その後仮想マシンVM15を追加する。そして,システムDは,DMX-D内にSLB1と,そのSLB1からリクエストを振り分けられる仮想マシンVM6,VM7を有し,その後SLB1からリクエストを振り分けられる仮想マシンVM16を追加する。
 図10は,管理サーバ3の管理情報テーブル322内の時刻補正情報テーブルの例を示す図である。図10の例によれば,図9の具体例に示したシステムA-Dに対して,図8に示した管理コンソール内の時刻補正設定画面から管理サーバに次のような時刻補正設定例が行われている。
(1)システムBには一括してGMT-8に時刻補正設定
(2)システムCのDMZ-Cに一括してGMT+8の時刻補正設定
(3)システムDのSLB1にGMT+9の時刻補正設定
(4)それ以外に,仮想マシンマシンVM1,VM2,VM4にもそれぞれGMT+9,GMT+0,GMT+1の時刻補正設定
 図11は,管理サーバ3の管理情報テーブル322内のシステム(VSYS)情報テーブル,仮想マシン情報テーブル,SLB情報テーブルの例を示す図である。管理サーバ3は,仮想マシンを生成する場合,その情報をこれらのテーブルに登録する。さらに,管理サーバ3は,時刻補正情報が設定されると,これらのテーブルに反映する。そして,管理サーバ3は,仮想マシンを生成した後に起動する場合,これらのテーブルを参照して,新規に起動する仮想マシンの情報に加えて,その仮想マシンの属性に設定されている時刻補正情報をオプションとする起動コマンドを,物理マシン経由でハイパバイザHVに送信する。
 図11中の仮想システム情報テーブルVSYS-TBには,管理サーバが管理している全てのシステムに対する契約者IDや一括設定の有無や,そのほか図示しないシステムの情報に加えて,時刻補正情報が登録されている。そして,仮想システム情報テーブルVSYS-TBには,(1)システムBに対して一括して時刻補正情報GMT-8が設定されている。
 図11中の仮想マシン情報テーブルVM-TBには,管理サーバが管理している全ての仮想マシンに対する情報と,VM毎の時刻補正情報と,属しているセグメントとそのセグメントの時刻補正情報と,リクエストを振り分けするSLBのIDが登録されている。図11の例では,仮想マシンVM1,VM2,VM4にはVM時刻補正情報がそれぞれ設定され,仮想マシンVM5にはセグメントDMZ-Cに対してセグメント時刻補正情報GMT+8が設定され,仮想マシンVM6,VM7にはそれらがSLB1のリクエスト振り分け先VMに属していることが設定されている。
 そして,図11中のSLB情報テーブルSLB-TBには,全てのSLBについて図示しない情報と,SLB時刻補正情報が登録されている。図11の例では,SLB1に対してのみSLB時刻補正情報GMT+9が設定されている。
 以下,図9,図10,図11の具体例について,本実施の形態における仮想マシンの生成と起動制御について説明する。まず,仮想マシンの生成処理と起動処理の流れを説明した後に,上記の具体例に適用した生成処理と起動処理の説明を行う。
 [本実施の形態における仮想マシンの生成と起動処理]
 図12は,仮想マシンの生成手順を示すフローチャート図である。管理サーバ3は,仮想マシン生成命令を受信すると(S10のYES),VM生成命令の生成するVM情報をオプションとする生成コマンドを,仮想システムを生成する物理マシン上のハイパバイザHVに対し送信する(S11)。この仮想マシン(VM)生成命令の受信は,例えば,クラウド利用者端末により管理コンソールやAPIエンドポイントからシステムの生成を行った場合や,SLBが新たな仮想マシンをスケールアウトするために発行するオートスケールコマンドを受信した場合に発生する。
 ハイパバイザHVは,この仮想マシンの生成コマンドを受信すると(S12),生成コマンドに含まれているVM情報を,ハイパバイザのVM情報ファイル内に保存する(S13)。VM情報ファイルは,前述のとおり,ハイパバイザのためのハードディスク領域に格納されている。
 なお,図12の工程S11に記載されているように,生成コマンドに時刻補正情報を含ませてもよい。この生成コマンドをハイパバイザに送信すると,ハイパバイザは,生成する仮想マシン情報と時刻補正情報とを共にVM情報ファイルに保存する。その結果,管理サーバは,起動コマンドに時刻補正情報を付加せずにハイパバイザに送信しても,保存済みの時刻補正情報で仮想マシンを起動させることができる場合もある。
 図13は,仮想マシンの起動手順を示すフローチャート図である。管理サーバ3は,仮想マシン起動命令を受信すると(S20のYES),起動する仮想マシンVMをハイパバイザHVが新規に起動する場合,つまり,起動する仮想マシンのハイパバイザHVが以前の起動時と異なる場合は(S21のYES),そのハイパバイザにおける最初の起動であることを意味するので,管理サーバは,起動VM情報と時刻補正値(または時刻補正情報)をオプションとする起動コマンドを物理マシン上のハイパバイザに対し送信する(S23)。また,起動する仮想マシンVMをハイパバイザHVが既に起動済みである場合は(S21のNO),時刻補正値に以前の起動時から変更がなければ,管理サーバは,起動VM情報をオプションとする起動コマンドを物理マシン上のハイパバイザHVに対し送信する(S22)。時刻補正値に以前の起動時から変更されていれば,管理サーバは上記の工程S23を行う。
 ハイパバイザHVは,起動コマンドを受信すると(S24のYES),S23経由のように起動コマンドに時刻補正の指定があれば(S25のYES),起動VM情報に基づいて且つ時刻補正値で仮想マシンを起動し,ハイパバイザのVM情報ファイルの時刻情報を更新して保存する(S27)。一方,S22経由のように起動コマンドに時刻補正の指定がない場合は(S25のYES),起動VM情報に基づいて仮想マシンを起動する(S26)。この場合は,初回の起動ではないので,ハイパバイザHVは,初回の起動時に工程S27でVM情報ファイル内に保存された時刻補正値で仮想マシンを起動する。
 以上のように,管理マシンの管理情報テーブル322内に予め仮想マシンの属性に対応して時刻補正情報を登録しておくことで,管理マシンが,仮想マシンを生成後初めて起動する場合に,管理情報テーブル322内の時刻補正情報を含む起動コマンドを物理マシン上のハイパバイザに対し送信してハイパバイザにその時刻補正情報で仮想マシンを起動させることができる。前述したとおり,この管理情報テーブル322は,時刻補正情報を保存する時刻補正情報テーブルでもある。
 なお,上記の時刻補正情報テーブルは,必ずしも管理サーバに登録される必要はない。管理サーバ以外の記憶領域に記憶されていれば,管理サーバはその時刻補正情報テーブルを参照して起動される仮想マシンの属性に対する時刻補正情報を抽出して,その時刻補正情報で仮想マシンを起動させる起動コマンドを物理マシンに送信することができる。
 図12,図13では,仮想マシンの生成と起動について,管理サーバ3とハイパバイザHVの動作について説明した。次に,以下の3つの場面での仮想マシンの生成手順と起動手順を説明する。
(1)クラウドサービス利用者が端末から手動で新たなシステムを構成する仮想マシンを生成し起動する場合
(2)クラウドサービス利用者が端末から手動で既存システムに更に追加的に仮想マシンを生成し起動する場合
(3)オートスケールコマンドにより追加の仮想マシンを生成し起動する場合
 図14は,クラウドサービス利用者が端末から手動で新たなシステムを構成する仮想マシンを生成し起動する場合(上記(1)の場合)の仮想マシンの生成手順と起動手順を示すフローチャート図である。まず,クラウド利用者端末1で,管理コンソール2Aから新規のシステムを配備する(S30)。これに応答して管理コンソール2Aは,管理サーバ3にシステムの登録を命令する(S31)。この命令に応答して,管理サーバ3は,管理情報テーブル322にシステムとそれを構成する仮想マシンなどを登録し,VM情報をオプションとする生成コマンドを物理マシン上のハイパバイザHVに対し送信する(S32)。これに応答して,ハイパバイザHVは,システムのVM情報をVM情報ファイルに保存する(S33)。
 次に,クラウド利用者端末1で,管理コンソール2Aから時刻補正情報を登録する(S34)。これに応答して管理コンソール2Aは,管理サーバ3に時刻補正情報の登録命令を送信する(S35)。この登録命令に応答して,管理サーバ3は,管理情報テーブルに時刻補正情報と登録する。前述のとおり,時刻補正情報は,仮想マシンの属性(システム,ネットワークセグメント,SLB等)毎に登録することができる。
 時刻補正情報が登録された後に,クラウド利用者端末1で,管理コンソールから仮想マシンの起動を行うと(S37),管理コンソール2Aは管理サーバ3に仮想マシン起動命令を送信する(S38)。この起動命令に応答して,管理サーバ3は,管理情報テーブル322内の時刻補正情報テーブルを参照して,そのテーブル内の起動仮想マシンに適用される時刻補正情報を抽出し,その時刻補正情報と起動VM情報をオプション(またはパラメータ)とする起動コマンドを物理マシン上のハイパバイザHVに対し送信する(S39)。この起動コマンドは,ハイパバイザHVが有するAPIの一つである。そこで,ハイパバイザHVは,この起動コマンドを実行し,起動VM情報の仮想マシンをその時刻補正情報で起動し,その時刻補正情報をVM情報ファイルに保存する(S40)。これにより,以降の起動時には,ハイパバイザは,VM情報ファイルに保存した時刻補正情報で仮想マシンを起動する。
 一方,工程S34の時刻補正情報が登録されないで,クラウド利用者端末1で,管理コンソールから仮想マシンの起動を行うと(S41),管理コンソール2Aは管理サーバ3に仮想マシン起動命令を送信する(S42)。この起動命令に応答して,管理サーバ3は,管理情報テーブル322内の時刻補正情報テーブルを参照しても,起動される仮想マシンに適用される時刻補正情報が登録されていないので,起動VM情報をオプションとする起動コマンドを物理マシン上のハイパバイザHVに対し送信する(S43)。そこで,ハイパバイザHVは,この起動コマンドの起動VM情報の仮想マシンをハイパバイザの標準時刻で起動する(S44)。
 図15は,クラウドサービス利用者が端末から手動で既存システムに更に追加的に仮想マシンを生成し起動する場合(上記(2)の場合)の仮想マシンの生成手順と起動手順を示すフローチャート図である。図15では,前提として,図14の仮想マシンの生成と時刻補正情報の登録と仮想マシンの起動が行われている(S50)。
 そこで,クラウド利用者端末1で,管理コンソール2Aから既存システム内に追加の仮想マシンを配備または生成する(S51)。これに応答して管理コンソール2Aは,管理サーバ3に追加の仮想マシンの登録を命令する(S52)。この命令に応答して,管理サーバ3は,管理情報テーブル322に追加生成する仮想マシンを登録し,生成VM情報をオプションとする生成コマンドを物理マシン上のハイパバイザHVに対し送信する(S53)。これに応答して,ハイパバイザHVは,生成するVM情報をVM情報ファイルに保存する(S54)。
 次に,クラウド利用者端末1で,管理コンソールから生成した仮想マシンの起動を行うと(S55),管理コンソール2Aは管理サーバ3に仮想マシン起動命令を送信する(S56)。この起動命令に応答して,管理サーバ3は,管理情報テーブル322内の時刻補正情報テーブルを参照して,そのテーブル内の起動仮想マシンに適用される時刻補正情報を抽出し,その時刻補正情報と起動VM情報をオプション(またはパラメータ)とする起動コマンドを物理マシン上のハイパバイザHVに対し送信する(S57)。そこで,ハイパバイザHVは,この起動コマンドを実行して,起動VM情報の仮想マシンを時刻補正情報で起動し,その時刻補正情報をVM情報ファイルに保存する(S58)。ハイパバイザHVは初めて仮想マシンを起動する場合は,起動コマンドで指定された時刻補正情報をVM情報ファイルに保存して,以降の同じ仮想マシンの起動はその保存した時刻補正情報で行う。
 このように,仮想マシンの属性に対応して時刻補正情報を登録しているので,その属性に属する仮想マシンを新たに生成した後起動する場合,新たに生成する仮想マシンがどの物理マシンのハイパバイザで起動されようとしても,管理サーバ3が,その登録された時刻補正情報をオプションとする起動コマンドを物理マシン上のハイパバイザHVに対し送信し,それによりハイパバイザHVに登録済みの時刻補正情報で起動制御させることができる。複数の仮想マシンが異なる物理マシンに生成され起動されても,異なる物理マシンに共通の管理サーバが時刻補正情報を登録しているので,設定した時刻補正情報で起動させることができる。
 図16は,SLBなどからのオートスケールコマンドにより追加の仮想マシンを生成し起動する場合(上記(3)の場合)の仮想マシンの生成手順と起動手順を示すフローチャート図である。図16でも,前提として,図14の仮想マシンの生成と時刻補正情報の登録と仮想マシンの起動が行われている(S60)。
 まず,管理サーバ3にオートスケールコマンドの発生が生じる(S61)。例えば,SLBが振り分けるリクエスト数が閾値以上になった場合や,監視サーバが監視する仮想マシンの負荷が閾値を超えた場合などに,SLBや監視サーバ(図示せず)が管理サーバのオートスケールコマンドを起動する。このオートスケールコマンドには,対象のシステム,セグメント,SLBなどの情報が含められ,SLBや監視サーバから管理サーバに送信される。
 このオートスケールコマンドの起動をトリガーとして,管理サーバ3は,管理情報テーブルに,オートスケールコマンドに含まれている追加の仮想マシン情報を登録する(S62)。そして,管理サーバ3は,管理情報テーブル322を参照して,生成し起動する仮想マシンに適用される時刻補正情報を抽出し,その時刻補正値と生成・起動するVM情報とをオプションとする生成・起動コマンドを,物理マシン上のハイパバイザHVに対し送信する(S63)。
 これに応答して,ハイパバイザは,生成・起動コマンドが有する生成・起動する仮想マシンを時刻補正値で生成し起動し,その時刻補正情報と生成・起動する仮想マシン情報とを,VM情報ファイルに保存する(S64)。
 上記の例では,オートスケールコマンドの起動に応答して,管理サーバ3が,生成・起動コマンドをハイパバイザに送信しているが,図14,15のように,管理サーバ3が生成コマンドを物理マシン上のハイパバイザに対し送信してハイパバイザに仮想マシンをVM情報ファイルに保存させた後,起動コマンドを物理マシン上のハイパバイザに対し送信してハイパバイザに生成した仮想マシンを時刻補正情報で起動させてもよい。
 上記のように,オートスケールコマンドの起動により自動的に仮想マシンが生成され起動される場合も,管理サーバ3の管理情報テーブル(時刻情報テーブル)322内に予め属性に対応付けて時刻補正情報を登録しているので,自動で生成される仮想マシンがどの物理マシンに生成されようとしても,管理サーバ3が送信する時刻補正情報をオプションとする起動コマンドにより,様々な物理マシンに新たに生成する仮想マシンを適応される時刻補正情報で起動することができる。
 [本実施の形態における仮想マシンの生成と起動処理例]
 以下,システムと,ネットワークセグメントと,SLBに属する仮想マシンを生成し起動する処理例について,図9,10,11の具体例に基づいて説明する。
 [第1の例]
 図17は,第1の例であるシステム一括設定されている場合の仮想マシンの生成と起動処理を示す図である。また,図18は,図17の仮想マシンの生成と起動処理において参照される管理情報テーブルを示す図である。第1の例は,図9に示したシステムBの例である。図18の管理情報テーブルは,図11と同じであり,どこを参照するかが示されている。
 図17(A)では,システムVSYS-Bを構成する仮想マシンVM3,VM4を物理マシンPM2に生成し起動する例である。例えば,システムVSYS-Bを構築しようとしているクラウド利用者が,端末1上の管理コンソール2Aから手動で仮想マシンVM3,VM4を生成する。この場合,クラウド利用者は仮想マシンVM3,VM4を生成する物理マシンを任意に選択することはできず,クラウドセンタ内の物理マシン群の状況によって,管理サーバ3により適切な物理マシンが選択される。したがって,物理マシンPM2の標準時間TD2がどのタイムゾーンの時刻になるかは予測不能である。
 この場合は,まず,管理サーバ3がシステムVSYS-Bの仮想マシンを生成する物理マシンPM2を選択する。そして,図14のフローチャートに示したように,管理サーバ3が,管理情報テーブル322内に仮想マシンVM3,VM4からなるシステムVSYS-Bを登録し,生成コマンドを物理マシン上のハイパバイザHVに対し送信し,ハイパバイザHVがその生成コマンドを実行してハイパバイザのVM情報ファイルにシステムVSYS-Bの仮想マシンVM3,VM4の情報を保存する(S32,S33)。
 次に,クラウド利用者は,管理コンソール2AからシステムVSYS-Bに対して一括で時刻補正情報GMT-8を設定すると,管理サーバ3は,その時刻補正情報GMT-8を情報管理テーブル322に登録する(S36)。
 その後,クラウド利用者は,管理コンソール2Aから仮想マシンVM3,VM4を起動すると,管理サーバ3は,図18に示されるように管理情報テーブル322の仮想システム情報テーブルVSYS-TBにおいてシステムBが一括で時刻補正情報GMT-8が登録されていることを検出し,その時刻補正情報GMT-8を抽出し,起動しようとする仮想マシン情報と抽出した時刻補正情報GMT-8とをオプション(パラメータ)とする起動コマンドを物理マシンPM2上のハイパバイザHVに対し送信する(S39)。これに応答して,物理マシンPM2のハイパバイザHVは,起動コマンドが指定する仮想マシンVM3,VM4を時刻補正情報GMT-8で起動し,その時刻補正情報をVM情報ファイルに保存する(S40)。この場合,図17に示すように,物理マシンPM2のハイパバイザHVの標準時刻はTD2であるが,管理サーバ3の管理情報テーブルにシステムVSYS-Bに対して一括して登録されている時刻補正情報GMT-8をオプションとする起動コマンドを受信するので,ハイパバイザにその起動コマンドを実行して,その時刻補正情報GMT-8で仮想マシンVM3,VM4を起動させることができる。また,以降の起動時は,ハイパバイザはVM情報ファイルに保存した時刻補正情報で仮想マシンVM3,VM4を起動する。
 図18によれば,仮想マシンVM5に対して時刻補正情報GMT+4が設定されているが,システムBに対する一括の時刻補正情報GMT-8が優先されている。この論理的な優先度は,特に本実施の形態を制限するものではなく,優先されないようにしてもよい。その場合は,例えば,仮想マシンVM5への時刻補正情報の設定は許可されない。
 図17(B)では,仮想マシンVM3,VM4によるシステムVSYS-Bに,仮想マシンVM13,VM14を追加する例である。この仮想マシンVM13,VM14の追加は,システムVSYS-Bのクラウド利用者が手動で行う場合や,例えば既存の仮想マシンVM3,VM4の処理量が増大し物理マシンPM2の負荷が一定時間以上超えている場合などに,管理サーバ3が自動的にオートスケールコマンドを起動した場合などである。
 手動の場合は,図15のフローチャートにしたがって,クラウド利用者が管理コンソール2Aから仮想マシンVM13,VM14を生成すると,管理サーバ3は,物理マシンPM3を選択し,仮想マシンVM13,VM14の情報を管理情報テーブルに登録し,そのVM情報をオプションとする生成コマンドを物理マシンPM3上のハイパバイザに対し送信する(S53)。これを実行して,ハイパバイザはそのVM情報をVM情報ファイルに保存する(S54)。
 そして,クラウド利用者が,管理コンソールから仮想マシンVM13,VM14の起動を行うと,管理サーバ3は,管理情報テーブル322を参照して,そのテーブル内の起動仮想マシンVM13,VM14に適用される時刻補正情報GMT-8を抽出し,その時刻補正情報と起動VM情報をオプションとする起動コマンドを物理マシン上のハイパバイザHVに対し送信する(S57)。そこで,ハイパバイザHVは,この起動コマンドを実行して,その時刻補正情報GMT-8で起動VM情報の仮想マシンVM13,VM14を起動し,その時刻補正情報をVM情報ファイルに保存する(S58)。
 自動の場合は,図16のフローチャートにしたがって,管理サーバ3が管理情報テーブルに仮想マシンVM13,VM14を登録し,その仮想マシン情報と時刻補正情報GMT-8とをオプションとする生成・起動コマンドを,選択した物理マシンPM3上のハイパバイザに対し送信し,ハイパバイザに仮想マシンVM13,VM14のVM情報ファイルへの保存と,時刻補正情報GMT-8による起動と,時刻補正情報GMT-8のVM情報ファイルへの保存とを行わせる(S62,S63,S64)。
 [第2の例]
 図19は,第2の例であるネットワークセグメントで一括設定されている場合の仮想マシンの生成と起動処理を示す図である。また,図20は,図19の仮想マシンの生成と起動処理において参照される管理情報テーブルを示す図である。第2の例は,図9に示したシステムCの例である。図20の管理情報テーブルは,図11と同じであり,どこを参照するかが示されている。
 図19(A)では,システムVSYS-C内のDMZ-C内の仮想マシンVM5を物理マシンPM4に生成し起動する例である。例えば,システムVSYS-Cを構築しようとしているクラウド利用者が端末1上で管理コンソール2Aから手動で仮想マシンVM5を生成する。この場合,クラウド利用者は仮想マシンVM5を生成する物理マシンを任意に選択することはできず,クラウドセンタ内の物理マシン群の状況によって,管理サーバ3により適切な物理マシンが選択される。したがって,物理マシンPM4の標準時間TD4がどのタイムゾーンの時刻になるかは予測不能である。
 この場合,図17(A)と同様に,まず,管理サーバ3がシステムVSYS-Cの仮想マシンを生成する物理マシンPM4を選択し,管理情報テーブル322内に仮想マシンVM3,VM4からなるシステムVSYS-Bを登録し,生成コマンドを物理マシン上のハイパバイザHVに対し送信し,ハイパバイザHVがその生成コマンドを実行して,そのVM情報ファイルに仮想マシンVM5の情報を保存する(S32,S33)。
 次に,クラウド利用者は,管理コンソール2AからシステムVSYS-Cのネットワークセグメントの一つであるDMZ-Cに対して一括で時刻補正情報GMT+8を設定すると,管理サーバ3は,その時刻補正情報GMT+8を情報管理テーブル322に登録する(S36)。
 次に,クラウド利用者は,管理コンソール2Aから仮想マシンVM5を起動すると,管理サーバ3は,図20に示されるように管理情報テーブル322を検索する。管理サーバ3は,管理情報テーブル322から,仮想システム情報テーブルVSYS-TBにおいてシステムCが一括で時刻補正情報が登録されておらず,仮想マシン情報テーブルVM-TBにおいて仮想マシンVM5がネットワークセグメントDMZ-Cに属していて,そのDMZ-Cには時刻補正情報GMT+8が設定されていることを検出する。そこで,管理サーバ3は,その時刻補正情報GMT+8を抽出し,起動しようとする仮想マシン情報と抽出した時刻補正情報GMT+8とをオプションとする起動コマンドを物理マシンPM4上のハイパバイザHVに対し送信する(S39)。これを実行して,物理マシンPM4のハイパバイザHVは,起動コマンドが指定する仮想マシンVM5を時刻補正情報GMT+8で起動し,その時刻補正情報をVM情報ファイルに保存する(S40)。
 図19(B)では,システムVSYS-C内のDMZ-C内に仮想マシンVM15を追加する例である。追加する理由は,図17の第1の例と同様である。
 手動の場合は,図15のフローチャートにしたがって,クラウド利用者が管理コンソール2Aから仮想マシンVM15を生成すると,管理サーバ3は,物理マシンPM5を選択し,仮想マシンVM15の情報を管理情報テーブルに登録し,そのVM情報をオプションとする生成コマンドを物理マシンPM5上のハイパバイザに対し送信し,ハイパバイザにそのVM情報をVM情報ファイルに保存させる(S53,S54)。
 そして,クラウド利用者が,管理コンソールから仮想マシンVM15の起動を行うと,管理サーバ3は,管理情報テーブル322を参照して,そのテーブル内の起動仮想マシンVM15に適用される時刻補正情報GMT+8を抽出し,その時刻補正情報と起動VM情報をオプションとする起動コマンドを物理マシン上のハイパバイザHVに対し送信し,ハイパバイザHVに起動コマンドの時刻補正情報GMT+8で起動VM情報の仮想マシンVM15を起動させ,その時刻補正情報をVM情報ファイルに保存させる(S57,S58)。尚,図20には仮想マシンVM15の登録は省略されているが,仮想マシンVM5と同様に登録されているものとする。
 自動の場合は,図16のフローチャートにしたがって,管理サーバ3が管理情報テーブルに仮想マシンVM15を登録し,その仮想マシン情報と時刻補正情報GMT+8とをオプションとする生成・起動コマンドを,選択した物理マシンPM5上のハイパバイザに対し送信し,ハイパバイザに仮想マシンVM15のVM情報ファイルへの保存と,時刻補正情報GMT+8による起動と,時刻補正情報GMT+8のVM情報ファイルへの保存とを行わせる(S62,S63,S64)。
 [第3の例]
 図21は,第3の例であるSLB単位で一括設定されている場合の仮想マシンの生成と起動処理を示す図である。また,図22は,図21の仮想マシンの生成と起動処理において参照される管理情報テーブルを示す図である。第3の例は,図9に示したシステムDの例である。図22の管理情報テーブルは,図11と同じであり,どこを参照するかが示されている。
 図21(A)では,システムVSYS-D内のSLB1によってリクエストが振り分けられる仮想マシンVM6,VM7(SLB1の配下の仮想マシン群)を物理マシンPM6に生成し起動する例である。例えば,システムVSYS-Dを構築しようとしているクラウド利用者が管理コンソール2Aから手動で仮想マシンVM6,VM7を生成する。この場合,クラウド利用者は仮想マシンVM6,VM7を生成する物理マシンを任意に選択することはできず,クラウドセンタ内の物理マシン群の状況によって,管理サーバ3により適切な物理マシンが選択される。したがって,物理マシンPM6の標準時間TD6がどのタイムゾーンの時刻になるかは予測不能である。
 まず,クラウド利用者が管理コンソール2AからSLB1のリクエスト振り分け先の仮想マシンVM6,VM7の生成を行うと,図14のフローチャートで説明したように,管理サーバ3が生成する物理マシンPM6を決定し,管理情報テーブル322に仮想マシンVM6,VM7を登録し,物理マシンPM6上のハイパバイザに対しVM情報をオプションとする生成コマンドを送信し,ハイパバイザにVM情報ファイルに保存させる(S32,S33)。
 そして,クラウド利用者が管理コンソール2AからSLB1について時刻補正情報GMT+9を登録すると,管理サーバ3が管理情報テーブル322にそのSLB1に対する時刻補正情報GMT+9を登録する(S36)。
 さらに,クラウド利用者が,管理コンソールから仮想マシンVM6,VM7の起動を行うと,管理サーバ3は,管理情報テーブル322を参照して,そのテーブル内の起動仮想マシンVM6,VM7に適用される時刻補正情報GMT+9を抽出する。図22に示されるように,管理情報テーブル322内の仮想システム情報テーブルVSYS-TB,仮想マシン情報テーブルVM-TB,SLB情報テーブルSLB-TBを順に参照して,仮想マシンVM6,VM7はSLB1に属していて時刻補正情報GMT+9が登録されていることを検出する。そして,管理サーバ3は,その時刻補正情報と起動VM情報をオプションとする起動コマンドを物理マシン上のハイパバイザHVに対し送信し,ハイパバイザHVに起動コマンドの時刻補正情報GMT+9で起動VM情報の仮想マシンVM6,VM7を起動させ,その時刻補正情報をVM情報ファイルに保存させる(S39,S40)。このように,仮想マシンVM6,VM7がハイパバイザの標準時刻TD6とは異なる管理サーバに登録した時刻補正情報GMT+9で起動させることができる。そして,次回以降の起動では,ハイパバイザがVM情報ファイルに保存した時刻補正情報GMT+9で仮想マシンVM6,VM7を起動することになる。
 図21(B)では,システムVSYS-D内のSLB1がオートスケールコマンドにより仮想マシンVM16を追加する例である。すなわち,SLB1がリクエスト総数が一定時間以上閾値を超えた場合に管理サーバ3のオートスケールコマンドを起動することで,管理サーバ3が自動で仮想マシンVM16を追加している例である。
 オートスケールコマンドに応答して,図16のフローチャートにしたがって,管理サーバ3が管理情報テーブルに仮想マシンVM16を登録し,管理情報テーブル322を検索して仮想マシンVM16が属するSLB1に対する時刻補正情報GMT+9を検出する。但し,図22の管理情報テーブルには仮想マシンVM16は省略されているが,VM6,VM7にと同様に登録されているものとする。そして,管理サーバ3は,その仮想マシン情報と時刻補正情報GMT+9とをオプションとする生成・起動コマンドを,選択した物理マシンPM7上のハイパバイザHVに対し送信し,ハイパバイザに仮想マシンVM16のVM情報ファイルへの保存と,時刻補正情報GMT+9による起動と,時刻補正情報GMT+8のVM情報ファイルへの保存とを行わせる(S62,S63,S64)。
 上記の3つの例から明らかなとおり,仮想マシンの属性(システム,ネットワークセグメント,SLB)に対して時刻補正情報を管理サーバ3の管理情報テーブルに登録することで,ハイパバイザに,異なる物理マシンに生成された複数の仮想マシンを,それぞれの最初の起動時に,登録した時刻補正情報で起動させることができる。そして,ハイパバイザは最初に起動した時刻補正情報をVM情報ファイルに保存するので,2回目以降の起動も,同じ時刻補正情報で起動することができる。
 [本実施の形態における仮想マシン時刻補正情報の設定]
 本実施の形態によれば,管理サーバの時刻補正情報の登録とそれをオプションとする起動コマンドの物理マシン上のハイパバイザへの送信とにより,新たに生成し起動する仮想マシンを,時刻補正情報で起動させることができ,起動後に手動による仮想マシンへの時刻補正の設定を必要としない。
 図23は,登録した時刻補正情報により同じ属性に属する仮想マシンが起動された例を示す図である。図23の例では,異なる2つの物理マシンPM1,PM2に仮想マシンVMが生成され起動されている。
 まず,システムBは,4つの仮想マシンVMが2つの物理マシンPM1,PM2にまたがって生成され起動されている。そして,システムBに対して時刻補正情報GMT-Bが一括して登録されているため,最初の起動動作で4つの仮想マシンVMは全て同じ時刻補正情報GMT-Bで起動されている。そして,その時刻補正情報GMT-BがハイパバイザのVM情報ファイルに保存されているので,2回目以降も,起動コマンドが別の時刻補正情報をオプションに含まなければ,ハイパバイザはVM情報ファイルに保存された時刻補正情報GMT-Bで仮想マシンを起動する。
 図23において,システムCは6つの仮想マシンVMが2つの物理マシンPM1,PM2にまたがって生成され起動されている。6つの仮想マシンVMのうち2つの仮想マシンVMが同じネットワークセグメントNW-SEGに属している。そして,システムCのネットワークセグメントNW-SEGに対して時刻補正情報GMT-Cが一括して登録されているため,最初の起動動作で2つの仮想マシンVMは全て同じ時刻補正情報GMT-Cで起動されている。そして,その時刻補正情報GMT-CがハイパバイザのVM情報ファイルに保存されているので,2回目以降も,起動コマンドが別の時刻補正情報をオプションに含まなければ,ハイパバイザはVM情報ファイルに保存された時刻補正情報GMT-Cで仮想マシンを起動する。
 さらに,図23において,システムDは4つの仮想マシンVMが2つの物理マシンPM1,PM2にまたがって生成され起動されている。4つの仮想マシンVMのうち3つの仮想マシンVMが同じSLB1に属している。そして,システムDのSLB1に対して時刻補正情報GMT-Dが一括して登録されているため,最初の起動動作で3つの仮想マシンVMは全て同じ時刻補正情報GMT-Dで起動される。そして,その時刻補正情報GMT-DがハイパバイザのVM情報ファイルに保存されているので,2回目以降も,ハイパバイザはVM情報ファイルに保存された時刻補正情報GMT-Dで仮想マシンを起動する。
 図24は,本実施の形態における管理サーバの場合のマイグレーションを説明する図である。また,図25は,マイグレーションの処理を示すフローチャート図である。図24には,物理マシンPM1に生成され起動していた仮想マシンVM1を,異なる物理マシンPM2にマイグレーションすることが示されている。
 図25のフローチャート図にしたがって,上記のマイグレーション処理について説明する。まず,クラウド利用者端末1から管理コンソール2Aを介して,仮想マシンVM1を物理マシンPM1からPM2にマイグレーション指令を入力すると,管理サーバ3は,物理マシンPM1のハイパバイザHV1にマイグレーションを命令する。
 これに応答して,ハイパバイザHV1は,移転先の物理マシンPM2のハイパバイザHV2に移転先仮想マシンVM2を生成させ,メモリ領域を確保させる(S70)。そして,ハイパバイザHV1は,移転元仮想マシンVM1のメモリ内容を,移転先仮想マシンVM2のメモリに転送しコピーする(S71)。メモリ内容の転送が完了すると,ハイパバイザHV1は,移転元仮想マシンVM1のCPU内のレジスタの値(コンテキスト)を移転先仮想マシンVM2のCPU内のレジスタに転送してコピーする(S72)。
 次に,ハイパバイザHV1は,移転元仮想マシンVM1をサスペンドし,移転先仮想マシンVM2をリジュームする(S73,S74)。この時,移転元仮想マシンVM1のメモリ情報とコンテキストにより移転先仮想マシンVM2がリジュームするので,移転元仮想マシンVM1の時刻補正情報で移転先仮想マシンVM2がリジュームする。以上で,マイグレーションは終了する。
 その後,何らかの理由で移転先仮想マシンVM2がシャットダウンされたとする(S75)。この場合,それ以降に移転先仮想マシンVM2が起動される場合は,管理サーバ3が移転元仮想マシンVM1の属性に対して設定していた時刻補正情報を抽出し,その時刻補正情報をオプションとする起動コマンドをハイパバイザHV2に送信し,その結果,移転先仮想マシンVM2が時刻補正情報で起動される。
 このように,異なる物理マシン間で仮想マシンをマイグレーションする場合において,移転先仮想マシンが移転元仮想マシンの物理マシンとは異なる物理マシンに生成されその後起動されるとき,本実施の形態の管理サーバ3による時刻補正情報の登録とその時刻補正情報をオプションとする起動コマンドの発行により,同じ時刻補正情報で移転先仮想マシンVM2を起動させることができる。
1:クラウド利用者端末       2A管理コンソール(クラウドサービスポータルサイト)
3:管理サーバ           322:管理情報テーブル
PM:物理マシン(物理計算機)    HV;ハイパバイザ(仮想化ソフトウエア)
VM1,VM2:仮想マシン(仮想計算機) 8:データセンタ(クラウドセンタ)

Claims (13)

  1.  複数の物理計算機上のいずれかで動作する仮想計算機を管理する仮想計算機管理処理をコンピュータに実行させる仮想計算機管理プログラムであって,
     前記仮想計算機管理処理は,
     前記物理計算機に生成される仮想計算機を起動する場合,仮想計算機の属性に対応する時刻補正情報を有する時刻補正登録情報から,前記起動対象の仮想計算機の属性に対応する時刻補正情報を抽出する抽出工程と,
     前記起動対象の仮想計算機を生成する物理計算機に,前記抽出した時刻補正情報で仮想計算機を起動させる起動コマンドを送信する起動工程とを有する仮想計算機管理プログラム。
  2.  請求項1において,
     更に,前記仮想計算機の起動要求を受け付ける工程を有し,
     前記起動要求を受け付けた場合に,前記抽出工程及び起動工程が実行される仮想計算機管理プログラム。
  3.  請求項1において,
     更に,前記仮想計算機を追加生成する追加生成要求を受け付ける工程を有し,
     前記追加生成要求を受け付けた場合に,前記抽出工程及び起動工程が実行される仮想計算機管理プログラム。
  4.  請求項3において,
     前記追加生成要求をサーバレベルバランサから受け付けた場合は,前記サーバレベルバランサの配下の仮想計算機を前記物理計算機に生成させ,前記時刻補正情報に応じて当該生成する仮想計算機を起動させる仮想計算機管理プログラム。
  5.  請求項1において,
     更に,所定の属性に対する時刻補正情報の登録要求に応答して,前記時刻補正登録情報内に,前記所定の属性に対し前記時刻補正情報を登録する登録工程を有する仮想計算機管理プログラム。
  6.  請求項1において,
     前記起動工程にて,前記物理計算機に前記属性に対応する時刻補正情報を記憶させる仮想計算機管理プログラム。
  7.  複数の物理計算機上のいずれかで動作する仮想計算機を管理する仮想計算機管理方法であって,
     前記物理計算機に生成される仮想計算機を起動する場合,仮想計算機の属性に対応する時刻補正情報を有する時刻補正登録情報から,前記起動対象の仮想計算機の属性に対応する時刻補正情報を抽出する抽出工程と,
     前記起動対象の仮想計算機を生成する物理計算機に,前記抽出した時刻補正情報で仮想計算機を起動させる起動コマンドを送信する起動工程とを有する仮想計算機管理方法。
  8.  仮想計算機を生成し動作させるハイパバイザがそれぞれ動作する複数の物理計算機と,
     前記複数の物理計算機上のいずれかで動作する前記仮想計算機を管理する管理サーバとを有し,
     前記管理サーバは,前記物理計算機に生成される仮想計算機を起動する場合,仮想計算機の属性に対応する時刻補正情報を有する時刻補正登録情報から,前記起動対象の仮想計算機の属性に対応する時刻補正情報を抽出する抽出手段と,前記起動対象の仮想計算機を生成する物理計算機に,前記抽出した時刻補正情報で仮想計算機を起動させる起動コマンドを送信する起動手段とを有し,
     前記起動コマンドを受信した物理計算機のハイパバイザは,前記時刻補正情報で前記仮想計算機を起動する仮想計算機システム。
  9.  請求項8において,
     前記管理サーバは,更に,前記仮想計算機の起動要求を受け付ける受付手段を有し,
     前記起動要求を受け付けた場合に,前記起動手段が前記起動コマンドを送信する仮想計算機システム。
  10.  請求項8において,
     更に,前記仮想計算機を追加生成する追加生成要求を受け付ける受付手段を有し,
     前記追加生成要求を受け付けた場合に,前記起動手段が前記起動コマンドを送信する仮想計算機システム。
  11.  請求項10において,
     前記追加生成要求をサーバレベルバランサから受け付けた場合は,前記起動手段が前記サーバレベルバランサの配下の仮想計算機を前記物理計算機に生成させ,前記時刻補正情報に応じて当該生成する仮想計算機を起動させる仮想計算機システム。
  12.  請求項8において,
     前記管理サーバは,更に,所定の属性に対する時刻補正情報の登録要求に応答して,前記時刻補正登録情報内に,前記所定の属性に対し前記時刻補正情報を登録する登録手段を有する仮想計算機システム。
  13.  請求項8において,
     前記起動コマンドを受信した物理計算機は,前記属性に対応する時刻補正情報を前記ハイパバイザに記憶させる仮想計算機システム。
PCT/JP2013/052276 2013-01-31 2013-01-31 仮想計算機管理プログラム,仮想計算機管理方法及び仮想計算機システム WO2014118961A1 (ja)

Priority Applications (4)

Application Number Priority Date Filing Date Title
PCT/JP2013/052276 WO2014118961A1 (ja) 2013-01-31 2013-01-31 仮想計算機管理プログラム,仮想計算機管理方法及び仮想計算機システム
JP2014559452A JP6102949B2 (ja) 2013-01-31 2013-01-31 仮想計算機管理プログラム,仮想計算機管理方法及び仮想計算機システム
EP13873624.4A EP2953032A4 (en) 2013-01-31 2013-01-31 VIRTUAL COMPUTER MANAGEMENT PROGRAM, VIRTUAL COMPUTER MANAGEMENT METHOD, AND VIRTUAL COMPUTER SYSTEM
US14/810,784 US20150339150A1 (en) 2013-01-31 2015-07-28 Virtual computer management program, virtual computer management method, and virtual computer system

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/JP2013/052276 WO2014118961A1 (ja) 2013-01-31 2013-01-31 仮想計算機管理プログラム,仮想計算機管理方法及び仮想計算機システム

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US14/810,784 Continuation US20150339150A1 (en) 2013-01-31 2015-07-28 Virtual computer management program, virtual computer management method, and virtual computer system

Publications (1)

Publication Number Publication Date
WO2014118961A1 true WO2014118961A1 (ja) 2014-08-07

Family

ID=51261705

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2013/052276 WO2014118961A1 (ja) 2013-01-31 2013-01-31 仮想計算機管理プログラム,仮想計算機管理方法及び仮想計算機システム

Country Status (4)

Country Link
US (1) US20150339150A1 (ja)
EP (1) EP2953032A4 (ja)
JP (1) JP6102949B2 (ja)
WO (1) WO2014118961A1 (ja)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20230305854A1 (en) * 2022-03-25 2023-09-28 Sap Se Reducing downtime during operating system patching

Families Citing this family (15)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN104239122B (zh) * 2014-09-04 2018-05-11 华为技术有限公司 一种虚拟机迁移方法和装置
US9594649B2 (en) * 2014-10-13 2017-03-14 At&T Intellectual Property I, L.P. Network virtualization policy management system
US9848041B2 (en) 2015-05-01 2017-12-19 Amazon Technologies, Inc. Automatic scaling of resource instance groups within compute clusters
US10133593B1 (en) * 2016-03-31 2018-11-20 Amazon Technologies, Inc. Virtual machine migration
CN106227578A (zh) * 2016-07-12 2016-12-14 腾讯科技(深圳)有限公司 一种虚拟机热迁移的方法、设备及系统
US10693732B2 (en) 2016-08-03 2020-06-23 Oracle International Corporation Transforming data based on a virtual topology
US10389628B2 (en) 2016-09-02 2019-08-20 Oracle International Corporation Exposing a subset of hosts on an overlay network to components external to the overlay network without exposing another subset of hosts on the overlay network
US10291507B2 (en) 2017-02-13 2019-05-14 Oracle International Corporation Implementing a virtual tap in a virtual topology
US10462013B2 (en) * 2017-02-13 2019-10-29 Oracle International Corporation Implementing a single-addressable virtual topology element in a virtual topology
JP2019049818A (ja) * 2017-09-08 2019-03-28 富士通株式会社 情報処理装置、情報処理システム、情報処理システムの制御方法及びライブマイグレーション制御プログラム
US10560331B2 (en) * 2018-02-07 2020-02-11 Juniper Networks, Inc. Self-driven and adaptable multi-vBNG management orchestration
US10904303B2 (en) 2018-05-31 2021-01-26 Salesforce.Com, Inc. Control message from streaming source to facilitate scaling
US11321139B2 (en) * 2018-05-31 2022-05-03 Salesforce.Com, Inc. Streaming traffic pattern for public cloud auto scaling
US11558311B2 (en) * 2020-01-08 2023-01-17 Amazon Technologies, Inc. Automated local scaling of compute instances
CN115617256A (zh) * 2021-07-12 2023-01-17 戴尔产品有限公司 基于指定虚拟机引导条件的确定可能性在存储集群的存储节点中移动虚拟卷

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH1115558A (ja) 1997-06-27 1999-01-22 Hitachi Ltd 情報処理装置の時刻制御方法
WO2012093490A1 (ja) * 2011-01-07 2012-07-12 富士通株式会社 情報処理装置、時刻制御方法および時刻制御プログラム

Family Cites Families (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5257376A (en) * 1990-09-04 1993-10-26 International Business Machines Corporation Method and apparatus for configuring a control program nucleus with a minimum impact on system availabiltiy
US8146078B2 (en) * 2004-10-29 2012-03-27 Intel Corporation Timer offsetting mechanism in a virtual machine environment
US9392078B2 (en) * 2006-06-23 2016-07-12 Microsoft Technology Licensing, Llc Remote network access via virtual machine
US8949826B2 (en) * 2006-10-17 2015-02-03 Managelq, Inc. Control and management of virtual systems
US7689817B2 (en) * 2006-11-16 2010-03-30 Intel Corporation Methods and apparatus for defeating malware
JP5298764B2 (ja) * 2008-10-22 2013-09-25 富士通株式会社 仮想システム制御プログラム、方法及び装置
US8694819B2 (en) * 2009-08-24 2014-04-08 Hewlett-Packard Development Company, L.P. System and method for gradually adjusting a virtual interval timer counter value to compensate the divergence of a physical interval timer counter value and the virtual interval timer counter value
US20110078303A1 (en) * 2009-09-30 2011-03-31 Alcatel-Lucent Usa Inc. Dynamic load balancing and scaling of allocated cloud resources in an enterprise network
JP2012037935A (ja) * 2010-08-03 2012-02-23 Fujitsu Ltd 情報処理装置
US8793684B2 (en) * 2011-03-16 2014-07-29 International Business Machines Corporation Optimized deployment and replication of virtual machines
US8984168B2 (en) * 2011-03-31 2015-03-17 Microsoft Technology Licensing, Llc Relative timestamp when real time clock is unavailable
US20140007189A1 (en) * 2012-06-28 2014-01-02 International Business Machines Corporation Secure access to shared storage resources

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH1115558A (ja) 1997-06-27 1999-01-22 Hitachi Ltd 情報処理装置の時刻制御方法
WO2012093490A1 (ja) * 2011-01-07 2012-07-12 富士通株式会社 情報処理装置、時刻制御方法および時刻制御プログラム

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See also references of EP2953032A4 *

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20230305854A1 (en) * 2022-03-25 2023-09-28 Sap Se Reducing downtime during operating system patching

Also Published As

Publication number Publication date
JP6102949B2 (ja) 2017-03-29
EP2953032A1 (en) 2015-12-09
JPWO2014118961A1 (ja) 2017-01-26
US20150339150A1 (en) 2015-11-26
EP2953032A4 (en) 2016-01-27

Similar Documents

Publication Publication Date Title
JP6102949B2 (ja) 仮想計算機管理プログラム,仮想計算機管理方法及び仮想計算機システム
US9838249B2 (en) Maintaining resource availability during maintenance operations
US10333782B1 (en) System and method for distributed management of cloud resources in a hosting environment
US10469592B2 (en) Virtualizing device management services on a multi-session platform
US11550603B2 (en) Method and system for sizing a cloud desktop fabric
US8909767B2 (en) Cloud federation in a cloud computing environment
JP6054522B2 (ja) 統合型ストレージ/vdiプロビジョニング方法
US11714668B2 (en) Supporting quality-of-service for virtual machines based on operational events
CN107741875B (zh) 一种异构管理系统
US20150234670A1 (en) Management apparatus and workload distribution management method
CN109313577B (zh) 分布式计算网络中的数据平面api
KR102313432B1 (ko) 다중―단일―테넌트 SaaS 서비스들의 관리
US11201930B2 (en) Scalable message passing architecture in a cloud environment
US11108673B2 (en) Extensible, decentralized health checking of cloud service components and capabilities
KR20150124001A (ko) 클라우드 기반 웹 호스팅 시스템
JP2012168710A (ja) 情報処理システム、情報処理方法、及び制御プログラム
US11385973B1 (en) High-availability for power-managed virtual desktop access
US20240028098A1 (en) Session preservation for automated power management

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

Country of ref document: EP

Kind code of ref document: A1

ENP Entry into the national phase

Ref document number: 2014559452

Country of ref document: JP

Kind code of ref document: A

WWE Wipo information: entry into national phase

Ref document number: 2013873624

Country of ref document: EP

NENP Non-entry into the national phase

Ref country code: DE