JP2019185511A - Cluster system, autoscale server monitoring device, autoscale server monitoring program, and autoscale server monitoring method - Google Patents

Abstract

To restore an autoscale server when suspended and restored on the basis of latest information of a virtual machine.SOLUTION: Physical servers 30, 40 are capable of executing a plurality of virtual machines. An autoscale server 20 performs scale-in and scale-out of virtual machines in the physical servers 30, 40. An autoscale server monitoring device 10 periodically communicates with the autoscale server 20, and stores information on the virtual machines managed by the autoscale server 20. Upon sending that the autoscale server 20 is suspended, the autoscale server monitoring device 10 transmits information on the virtual machines in accordance with a request from the autoscale server 20.SELECTED DRAWING: Figure 1

Description

  The present invention relates to a cluster system, an autoscale server monitoring apparatus, an autoscale server monitoring program, and an autoscale server monitoring method.

  In the field of information processing, there is a virtualization technology for operating a plurality of virtual computers (sometimes called virtual machines or virtual hosts) on a physical computer (sometimes called a physical machine or a physical host). It's being used. Software such as an OS (Operating System) can be executed on each virtual machine. A physical machine that uses a virtualization technology executes software for managing a plurality of virtual machines. For example, software called a hypervisor may allocate a processing capacity of a CPU (Central Processing Unit) and a storage area of a RAM (Random Access Memory) to a plurality of virtual machines as computing resources.

  By the way, in an information processing system, the number of machines (virtual machines and physical machines) that perform operations may be increased or decreased. For example, increasing the number of machines is called scale-out. On the other hand, reducing the number of machines is called scale-in. Here, a technique for supporting the operation of a system that performs scale-out and scale-in is considered.

  For example, there is a proposal of a failure monitoring device that prevents erroneous notification of normal operation of a standby server for scale by automatic scale-out and automatic scale-in as a failure. The fault monitoring device stores server usage information that indicates whether each monitored server is always operating or only when it is scaled out, and operating status information that indicates whether each server is on standby or operating. To do. The fault monitoring device checks the server usage information and operational status information of the server that generated the event for the event detected by the monitoring system, and whether the event occurred due to a fault or occurs due to automatic scale-out and automatic scale-in. Determine if you did.

  In addition, there is also a proposal for a platform operation management system that can monitor and avoid the loss of logs in an information processing system built with virtual servers whose number automatically increases or decreases in a cloud environment. . In the infrastructure operation management system, the virtual server that is the target of the autoscale function transfers a predetermined log that requires real-time monitoring, to the virtual server that is not the target of the autoscale function.

JP 2011-253231-A Japanese Patent Laying-Open No. 2015-184879

  As described above, it is conceivable to automatically increase or decrease the number of virtual machines belonging to the system by using an autoscale server having an autoscale function. However, the autoscale server may stop due to a failure or the like. In this case, a change in the activation state of the virtual machine (for example, the activated virtual machine stops due to a failure or the like) may occur while the autoscale server is stopped. Then, when the autoscale server is restored, there is a possibility that the information indicating the operating state of the virtual machine held by the autoscale server is inconsistent with the actual operating state of the virtual machine. Such inconsistency can be a factor that prevents the autoscale server from properly executing the autoscale function after recovery.

  In one aspect, the present invention relates to a cluster system, an autoscale server monitoring apparatus, an autoscale server monitoring program, and an autoscale server that can be recovered based on the latest information of a virtual machine when the autoscale server is stopped and recovered. An object is to provide a scale server monitoring method.

  In one aspect, a cluster system is provided. The cluster system includes a physical server, an autoscale server, and an autoscale server monitoring device. The physical server can execute a plurality of virtual machines. The autoscale server performs scale-in and scale-out of the virtual machine in the physical server. The autoscale server monitoring device periodically communicates with the autoscale server, stores virtual machine information managed by the autoscale server, and detects that the autoscale server has stopped. , Send virtual machine information.

  In one aspect, an autoscale server monitoring device is provided. The autoscale server monitoring apparatus has a storage unit and a processing unit. The storage unit stores information on virtual machines managed by the autoscale server. When the processing unit periodically communicates with the autoscale server and detects that the autoscale server has stopped, the processing unit transmits virtual machine information in response to a request from the autoscale server.

In one aspect, an autoscale server monitoring program is provided.
In one aspect, an autoscale server monitoring method is provided.

  In one aspect, when the autoscale server stops and is restored, it can be restored based on the latest information of the virtual machine.

It is a figure which shows the cluster system of 1st Embodiment. It is a figure which shows the example of the cluster system of 2nd Embodiment. It is a block diagram which shows the hardware example of a monitoring server. It is a figure which shows the example of a scale out and a scale in. It is a block diagram which shows the function example of a cluster system. It is a figure which shows the example of an auto scale server management table. It is a figure which shows the example of a VM management table. It is a figure which shows the example of an auto scale group table. It is a figure which shows the example of a VM table. It is a figure which shows the example of an auto scale policy table. It is a flowchart which shows the example of VM monitoring. It is a flowchart which shows the example of an auto scale server monitoring. It is a figure which shows the example of the monitoring by a monitoring server. It is a figure which shows the comparative example of monitoring. It is a figure which shows the example of the virtual machine of 3rd Embodiment. It is a figure which shows the example of a VM management table. It is a flowchart which shows the example of VM monitoring.

Hereinafter, the present embodiment will be described with reference to the drawings.
[First Embodiment]
A first embodiment will be described.

FIG. 1 illustrates a cluster system according to the first embodiment.
The cluster system 1 includes an autoscale server monitoring device 10, an autoscale server 20, and physical servers 30 and 40. The autoscale server monitoring device 10, the autoscale server 20, and the physical servers 30 and 40 are connected to a network 50.

  The physical servers 30 and 40 can execute a plurality of virtual machines. For example, the physical server 30 can execute the virtual machines 31 and 32. The physical server 40 can execute the virtual machines 41 and 42. Virtual machines can be scaled out and scaled in.

  The autoscale server 20 collects the load of each virtual machine and controls the scale-out and scale-in of the virtual machine based on the load of each virtual machine. For example, if the state in which the load of the virtual machine 31 exceeds the first threshold continues when the virtual machine 32 is stopped, the autoscale server 20 starts the virtual machine 32 on the physical server 30 and The load is distributed not only to the machine 31 but also to the virtual machine 32. In addition, when the virtual machines 31 and 32 are operating, the autoscale server 20 is configured such that the load (average load or one load) of the virtual machines 31 and 32 is the second threshold (second threshold <first Below the threshold), the virtual machine 32 is stopped and the resource usage is reduced. The autoscale server 20 similarly controls the scale-out and scale-in of the virtual machines 41 and 42 in the physical server 40. The group of virtual machines for determining the load is determined according to the operation (for example, the virtual machine 32 may be started according to the load of the virtual machines 31, 41, and 42).

  The autoscale server monitoring apparatus 10 monitors the autoscale server 20. Further, the autoscale server monitoring apparatus 10 monitors the virtual machines 31, 32, 41, and 42 that are autoscale targets. Specifically, the autoscale server monitoring apparatus 10 performs life and death monitoring of the corresponding virtual machine by periodically communicating with the operating virtual machine. When the autoscale server monitoring apparatus 10 detects an abnormality in any of the virtual machines, the autoscale server monitoring apparatus 10 notifies the user that the abnormality has been detected.

  However, the autoscale target virtual machine is activated or stopped by the autoscale control by the autoscale server 20. For this reason, when the autoscale server monitoring apparatus 10 detects the interruption of the periodic communication in any of the autoscale target virtual machines, the autoscale server monitoring apparatus 10 inquires of the autoscale server 20 whether the virtual machine has been stopped due to the scale-in. . If the disruption of regular communication is due to scale-in, the disruption is not abnormal. On the other hand, if the interruption of regular communication is not caused by scale-in, the interruption is regarded as abnormal. However, the autoscale server 20 may stop due to an abnormality or the like. The autoscale server monitoring apparatus 10 provides a function of monitoring the operating state of the autoscale server 20 and supporting the recovery of the autoscale server 20.

The autoscale server monitoring apparatus 10 includes a storage unit 11 and a processing unit 12. The autoscale server 20 includes a storage unit 21 and a processing unit 22.
The storage units 11 and 21 may be a volatile storage device such as a RAM, or may be a nonvolatile storage device such as an HDD (Hard Disk Drive) or a flash memory. The processing units 12 and 22 may include a CPU, a DSP (Digital Signal Processor), an ASIC (Application Specific Integrated Circuit), an FPGA (Field Programmable Gate Array), and the like. The processing units 12 and 22 may be processors that execute programs. As used herein, the “processor” may include a set of multiple processors (multiprocessor).

  The storage unit 11 stores information on the virtual machines 31, 32, 41, and 42 managed by the autoscale server 20. For example, the storage unit 11 stores a table 61. The table 61 shows the status of alive monitoring (success / failure of regular communication) of each of the virtual machines 31, 32, 41, and 42 by the autoscale server monitoring apparatus 10. Here, the identification information of the virtual machine 31 is “VM (Virtual Machine) 1”. The identification information of the virtual machine 32 is “VM2”. The identification information of the virtual machine 41 is “VM3”. The identification information of the virtual machine 42 is “VM4”. Further, in the table 61, “ON” indicates that periodic communication with the corresponding virtual machine has been performed (for example, at the latest periodic communication timing), and “OFF” indicates that periodic communication has not been performed.

  Here, the storage unit 21 also stores information indicating the states of the virtual machines 31, 32, 41, and 42. For example, the storage unit 21 stores a table 71. The table 71 is stored in a non-volatile storage area in the storage unit 21. The table 71 is information used for autoscale control, and is state information indicating the states of the virtual machines 31, 32, 41, and 42. For example, “normal” indicates normal operation. “Scale-in” indicates that the scale-in is stopped. “Error” indicates that the operation has been stopped due to an abnormality. The processing unit 22 updates the state of each virtual machine in the table 71 in accordance with the collection of the operating states of the virtual machines 31, 32, 41, and the results of auto scaling.

  The processing unit 12 may acquire information indicating the virtual machine to be autoscaled from the autoscale server 20 and generate the table 61 to determine a virtual machine to be monitored for life and death by the autoscale server monitoring apparatus 10.

  When the processing unit 12 periodically communicates with the autoscale server 20 and detects that the autoscale server 20 has stopped, the processing unit 12 transmits virtual machine information to the autoscale server 20 in response to a request from the autoscale server 20. .

  First, consider the case where the autoscale server 20 is in operation (step ST1). At this time, it is assumed that the processing unit 12 can perform regular communication with the virtual machines 31, 41, and 42 but cannot perform regular communication with the virtual machine 32 (cannot communicate). The processing unit 12 records “ON” for the virtual machines 31, 41, and 42 (“VM1, VM3, VM4”) and “OFF” for the virtual machine 32 (“VM2”) in the table 61. The processing unit 12 inquires of the autoscale server 20 about the autoscale status of the virtual machine 32.

  At this time, in the autoscale server 20, as shown in the table 71, the virtual machines 31, 41, and 42 are managed as “normal” and the virtual machine 32 is managed as “scale-in”. That is, the virtual machine 32 is in a state stopped by scale-in. For this reason, the processing unit 22 responds to the autoscale server monitoring apparatus 10 that the virtual machine 32 has been stopped due to the scale-in.

  The processing unit 12 receives a response from the autoscale server 20, and detects that the virtual machine 32 is in a state stopped by scale-in based on the response. For this reason, the processing unit 12 does not regard the failure of communication with the virtual machine 32 (disruption of regular communication) as an abnormality. The processing unit 12 continues alive monitoring for the virtual machines 31, 41, and 42.

  Next, consider a case where the autoscale server 20 is stopped due to an abnormality or the like (step ST2). When the regular communication with the autoscale server 20 cannot be normally performed, the processing unit 12 detects that the autoscale server 20 is stopped. The processing unit 12 periodically communicates with the operating virtual machines 31, 41, and 42 while the autoscale server 20 is stopped, and continues monitoring whether the virtual machines 31, 41, and 42 are alive. Then, the processing unit 12 detects that communication with the virtual machine 42 (“VM4”) is disabled (periodic communication interruption). Then, the processing unit 12 updates the table 61 to the table 62. Specifically, the processing unit 12 changes “VM4” from “ON” to “OFF”.

  Next, consider a case where the autoscale server 20 is restored from a stopped state (step ST3). When receiving a request from the autoscale server 20, the processing unit 12 detects that the autoscale server 20 has started. The request from the autoscale server 20 may be a request for virtual machine information, or may be a predetermined request (or response) related to regular communication with the autoscale server monitoring apparatus 10. Then, based on the table 62, the processing unit 12 transmits to the autoscale server 20 that the periodic communication with the virtual machine 42 has been detected while the autoscale server 20 is stopped. The interruption of the regular communication with the virtual machine 42 occurs while the autoscale server 20 is stopped. For this reason, the interruption is not caused by the scale-in of the virtual machine 42. Therefore, the processing unit 22 updates the table 71 to the table 72 when receiving a notification of interruption of the periodic communication of the virtual machine 42 from the autoscale server monitoring apparatus 10. Specifically, the processing unit 22 changes “VM4” from “normal” to “error”.

The processing unit 12 may acquire from the autoscale server 20 that the virtual machine 42 is managed as “error” and notify the user of an abnormality in the virtual machine 42.
In step ST <b> 3, the processing unit 12 may transmit information on each virtual machine in the table 62 to the autoscale server 20. The processing unit 22 can determine in which virtual machine an abnormality has occurred by comparing the virtual machine information in the table 62 and the virtual machine information in the table 72. For example, the processing unit 22 determines that a virtual machine that is “OFF” in the table 62 and “normal” in the table 71 is abnormal (“error”), and other virtual machines are not abnormal (“normal” or “scale”). -In "or the like.

  According to the autoscale server monitoring apparatus 10, information on virtual machines that are periodically communicated with the autoscale server 20 and managed by the autoscale server 20 is stored. When it is detected that the autoscale server 20 has stopped, virtual machine information is transmitted in response to a request from the autoscale server 20.

Thereby, when the autoscale server 20 is stopped and recovered, it can be recovered based on the latest information of the virtual machine.
Here, a case where the function of the autoscale server monitoring apparatus 10 is not used is considered. In this case, even if the virtual machine 41 stops due to an abnormality or the like while the autoscale server 20 is stopped, the autoscale server 20 cannot grasp the stop of the virtual machine after the autoscale server 20 is started. . The autoscale server 20 performs autoscale control of each virtual machine using the table 71. In other words, there is a mismatch between the virtual machine information managed by the autoscale server 20 and the actual operating state of the virtual machine. In this case, the autoscale server 20 cannot perform appropriate autoscale control for the virtual machines 41 and 42. Further, it may take a relatively long time (for example, 10 minutes to several tens of minutes) before the autoscale server 20 detects the stop of the virtual machine 42. During this time, if the load on the virtual machine 41 increases, autoscale control may not be performed properly, and processing such as an application executed on the virtual machine 41 may be affected.

  Therefore, the autoscale server monitoring apparatus 10 acquires information about the virtual machine that is stopped by the autoscale server 20 and provides the autoscale server 20 with the information about the virtual machine when the autoscale server 20 is restored. As a result, the autoscale server 20 can be restored in a state in which the inconsistency between the virtual machine information managed in the autoscale server 20 and the actual operating state of the virtual machine is resolved. For this reason, the autoscale server 20 can resume autoscale control normally immediately after the recovery. As a result, the load of each virtual machine can be appropriately distributed by auto-scaling control, and the influence on processing such as an application executed on each virtual machine can be suppressed.

  In the example of the cluster system 1, the targets to be monitored by the autoscale server monitoring device 10 are the autoscale server 20 and the virtual machines (virtual machines 31, 32, 41, 42) subject to autoscale by the autoscale server 20. . On the other hand, the virtual machine to be monitored by the autoscale server monitoring apparatus 10 is not limited to this. The autoscale server monitoring apparatus 10 may perform alive monitoring of virtual machines that are autoscale targets and virtual machines that are not autoscale targets. When the autoscale server monitoring apparatus 10 detects the interruption of the periodic communication for a virtual machine that is not an autoscale target, the autoscale server monitoring apparatus 10 omits the inquiry to the autoscale server 20 and notifies the user that an abnormality has occurred in the virtual machine. be able to.

[Second Embodiment]
Next, a second embodiment will be described.
FIG. 2 is a diagram illustrating an example of a cluster system according to the second embodiment.

  The cluster system according to the second embodiment is an information processing system that provides a virtual machine usage environment to a user. The cluster system according to the second embodiment includes a monitoring server 100, an autoscale server 200, and physical servers 300 and 400.

  The monitoring server 100, the autoscale server 200, and the physical servers 300 and 400 are connected to the network 60. The network 60 is, for example, a LAN (Local Area Network) laid in a data center or the like. The network 60 is connected to the network 70. The network 70 is, for example, the Internet or a WAN (Wide Area Network). User terminals 500 and 600 are connected to the network 70.

  The monitoring server 100 is a server computer that monitors the autoscale server 200. The monitoring server 100 also monitors virtual machines that operate on the physical servers 300 and 400. The monitoring server 100 is an example of the autoscale server monitoring apparatus 10 according to the first embodiment.

  The auto scale server 200 is a server computer that performs auto scale (auto scale) control of virtual machines operating on the physical servers 300 and 400. The autoscale server 200 is an example of the autoscale server 20 according to the first embodiment.

  The physical servers 300 and 400 are server computers that can execute a plurality of virtual machines. For example, the physical server 300 executes software called a hypervisor and allocates hardware resources such as CPU and RAM in the physical server 300 to virtual machines on the physical server 300. Similarly, the physical server 400 executes a hypervisor and allocates hardware resources such as CPU and RAM in the physical server 400 to virtual machines on the physical server 400. The physical servers 300 and 400 are an example of the physical servers 30 and 40 according to the first embodiment.

  User terminals 500 and 600 are client computers used by users. The user terminals 500 and 600 transmit processing requests for applications executed on the virtual machines on the physical servers 300 and 400. In addition, the user terminals 500 and 600 receive the processing result by the virtual machine.

  In the cluster system of the second embodiment, autoscale control of the virtual machine is performed by the autoscale server 200 so that the user can use the virtual machine smoothly. However, the autoscale server 200 may stop due to an abnormality or the like. Therefore, the monitoring server 100 provides a function for reducing the influence on the autoscale control even when the autoscale server 200 is stopped. In the following description, a virtual machine may be abbreviated as VM. In addition, the auto scale may be abbreviated as AS (Auto Scaling).

FIG. 3 is a block diagram illustrating a hardware example of the monitoring server.
The monitoring server 100 includes a CPU 101, a RAM 102, an HDD 103, an image signal processing unit 104, an input signal processing unit 105, a medium reader 106, and a NIC (Network Interface Card) 107. The CPU 101 corresponds to the processing unit 12 of the first embodiment. The RAM 102 or the HDD 103 corresponds to the storage unit 11 of the first embodiment.

  The CPU 101 is a processor that executes program instructions. The CPU 101 loads at least a part of the program and data stored in the HDD 103 into the RAM 102 and executes the program. Note that the CPU 101 may include a plurality of processor cores. The monitoring server 100 may have a plurality of processors. The processes described below may be executed in parallel using a plurality of processors or processor cores. A set of processors may be referred to as “multiprocessor” or simply “processor”.

  The RAM 102 is a volatile semiconductor memory that temporarily stores programs executed by the CPU 101 and data used by the CPU 101 for calculations. Note that the monitoring server 100 may include a type of memory other than the RAM, or may include a plurality of memories.

  The HDD 103 is a non-volatile storage device that stores software programs such as an OS, middleware, and application software, and data. The monitoring server 100 may include other types of storage devices such as flash memory and SSD (Solid State Drive), and may include a plurality of nonvolatile storage devices.

  The image signal processing unit 104 outputs an image to the display 111 connected to the monitoring server 100 in accordance with a command from the CPU 101. As the display 111, any type of display such as a CRT (Cathode Ray Tube) display, a liquid crystal display (LCD), a plasma display, an organic EL (OEL: Organic Electro-Luminescence) display, or the like can be used.

  The input signal processing unit 105 acquires an input signal from the input device 112 connected to the monitoring server 100 and outputs it to the CPU 101. As the input device 112, a pointing device such as a mouse, a touch panel, a touch pad, a trackball, a keyboard, a remote controller, a button switch, or the like can be used. A plurality of types of input devices may be connected to the monitoring server 100.

  The medium reader 106 is a reading device that reads programs and data recorded on the recording medium 113. As the recording medium 113, for example, a magnetic disk, an optical disk, a magneto-optical disk (MO), a semiconductor memory, or the like can be used. Magnetic disks include flexible disks (FD: Flexible Disk) and HDDs. The optical disc includes a CD (Compact Disc) and a DVD (Digital Versatile Disc).

  For example, the medium reader 106 copies a program or data read from the recording medium 113 to another recording medium such as the RAM 102 or the HDD 103. The read program is executed by the CPU 101, for example. The recording medium 113 may be a portable recording medium and may be used for distributing programs and data. In addition, the recording medium 113 and the HDD 103 may be referred to as computer-readable recording media.

  The NIC 107 is an interface that is connected to the network 60 and communicates with other computers via the network 60. The NIC 107 is connected to a communication device such as a switch or a router with a cable, for example.

FIG. 4 is a diagram illustrating an example of scale-out and scale-in.
FIG. 4A illustrates scale-out. Consider a case where the physical server 300 executes the virtual machines 310 and 320 and the physical server 400 executes the virtual machines 410 and 420. For example, the virtual machines 310, 320, 410, and 420 belong to one group of virtual machines to be autoscaled and execute processing of applications (or application groups) used by users in a distributed manner.

  The autoscale server 200 periodically collects loads on the virtual machines 310, 320, 410, and 420. For example, in the autoscale server 200, when the average load of the virtual machines 310, 320, 410, and 420 exceeds the first threshold for a predetermined period, the load of the virtual machines 310, 320, 410, and 420 is increased. And scale out the virtual machine. For example, the autoscale server 200 activates the virtual machine 330 by the physical server 300 and distributes part of the load on the virtual machines 310, 320, 410, 420 to the virtual machine 330.

  FIG. 4B illustrates scale-in. Consider a case where the physical server 300 executes the virtual machines 310 and 320 and the physical server 400 executes the virtual machines 410 and 420. The autoscale server 200 periodically collects loads on the virtual machines 310, 320, 410, and 420. For example, in the autoscale server 200, when the average load of the virtual machines 310, 320, 410, and 420 continues below a second threshold for a predetermined period, the load of the virtual machines 310, 320, 410, and 420 becomes low. The virtual machine is scaled in. Here, the second threshold value is smaller than the first threshold value. For example, the autoscale server 200 stops the virtual machine 420 in the physical server 400 and releases resources allocated to the virtual machine 420.

FIG. 5 is a block diagram illustrating an example of functions of the cluster system.
The monitoring server 100 includes a storage unit 120 and a monitoring unit 130. The storage unit 120 is realized by a storage area of the RAM 102 or the HDD 103. The monitoring unit 130 is realized by the CPU 101 executing a program stored in the RAM 102.

  The storage unit 120 stores an autoscale server management table and a VM management table. The autoscale server management table is information indicating the operating state of the autoscale server 200. The VM management table is information indicating the success or failure of regular communication for each virtual machine.

  The monitoring unit 130 monitors each virtual machine on the physical servers 300 and 400 and the autoscale server 200. The monitoring unit 130 includes a VM monitoring unit 131 and an AS server cooperation unit 132.

  The VM monitoring unit 131 periodically communicates with each virtual machine on the physical servers 300 and 400 and confirms communication with each virtual machine. For example, the VM monitoring unit 131 performs communication confirmation by receiving a communication confirmation packet from each virtual machine. The communication confirmation packet may be, for example, an ICMP (Internet Control Message Protocol) echo request or an echo response from a virtual machine in response to an echo request transmitted by the VM monitoring unit 131. Alternatively, the VM monitoring unit 131 may perform communication confirmation using another protocol such as SNMP (Simple Network Management Protocol). The virtual machines that are monitored by the VM monitoring unit 131 are all virtual machines that are subject to autoscale control. The VM monitoring unit 131 may inquire the autoscale server 200 about a virtual machine to be monitored.

  The AS server cooperation unit 132 cooperates with the auto scale server (AS server) 200. The AS server cooperation unit 132 periodically communicates with the autoscale server 200 and performs alive monitoring of the autoscale server 200. For example, the AS server cooperation unit 132 may perform alive monitoring of the autoscale server 200 by inquiring of the autoscale server 200 periodically about the state of the virtual machine. If there is a response from the autoscale server 200 to the inquiry, the autoscale server 200 is operating. On the other hand, if there is no response from the autoscale server 200 to the inquiry, the autoscale server 200 is stopped.

  When the autoscale server 200 is operating, the AS server cooperation unit 132 indicates to the autoscale server 200 whether or not a virtual machine that has not been confirmed for communication among the monitored virtual machines has been stopped due to scale-in. Inquire. When the corresponding virtual machine is stopped due to the scale-in, the AS server cooperation unit 132 does not make an abnormality that the communication check cannot be performed. When the corresponding virtual machine is not stopped due to the scale-in, the AS server cooperation unit 132 determines that the virtual machine for which the communication check cannot be performed is abnormal, and notifies the system administrator. For example, the AS server cooperation unit 132 may cause the display 111 to display a screen indicating that an abnormality has occurred in the corresponding virtual machine. Alternatively, the AS server cooperation unit 132 may transmit a message indicating the occurrence of an abnormality of the corresponding virtual machine to a terminal device (not shown) connected to the network 50 and used by the system administrator. .

  When the autoscale server 200 is stopped, the AS server cooperation unit 132 cannot make an inquiry to the autoscale server 200 as to whether or not the virtual machine for which the communication check has not been performed has been stopped due to the scale-in. For this reason, the AS server cooperation unit 132 holds the inquiry. Thereafter, when the autoscale server 200 is activated, the AS server cooperation unit 132 detects the activation of the autoscale server 200 by resuming the communication confirmation. Then, when there is a virtual machine whose communication check has been interrupted while the autoscale server 200 is stopped, the AS server cooperation unit 132 transmits information on the virtual machine to the autoscale server 200.

  The auto scale server 200 includes a storage unit 210 and an AS control unit 220. The storage unit 210 is realized using a storage area of the RAM or HDD of the autoscale server 200. The AS control unit 220 is realized by the CPU of the autoscale server 200 executing a program stored in the RAM of the autoscale server 200.

  The storage unit 210 stores information used for autoscale control. Specifically, the storage unit 210 stores an autoscale group table, a VM table, and an autoscale policy table.

  The auto scale group table is information indicating an auto scale group. The auto scale group is a group of virtual machines that are targets of auto scale control. In accordance with the load of the virtual machine belonging to one autoscale group, the autoscale control of the virtual machine belonging to the autoscale group is performed. The VM table is information indicating a virtual machine that is subject to autoscale control. The VM table includes the state of the virtual machine. The state of the virtual machine is as follows: (1) The virtual machine is operating normally, (2) The virtual machine is abnormal, (3) It is degraded due to scale-in (it has stopped due to scale-in) (4) It is considered that the system is being activated for scale-out. The autoscale policy table is information indicating an autoscale control policy (conditions for performing scale-in and scale-out).

  Here, the auto scale group table, the VM table, and the auto scale policy table are stored in a non-volatile storage area (for example, a storage area of the HDD) in the storage unit 210. Further, the autoscale group table, the VM table, and the autoscale policy table are duplicated and temporarily stored in a volatile storage area (for example, a storage area of the RAM) in the storage unit 210 when used for autoscale control. May also be stored. In this case, the updated contents of each table held in the volatile storage area are also reflected in the replication source tables stored in the nonvolatile storage area by the AS control unit 220.

  The AS control unit 220 performs autoscale control (AS control) of virtual machines on the physical servers 300 and 400 (for example, a plurality of virtual machines including the virtual machines 310, 320, 410, and 420). The AS control unit 220 periodically collects information on virtual machine loads. For example, the AS control unit 220 may collect the load of the virtual machine using a protocol such as SNMP. The AS control unit 220 instructs the physical servers 300 and 400 to perform scale-in and scale-out based on the collected load and the autoscale policy of the autoscale group to which the virtual machine belongs.

  Here, the autoscale server 200 may stop due to a failure or the like. While the autoscale server 200 is stopped, the autoscale control by the AS control unit 220 is also stopped. When the autoscale server 200 is started after the autoscale server 200 is stopped, the AS control unit 220 acquires virtual machine information from the monitoring server 100 according to the communication confirmation while the autoscale server 200 is stopped. To do. The AS control unit 220 updates the state of the virtual machine in the VM table stored in the storage unit 210 based on the acquired virtual machine information. The AS control unit 220 resumes the collection of the load of the virtual machine based on the updated VM table, and resumes the autoscale control.

FIG. 6 is a diagram illustrating an example of an autoscale server management table.
The autoscale server management table 121 is stored in the storage unit 120. The autoscale server management table 121 includes items of an autoscale server ID (IDentifier) and an operating flag.

  In the auto scale server ID item, identification information (auto scale server ID) of the auto scale server 200 is registered. The autoscale server ID of the autoscale server 200 is, for example, “apparatus A”. In the in-operation flag item, an in-operation flag indicating whether or not the autoscale server 200 is in operation is registered. The operating flag “True” indicates that it is operating. The operating flag “False” indicates that the system is not operating (that is, stopped). For example, in the autoscale server management table 121, a record in which the autoscale server ID is “device A” and the operating flag is “True” is registered.

FIG. 7 is a diagram illustrating an example of the VM management table.
The VM management table 122 is stored in the storage unit 120. The VM management table 122 includes items of a VM name, a communication IP (Internet Protocol) address, an autoscale VM operating flag, and an autoscale information update flag.

  The virtual machine name (virtual machine ID) is registered in the VM name item. The IP address of the virtual machine is registered in the item of IP address for communication. In the auto scale VM operating flag item, an auto scale VM operating flag indicating whether or not life monitoring is successful (that is, whether the corresponding virtual machine is operating) is registered. The auto-scale VM operating flag “True” indicates that regular communication with the corresponding virtual machine has been normally performed (that is, the corresponding virtual machine is operating). The auto-scale VM operating flag “False” indicates that regular communication with the corresponding virtual machine has not been normally performed (that is, the corresponding virtual machine has stopped). In the item of the autoscale information update flag, an autoscale information update flag indicating whether or not the autoscale VM operation flag has been updated for the virtual machine while the autoscale server 200 is stopped is registered. The autoscale information update flag “True” indicates that the update has occurred. The autoscale information update flag “False” indicates that the update has not occurred. The initial value of the autoscale information update flag is “False”.

  For example, in the VM management table 122, the VM name is “Grp1_VM1”, the communication IP address is “100.10.99.1”, the autoscale VM operating flag is “True”, and the autoscale information update flag is “False”. Is registered. This record indicates that the communication IP address of the virtual machine with the VM name “Grp1_VM1” is “100.10.99.1”. Further, it indicates that the virtual machine is running and the autoscale VM operating flag is not updated while the autoscale server 200 is stopped.

  Further, for example, in the VM management table 122, the VM name is “SampleVM”, the communication IP address is “200.200.200.2”, the autoscale VM operating flag is “False”, and the autoscale information update flag is set. A record “True” is registered. This record indicates that the communication IP address of the virtual machine with the VM name “SampleVM” is “200.200.200.2”. In addition, it indicates that the virtual machine is stopped and the autoscale VM operation flag is updated while the autoscale server 200 is stopped.

FIG. 8 is a diagram illustrating an example of an autoscale group table.
The autoscale group table 211 is stored in the storage unit 210. The auto scale group table 211 includes items of auto scale group ID, available CIDR (Classless Inter-Domain Routing), auto scale policy ID, minimum number and maximum number.

  In the item of auto scale group ID, identification information (auto scale group ID) of the auto scale group is registered. Available CIDR is registered in the item of available CIDR. In the auto scale policy ID item, identification information (auto scale policy ID) of an auto scale policy applied to the corresponding auto scale group is registered. Here, the specific content of the autoscale policy corresponding to the autoscale policy ID is registered in advance in an autoscale policy table to be described later. In the item of minimum number, the minimum number of virtual machines in the corresponding autoscale group is registered. In the maximum number of items, the maximum number of virtual machines in the corresponding autoscale group is registered.

  For example, in the autoscale group table 211, the autoscale group ID is “Group 1”, the available CIDR is “100.10.99.0/24”, the autoscale policy ID is “Rule 1, 3”, and the minimum number Is registered as “1” and the maximum number is “10”. In this record, in the autoscale group with the autoscale group ID “group 1”, the available CIDR is “100.10.99.0/24”, and the autoscale policy with the autoscale policy ID “rule 1, 3”. Indicates that the minimum number of virtual machines is 1 and the maximum number is 10.

FIG. 9 is a diagram illustrating an example of the VM table.
The VM table 212 is stored in the storage unit 210. The VM table 212 includes items of a VM name, an auto scale group ID, a communication IP address, and a VM state.

  In the VM name item, the VM name of the virtual machine is registered. In the auto scale group ID item, the auto scale group ID of the auto scale group to which the virtual machine belongs is registered. The IP address of the virtual machine is registered in the item of IP address for communication. In the VM status item, the status of the virtual machine is registered. As described above, the state of the virtual machine is that the virtual machine is operating normally, the virtual machine is abnormal (ERROR), and has been degraded due to scale-in (stopped due to scale-in), It may be activated for scale-out.

  For example, in the VM table 212, a record having a VM name “Grp1_VM1”, an autoscale group ID “group 1”, a communication IP address “100.10.99.1”, and a VM state “normal” is registered. Is done. In this record, the virtual machine with the VM name “Grp1_VM1” belongs to the autoscale group with the autoscale group ID “group 1”, the IP address of the virtual machine is “100.10.99.1”, and the virtual machine Indicates that it is operating normally.

  Further, for example, the VM table 212 has a record in which the VM name is “Grp1_VM2”, the autoscale group ID is “group 1”, the communication IP address is “100.10.99.2”, and the VM state is “ERROR”. Is registered. In this record, the virtual machine with the VM name “Grp1_VM2” belongs to the autoscale group with the autoscale group ID “group 1”, the IP address of the virtual machine is “100.10.99.2”, and the virtual machine Indicates that an abnormality has occurred.

  Further, for example, in the VM table 212, the VM name is “Grp1_VM3”, the autoscale group ID is “group 1”, the communication IP address is “100.10.99.3”, and the VM state is “scale-in degenerate”. Is registered. In this record, a virtual machine with a VM name “Grp1_VM3” belongs to an autoscale group with an autoscale group ID “group 1”, and the IP address of the virtual machine is “100.10.99.3”. Indicates that it has stopped.

  Further, for example, in the VM table 212, the VM name is “Grp2_VM3”, the autoscale group ID is “group 2”, the communication IP address is “100.11.0.32”, and the VM state is “scaled out”. Is registered. In this record, the virtual machine with the VM name “Grp2_VM3” belongs to the autoscale group with the autoscale group ID “group 2”, the IP address of the virtual machine is “100.11.0.32”, and the scale-out Therefore, it shows that it is starting.

  FIG. 10 is a diagram illustrating an example of an autoscale policy table. The autoscale policy table 213 is stored in the storage unit 210. The auto scale policy table 213 includes items of auto scale policy ID, trigger, and trigger details.

  In the item of auto scale policy ID, identification information (auto scale policy ID) of the auto scale policy is registered. In the trigger item, a resource to be monitored (which may be a logical resource recognized by a virtual machine) serving as a trigger for autoscale control is registered. In the trigger details item, conditions related to the trigger of auto scale control are registered.

  For example, in the auto scale policy table 213, the auto scale policy ID is “Rule 1”, the trigger is “CPU usage rate”, the trigger details are “CPU average usage rate per minute is acquired, and 80% is obtained 5 times continuously. A record “scale out when exceeded” is registered.

  This record is triggered by the CPU usage rate of the virtual machine in the auto-scaling policy with the auto-scaling policy ID “Rule 1”, and when the average CPU usage rate per minute exceeds 80% for 5 consecutive times, Indicates to do out. Here, the “CPU average usage rate per minute” may be an average regarding a plurality of virtual machines belonging to the corresponding autoscale group, or may be an average of virtual machine units belonging to the corresponding autoscale group. In the latter case, scale-out is performed when the average CPU usage rate per minute exceeds 80% five times in at least one of the virtual machines belonging to the corresponding autoscale group. The concept of “CPU average usage rate” (or “memory average usage rate”) every predetermined time is the same for other autoscale policies.

  Also, for example, in the autoscale policy table 213, the autoscale policy ID is “Rule 2”, the trigger is “Memory usage rate”, the trigger details are “Acquire memory average usage rate every 5 minutes, and 95 times in succession. The record “Scale out when exceeding%” is registered. This record is triggered by the memory usage rate of the virtual machine in the auto scaling policy with the auto-scaling policy ID “Rule 2”. When the average memory usage rate every 5 minutes exceeds 95% three times continuously, the scale is Indicates to do out.

  Also, for example, in the autoscale policy table 213, the autoscale policy ID is “Rule 3”, the trigger is “CPU usage rate”, the trigger details are “CPU average usage rate per minute is acquired, and 10 times continuously. The record “Scale-in when below%” is registered. This record is triggered by the CPU usage rate of the virtual machine in the auto-scaling policy with the auto-scaling policy ID “Rule 3”, and when the average CPU usage rate per minute falls below 10% for 5 consecutive times, Indicates to perform in.

  Also, for example, in the autoscale policy table 213, the autoscale policy ID is “Rule 4”, the trigger is “Memory usage rate”, the trigger details are “Acquire memory average usage rate every 5 minutes, and 30 times continuously. The record “Scale-in when below%” is registered. This record is triggered by the virtual machine's memory usage rate in the auto scaling policy with the auto-scaling policy ID “Rule 4”, and when the average memory usage rate every 5 minutes falls below 30% for 5 consecutive times, Indicates to perform in.

Next, a processing procedure of the monitoring server 100 in the cluster system will be described.
FIG. 11 is a flowchart illustrating an example of VM monitoring.
The VM monitoring unit 131 periodically executes the following processing. The execution cycle is determined according to the operation. The period may be about several seconds to several tens of seconds, or about 1 minute to several minutes.

  (S10) The VM monitoring unit 131 collects monitoring information of the virtual machine to be monitored (monitoring target VM). For example, the VM monitoring unit 131 collects monitoring information by receiving a predetermined packet for alive monitoring from a virtual machine to be monitored.

  (S11) The VM monitoring unit 131 updates the operation status of the monitoring target VM. Specifically, the VM monitoring unit 131 updates the VM management table 122 based on the monitoring information collection result in step S10. In other words, the VM monitoring unit 131 sets the auto-scale VM operating flag of the virtual machine for which the monitoring information has been collected (the alive monitoring packet has been received) to “True”. In the case of “True” originally, it can be left as it is.

  (S12) The VM monitoring unit 131 determines whether there is a monitoring target VM for which the monitoring information has not arrived within a predetermined time since the last collection of the monitoring information. The predetermined time is a period obtained by adding a relatively short time (a time shorter than the period) to the monitoring period or the period. If there is a monitoring target VM for which monitoring information has not arrived within a predetermined time, the process proceeds to step S13. If there is no monitoring target VM for which the monitoring information has not arrived within the predetermined time, the process proceeds to step S16.

  (S13) The VM monitoring unit 131 sets an auto-scale VM operating flag in the VM management table 122 for the monitoring target VM that is determined in step S12 that the monitoring information has not arrived within a predetermined time since the last monitoring information collection. Is set to “False”. In the case of “False” originally, it can be left as it is.

  (S14) The VM monitoring unit 131 refers to the autoscale server management table 121 and determines whether or not the operating flag is “True”. If the operating flag is “True”, the process proceeds to step S16. If the operating flag is “False”, the process proceeds to step S15.

  (S15) The VM monitoring unit 131 sets the autoscale information update flag of the VM management table 122 to “True” for the monitoring target VM for which the autoscale VM operation flag is set to “False” in step S13.

  (S16) The VM monitoring unit 131 determines whether or not to continue monitoring. When monitoring is continued, the process waits for the monitoring period and the process proceeds to step S10. If the monitoring is not continued, the VM monitoring process ends. For example, the VM monitoring unit 131 determines that the monitoring is not continued when an input of the monitoring end by the system administrator is received, and determines that the monitoring is continued in other cases.

FIG. 12 is a flowchart illustrating an example of autoscale server monitoring.
The AS server cooperation unit 132 periodically executes the following processing. The execution cycle is determined according to the operation. The period may be about several seconds to several tens of seconds, or about 1 minute to several minutes.

  (S20) The AS server cooperation unit 132 refers to the VM state of the autoscale server 200. Specifically, the AS server cooperation unit 132 inquires of the autoscale server 200 about the VM state of each virtual machine in the VM table 212.

  (S21) The AS server cooperation unit 132 determines whether or not the autoscale server 200 is operating. If the autoscale server 200 is operating, the process proceeds to step S23. If the autoscale server 200 is not operating, that is, if it is stopped, the process proceeds to step S22. For example, if there is a response from the autoscale server 200 to the inquiry in step S20, the AS server cooperation unit 132 determines that the autoscale server 200 is operating. Moreover, the AS server cooperation part 132 determines with the auto scale server 200 having stopped, when there is no response of the auto scale server 200 with respect to the inquiry of step S20.

  (S22) The AS server cooperation unit 132 sets the operating flag of the autoscale server management table 121 to “False”. In the case of “False” originally, it can be left as it is. Then, the process proceeds to step S27.

(S23) The AS server cooperation unit 132 sets the operating flag of the autoscale server management table 121 to “True”. In the case of “True” originally, it can be left as it is.
(S24) The AS server cooperation unit 132 determines whether there is a monitoring target VM whose autoscale information update flag in the VM management table 122 is “True”. If there is a monitoring target VM whose autoscale information update flag is “True”, the process proceeds to step S25. If there is no monitoring target VM whose autoscale information update flag is “True”, the process proceeds to step S27.

  (S25) The AS server cooperation unit 132 updates the VM state managed by the autoscale server 200 based on the autoscale VM operating flag in the VM management table 122 of the monitoring server 100. Specifically, the AS server cooperation unit 132 transmits information on the monitoring target VM whose autoscale information update flag is “True” (information indicating the autoscale VM operating flag “False”) to the autoscale server 200. To do.

  (S26) The AS server cooperation unit 132 sets the autoscale information update flag in the VM management table 122 to “False”. Specifically, the AS server cooperation unit 132 changes the part where the autoscale information update flag is “True” in Step S24 to “False”.

  (S27) The AS server cooperation unit 132 detects the occurrence of an abnormality according to the VM state of each monitoring target VM acquired from the autoscale server 200, and notifies the system administrator of the abnormality. For example, the AS server cooperation unit 132 determines that the virtual machine in which the autoscale VM operation flag is “False” in the VM management table 122 and the VM state confirmed by the autoscale server 200 is not “stop due to scale-in” is abnormal. judge. For example, the AS server cooperation unit 132 may display an image indicating abnormality on the display 111. Alternatively, the AS server cooperation unit 132 may transmit a message indicating an abnormality to the terminal device used by the system administrator. When step S27 is executed via step S22, the AS server cooperation unit 132 cannot acquire the VM state from the autoscale server 200. In this case, the AS server cooperation unit 132 may skip step S27 and execute step S28. Alternatively, the AS server cooperation unit 132 regards the virtual machine with the auto-scale VM operation flag “False” as abnormal without exceptionally confirming with the auto-scale server 200, and notifies the system administrator of the abnormality of the virtual machine. May be notified.

  (S28) The AS server cooperation unit 132 determines whether or not to continue monitoring. When monitoring is continued, the process waits for the monitoring period and the process proceeds to step S20. If the monitoring is not continued, the autoscale server monitoring process ends. For example, the AS server cooperation unit 132 determines that the monitoring is not continued when an input of the monitoring end by the system administrator is received, and determines that the monitoring is continued in other cases.

Next, an example of monitoring by the monitoring server 100 will be described.
FIG. 13 is a diagram illustrating an example of monitoring by the monitoring server.
In order to simplify the description, among the items in the VM management table 122, the VM name and the VM operating flag (corresponding to the auto-scale VM operating flag) are shown, and the other items are not shown. In addition, among the items of the VM table 212, the VM name and the VM state are illustrated, and illustration of other items is omitted. In addition, the virtual machine with the VM name “VM1” is represented as a virtual machine VM1 (other VM names are also represented in the same manner).

  First, consider the case where the autoscale server 200 is in operation (step ST11). According to the VM management table 122, the VM operating flag of the virtual machine VM1 at this stage is “True”. The VM operating flag of the virtual machine VM2 is “False”. The VM operating flag of the virtual machine VM3 is “True”. The VM operating flag of the virtual machine VM4 is “True”. On the other hand, according to the VM table 212, the VM state of the virtual machine VM1 is “normal”. The VM state of the virtual machine VM2 is “scale-in degeneration”. The VM state of the virtual machine VM3 is “normal”. The VM state of the virtual machine VM4 is “normal”. Since the VM operating flag of the virtual machine VM2 is “False” in the VM management table 122, the monitoring server 100 inquires of the autoscale server 200 about the VM state of the virtual machine VM2. Based on the VM table 212, the autoscale server 200 responds to the monitoring server 100 with the VM state “scale-in degeneration” of the virtual machine VM2. In this case, the monitoring server 100 does not regard the failure to acquire the monitoring information from the virtual machine VM2 as an abnormality.

  Then, consider a case where the autoscale server 200 is stopped (step ST12). The VM table 212 is held in a non-volatile storage device (for example, HDD) of the autoscale server 200 even while the autoscale server 200 is stopped. The monitoring server 100 detects that the autoscale server 200 has stopped by detecting that there is no response from the autoscale server 200 in response to a periodic inquiry about the VM state to the autoscale server 200.

  The monitoring server 100 detects that communication with the virtual machine VM4 is not possible. Then, the monitoring server 100 updates the VM management table 122 to the VM management table 123 by changing the VM operating flag of the virtual machine VM4 to “False” in the VM management table 122. Since the monitoring server 100 changes the VM operating flag from “True” to “False” for the virtual machine VM4 while the autoscale server 200 is stopped, the autoscale information update flag (not shown in FIG. 13) is displayed. Is set to “True”.

  After that, consider the case where the autoscale server 200 is restored (step ST13). For example, the monitoring server 100 detects activation of the autoscale server 200 by detecting that a response from the autoscale server 200 has been resumed in response to a periodic inquiry about the VM state to the autoscale server 200. The response includes that the virtual machine VM4 is “normal” (however, different from the actual state). When the monitoring server 100 receives the response of the VM state from the autoscale server 200, the monitoring server 100 detects that the stop of the virtual machine VM4 is not stop due to the scale-in, and notifies the system administrator of the abnormality of the virtual machine VM4.

  Based on the VM management table 123, the monitoring server 100 notifies the autoscale server 200 that the communication with the virtual machine VM4 has been detected while the autoscale server 200 is stopped. The auto scale server 200 updates the VM table 212 to the VM table 214 by changing the VM state of the virtual machine VM4 in the VM table 212 to “ERROR” in response to the notification. Then, the autoscale server 200 resumes autoscale control of each virtual machine using the VM table 214.

  Note that the monitoring server 100 detects an abnormality of the virtual machine VM4 at the timing when “ERROR” is acquired as the VM state of the virtual machine VM4 from the autoscale server 200, not at the timing when the activation of the autoscale server 200 is detected. The administrator may be notified.

Next, a comparative example of monitoring will be described.
FIG. 14 is a diagram illustrating a comparative example of monitoring.
In the comparative example, a system including a monitoring server 700 that monitors a virtual machine and an autoscale server 800 that performs autoscale control on the virtual machine is considered. However, the monitoring server 700 does not have a function to cooperate with the autoscale server 800.

  The monitoring server 700 stores a VM monitoring table 701 that manages the alive monitoring status of each virtual machine. In the VM monitoring table 701, a VM name and a VM operation flag are recorded. The VM operation flag indicates that “True” is operating and “False” is stopped.

The autoscale server 800 stores a VM state table 801 that manages the state of each virtual machine. In the VM state table 801, a VM name and a VM state are recorded.
First, consider the case where the autoscale server 800 is in operation (step ST21). According to the VM monitoring table 701, the VM operating flag of the virtual machine VM1 is “True” at this stage. The VM operating flag of the virtual machine VM2 is “False”. The VM operating flag of the virtual machine VM3 is “True”. The VM operating flag of the virtual machine VM4 is “True”. On the other hand, according to the VM state table 801, the VM state of the virtual machine VM1 is “normal”. The VM state of the virtual machine VM2 is “scale-in degeneration”. The VM state of the virtual machine VM3 is “normal”. The VM state of the virtual machine VM4 is “normal”. Since the VM operating flag of the virtual machine VM2 is “False” in the VM monitoring table 701, the monitoring server 700 inquires of the autoscale server 800 about the VM state of the virtual machine VM2. The autoscale server 800 responds to the monitoring server 700 with the VM state “scale-in degeneration” of the virtual machine VM2 based on the VM state table 801. In this case, the monitoring server 700 does not regard the failure to acquire monitoring information from the virtual machine VM2 as an abnormality.

  Then, consider a case where the autoscale server 800 is stopped (step ST22). The VM state table 801 is held in a non-volatile storage device (for example, HDD) of the autoscale server 800 even while the autoscale server 800 is stopped. The monitoring server 700 detects that the autoscale server 800 has stopped by detecting that there is no response from the autoscale server 800 in response to a periodic inquiry about the VM state to the autoscale server 800.

  The monitoring server 700 detects that communication with the virtual machine VM4 is not possible. Then, the monitoring server 700 updates the VM monitoring table 701 to the VM monitoring table 702 by changing the VM operating flag of the virtual machine VM4 to “False” in the VM monitoring table 701.

  After that, consider the case where the autoscale server 800 is restored (step ST23). For example, the monitoring server 700 detects the start of the autoscale server 800 by detecting that the response from the autoscale server 800 has been resumed in response to a periodic inquiry about the VM state to the autoscale server 800. When the monitoring server 700 detects that the VM state of the virtual machine VM4 is “normal” (but different from the actual state) based on the response of the VM state and is not stopped due to scale-in, the system administrator Is notified of the abnormality of the virtual machine VM4.

  The autoscale server 800 resumes autoscale control using the VM state table 801. In the VM state table 801, the virtual machine VM4 is managed as “normal”. For this reason, the autoscale server 800 cannot appropriately perform autoscale control for the autoscale group to which the virtual machine VM4 belongs. In addition, it may take 10 minutes to several tens of minutes for the autoscale server 800 to detect an abnormality in the virtual machine VM4. During this time, if the processing load of the application used by the user increases, appropriate scale-out cannot be performed, and there is a risk that the processing will be delayed.

  On the other hand, according to the cluster system of the second embodiment, when the monitoring server 100 and the autoscale server 200 are linked and the autoscale server 200 is started, the monitoring server 100 sends the latest virtual machine information to the autoscale server. 200. For this reason, the autoscale server 200 can recover with the latest virtual machine information and resume autoscale control. For this reason, the virtual machine stopped while the autoscale server 200 is stopped can be properly grasped by the autoscale server 200, and the autoscale control can be restarted appropriately. As a result, the influence on the processing of the application used by the user can be suppressed.

[Third Embodiment]
Next, a third embodiment will be described. Items that differ from the second embodiment described above will be mainly described, and descriptions of common items will be omitted.

  In the example of the second embodiment, the virtual machine to be controlled by the autoscale server 200 and the virtual machine to be monitored by the monitoring server 100 match. You can also monitor virtual machines that are not controlled.

FIG. 15 is a diagram illustrating an example of a virtual machine according to the third embodiment.
For example, consider that the physical server 300 executes the virtual machines 310 and 320, and the physical server 400 executes the virtual machines 410, 420, and 430. Among these, virtual machines 310, 320, 410, and 420 are objects to be controlled by the autoscale server 200. The virtual machine 430 is not subject to autoscale control by the autoscale server 200. On the other hand, the monitoring targets by the monitoring server 100 are virtual machines 310, 320, 410, 420, and 430.

  As described above, the range of the virtual machine to be controlled by the autoscale server 200 and the range of the virtual machine to be monitored by the monitoring server 100 may not match. When the monitoring server 100 detects that communication with the virtual machine is disabled by alive monitoring for a virtual machine that is not subject to autoscale control, the monitoring server 100 checks the virtual machine for an abnormality without checking the autoscale status of the virtual machine. Detect and notify the system administrator. The monitoring server 100 manages whether or not the virtual machine to be monitored is an autoscale control target by using the VM management table.

FIG. 16 is a diagram illustrating an example of the VM management table.
The VM management table 124 is stored in the storage unit 120. The VM management table 124 includes items of an auto scale availability flag, a VM name, a communication IP address, an auto scale VM operating flag, and an auto scale information update flag.

  Information indicating whether or not the corresponding virtual machine is subject to autoscale control is registered in the autoscale availability flag item. When the corresponding virtual machine is subject to autoscale control, the autoscale availability flag is “target”. When the corresponding virtual machine is not subject to autoscale control, the autoscalability flag is “not subject”.

  The information registered in the items of the VM name, the communication IP address, the autoscale VM operating flag, and the autoscale information update flag is the same as the information registered in the item of the same name in the VM management table 122. However, the items of the autoscale VM operating flag and the autoscale information update flag are not set when the autoscale availability flag is “not applicable” (in the figure, “not set” is indicated by a hyphen symbol “−”).

  For example, in the VM management table 124, the autoscale availability flag is “not applicable”, the VM name is “VMMnomal”, the communication IP address is “110.10.1.1.1”, and the autoscale VM operating flag is not set. ("-"), A record that the autoscale information update flag is not set ("-") is registered. This record indicates that the virtual machine with the VM name “VMMormal” is not subject to autoscale control and the IP address of the virtual machine is “110.10.1.1.1”.

  Further, for example, in the VM management table 124, the autoscale availability flag is “target”, the VM name is “Grp1_VM1”, the communication IP address is “100.10.99.1”, and the autoscale VM operating flag is “ “True” and an autoscale information update flag of “False” are registered. This record indicates that the virtual machine with the VM name “Grp1_VM1” is an autoscale control target. Further, it indicates that the communication IP address of the virtual machine is “100.10.99.1”. Furthermore, it indicates that the virtual machine is running and the autoscale VM operation flag is not updated while the autoscale server 200 is stopped.

  Next, a VM monitoring processing procedure by the VM monitoring unit 131 using the VM management table 124 will be described. In the third embodiment, the VM monitoring unit 131 executes the following procedure instead of the VM monitoring procedure described with reference to FIG.

FIG. 17 is a flowchart illustrating an example of VM monitoring.
The VM monitoring unit 131 periodically executes the following processing. The execution cycle is determined according to the operation. The period may be about several seconds to several tens of seconds, or about 1 minute to several minutes.

  (S30) The VM monitoring unit 131 collects monitoring information of the virtual machine to be monitored (monitoring target VM). For example, the VM monitoring unit 131 collects monitoring information by receiving a predetermined packet for alive monitoring from a virtual machine to be monitored.

  (S31) The VM monitoring unit 131 updates the operation status of the monitoring target VM. Specifically, the VM monitoring unit 131 updates the VM management table 124 based on the monitoring information collection result in step S30. In other words, the VM monitoring unit 131 sets the auto-scale VM operating flag of the virtual machine for which the monitoring information has been collected (the alive monitoring packet has been received) to “True”. In the case of “True” originally, it can be left as it is.

  (S32) The VM monitoring unit 131 determines whether or not there is a monitoring target VM for which monitoring information has not arrived within a predetermined time since the last collection of monitoring information. The predetermined time is a period obtained by adding a relatively short time (a time shorter than the period) to the monitoring period or the period. If there is a monitoring target VM for which monitoring information has not arrived within a predetermined time, the process proceeds to step S33. If there is no monitoring target VM for which the monitoring information has not arrived within the predetermined time, the process proceeds to step S38.

  (S33) The VM monitoring unit 131 refers to the VM management table 124, and the auto-scalability flag of the monitoring target VM for which the monitoring information has not arrived within a predetermined time since the last monitoring information collection is “target”. It is determined whether or not. If it is “target”, the process proceeds to step S35. If it is not “target” (ie, “not target”), the process proceeds to step S34.

  (S34) The VM monitoring unit 131 notifies the system administrator of the abnormality of the corresponding virtual machine. For example, the VM monitoring unit 131 may display an image indicating abnormality on the display 111. Alternatively, the VM monitoring unit 131 may transmit a message indicating an abnormality to the terminal device used by the system administrator. Then, the process proceeds to step S38.

  (S35) The VM monitoring unit 131 sets an auto-scale VM operating flag in the VM management table 124 for the monitoring target VM that is determined in step S32 that the monitoring information has not arrived within a predetermined time since the last monitoring information collection. Is set to “False”. In the case of “False” originally, it can be left as it is.

  (S36) The VM monitoring unit 131 refers to the autoscale server management table 121 and determines whether or not the operating flag is “True”. If the operating flag is “True”, the process proceeds to step S38. If the operating flag is “False”, the process proceeds to step S37.

  (S37) The VM monitoring unit 131 sets the autoscale information update flag of the VM management table 124 to “True” for the monitoring target VM for which the autoscale VM operation flag is set to “False” in step S35.

  (S38) The VM monitoring unit 131 determines whether or not to continue monitoring. When monitoring is continued, the process waits for the monitoring period and the process proceeds to step S30. If the monitoring is not continued, the VM monitoring process ends. For example, the VM monitoring unit 131 determines that the monitoring is not continued when an input of the monitoring end by the system administrator is received, and determines that the monitoring is continued in other cases.

In the third embodiment, the AS server cooperation unit 132 also cooperates with the autoscale server 200 according to the autoscale server monitoring procedure of FIG.
Thereby, when the autoscale server 200 stops and is restored, the autoscale server 200 can be restored based on the latest information of the virtual machine.

  Furthermore, the monitoring server 100 can perform monitoring by distinguishing a virtual machine that is subject to autoscale control and a virtual machine that is not subject to autoscale control based on the autoscalability flag in the VM management table 124. For virtual machines that are not subject to auto-scaling control, the monitoring server 100 can omit an inquiry about auto-scaling to the auto-scaling server 200 and can quickly notify the abnormality of the virtual machine.

  The information processing according to the first embodiment can be realized by causing the processing unit 12 to execute a program. The information processing of the second and third embodiments can be realized by causing the CPU 101 to execute a program. The program can be recorded on a computer-readable recording medium 113.

  For example, the program can be distributed by distributing the recording medium 113 on which the program is recorded. Alternatively, the program may be stored in another computer and distributed via a network. For example, the computer stores (installs) a program recorded in the recording medium 113 or a program received from another computer in a storage device such as the RAM 102 or the HDD 103, and reads and executes the program from the storage device. Good.

DESCRIPTION OF SYMBOLS 1 Cluster system 10 Autoscale server monitoring apparatus 11,21 Memory | storage part 12,22 Processing part 20 Autoscale server 30,40 Physical server 31,32,41,42 Virtual machine 50 Network 61,62,71,72 Table

Claims (8)

A physical server capable of running multiple virtual machines;
An autoscale server that performs scale-in and scale-out of virtual machines in the physical server;
Periodically communicating with the autoscale server, storing information on the virtual machine managed by the autoscale server, and detecting that the autoscale server has stopped, in response to a request from the autoscale server, An autoscale server monitoring device that transmits virtual machine information;
A cluster system. The autoscale server monitoring device detects that communication with the virtual machine is disabled while the autoscale server is stopped, and displays information indicating that communication with the virtual machine is disabled when the autoscale server is started. Send to the scale server,
The cluster system according to claim 1. The autoscale server stores state information indicating the state of the virtual machine, updates the state information in accordance with the virtual machine information transmitted by the autoscale server monitoring apparatus, and the updated state information Resuming control of the scale-in and the scale-out based on
The cluster system according to claim 1. When the autoscale server monitoring device detects that communication with the virtual machine is disabled, the autoscale server monitoring device detects an abnormality of the virtual machine in response to an inquiry to the autoscale server as to whether or not the virtual machine has been stopped due to the scale-in. Detect
The cluster system according to claim 1. The plurality of virtual machines include other virtual machines that are outside the scope of the scale-in and scale-out control by the autoscale server,
When the autoscale server monitoring device detects the inability to communicate with the other virtual machine, the autoscale server detects the abnormality of the other virtual machine by omitting the inquiry to the autoscale server.
The cluster system according to claim 4. A storage unit for storing information on virtual machines managed by the autoscale server;
When periodically communicating with the autoscale server and detecting that the autoscale server has stopped, a processing unit that transmits information on the virtual machine in response to a request from the autoscale server;
An autoscale server monitoring device. Communicates regularly with the autoscale server, stores information on virtual machines managed by the autoscale server,
Upon detecting that the autoscale server has stopped, the virtual scale information is transmitted in response to a request from the autoscale server.
An autoscale server monitoring program that causes a computer to execute processing. Computer
Communicates regularly with the autoscale server, stores information on virtual machines managed by the autoscale server,
Upon detecting that the autoscale server has stopped, the virtual machine information is transmitted in response to the request from the autoscale server.
Autoscale server monitoring method.

Images