JP2018081428A - Monitoring apparatus, monitoring program, and monitoring method - Google Patents

Abstract

PROBLEM TO BE SOLVED: To provide a monitoring apparatus capable of efficiently monitoring a virtual infrastructure to detect failures.SOLUTION: A monitoring apparatus according to the present invention monitors a failure of a first physical machine on which a virtual machine operates, and when detecting the failure, moves the virtual machine on the first physical machine to a second physical machine to perform failure recovery. The monitoring apparatus comprises: (1) reception means for receiving a notification indicating the failure actively transmitted from the first physical machine; (2) determination means for determining, when receiving the notification indicating the failure, that it is the failure of the first physical machine on the basis of a parameter of the notification indicating the failure and a pre-registered failure condition; and (3) failure recovery means for moving the virtual machine on the first physical machine to the second physical machine to perform the failure recovery when it is determined that it is the failure of the first physical machine by the determination means.SELECTED DRAWING: Figure 1

Description

  The present invention relates to a monitoring device, a monitoring program, and a monitoring method, and can be applied to, for example, a monitoring device that monitors base software (hypervisor) / hardware (physical machine: PM) that constitutes a virtual environment.

  In recent years, virtualization technology has been widely applied to server devices (for example, SIP (Session Initiation Protocol) server). Virtualization technology provides a method for effectively utilizing surplus resources. By applying virtualization technology, regardless of the physical configuration, the resources are dynamically allocated among virtual machines (VMs) that execute server functions according to the load, thereby maximizing the processing capacity of hardware. A virtual environment to be demonstrated is constructed.

  By the way, in a virtual environment, a failure of hardware (PM) that constitutes a virtualization infrastructure may lead to a service stop of a plurality of service components (virtual machines).

  Therefore, in a virtual environment, the occurrence of a hardware failure is monitored, the occurrence of a hardware failure is automatically detected, and the virtual machine that was running on the failed PM is restored with another PM (PM healing) There is an automatic recovery function (see Patent Document 1).

  In general, the automatic recovery function is: (1) failure detection (2) confirmation that the cause of failure is PM failure (3) power off of broken PM (4) recovery from spare PM (5) The virtual machine on the failed PM is moved to the recovery PM. (6) The process is realized by six processes (functions) for starting programs to be run on the virtual machine.

Japanese Patent Laying-Open No. 2015-176168

  However, in the conventional monitoring and recovery technique, there are mainly the following two problems.

  First, since a failure is detected by periodically collecting information between PMs (or between PMs and monitoring devices), a monitoring mechanism (active monitoring) and prevention of false detection are required. Second, since the process is performed after a PM failure (hardware failure) or a system down is detected, the failure cannot be detected in advance and the recovery cannot be performed.

  Therefore, a monitoring device, a monitoring program, and a monitoring method that can efficiently monitor the virtualization infrastructure and detect a failure are desired.

  The first aspect of the present invention monitors the failure of the first physical machine on which the virtual machine operates, and when a failure is detected, the virtual machine on the first physical machine is moved to the second physical machine to recover the failure. (1) receiving means for receiving a notification indicating a failure actively transmitted from the first physical machine; and (2) when a notification indicating the failure is received, Determination means for determining that a failure is a failure of the first physical machine based on a notification parameter indicating a failure and a failure condition registered in advance; and (3) the failure is determined by the determination means. If it is determined that the physical machine is faulty, it has fault recovery means for recovering the fault by moving the virtual machine on the first physical machine to the second physical machine.

  The monitoring program of the second aspect of the present invention monitors the failure of the first physical machine on which the virtual machine operates, and moves the virtual machine on the first physical machine to the second physical machine when the failure is detected. And (1) receiving means for receiving a notification indicating a failure actively transmitted from the first physical machine, and (2) a notification indicating the failure. When received, a determination unit that determines that the failure is a failure of the first physical machine based on a notification parameter indicating the failure and a failure condition registered in advance, and (3) by the determination unit, When it is determined that the failure is a failure of the first physical machine, the virtual machine on the first physical machine is moved to the second physical machine to function as a failure recovery unit that performs failure recovery. With features That.

  The third aspect of the present invention monitors the failure of the first physical machine on which the virtual machine operates, and when the failure is detected, the virtual machine on the first physical machine is moved to the second physical machine to recover the failure. A monitoring method for use in a monitoring device that performs reception, comprising: a receiving unit, a determining unit, and a failure recovery unit; (1) the receiving unit detects a fault actively transmitted from the first physical machine; (2) When the notification indicating the failure is received, the determination unit determines that the failure is based on a parameter of the notification indicating the failure and a failure condition registered in advance. (3) When the failure recovery unit determines that the failure is a failure of the first physical machine, the failure recovery unit determines whether the failure on the first physical machine is a virtual machine failure. Move the machine to the second physical machine And performing disaster recovery.

  According to the present invention, it is possible to efficiently monitor a virtualization infrastructure and detect a failure.

It is the block diagram shown about the functional structure of the monitoring apparatus which concerns on embodiment. It is a block diagram which shows the example of whole structure of the monitoring recovery system which concerns on embodiment. It is a figure which shows an example of the failure condition which concerns on embodiment. It is a flowchart which shows operation | movement of the monitoring recovery system (monitoring apparatus) which concerns on embodiment. It is a figure which shows the image which the monitoring apparatus which concerns on embodiment restores the virtual machine which was operate | moving on PM which detected generation | occurrence | production of a failure. It is a figure explaining the operation | movement of FIG. 4 based on the specific example of the SNMP trap which concerns on embodiment.

(A) Main Embodiments Hereinafter, embodiments of a monitoring device, a monitoring program, and a monitoring method of the present invention will be described in detail with reference to the drawings.

(A-1) Configuration of Embodiment (A-1-1) Overall Configuration FIG. 2 is a block diagram illustrating an example of the overall configuration of the monitoring and recovery system according to the embodiment.

  In FIG. 2, the monitoring and recovery system 1 includes a monitoring device 2 and three physical machines (PM) 3 (3-1 to 3-3). Of course, the number of PM3 is not limited. In addition, the monitoring device 2 and PM3 are connected to the network N. Although the communication system of the network N is not limited, for example, an IP communication network or the like can be applied. In this embodiment, the monitoring device 2 uses the SNMP (Simple Network Management Protocol) protocol to monitor PM3 as a monitoring target. However, the present invention is not limited to this, and various protocols are used. Can be used.

  The monitoring device 2 monitors an SNMP trap indicating a failure of the PM 3 (including the hypervisor 31 constituting the virtual environment), and executes a recovery operation set in advance when the failure is detected.

  The PM 3 is a device that operates a virtual machine (VM) 32 that virtualizes a computer and provides various services to a user, and is, for example, a server computer. The PM 3 operates a plurality of virtual machines 32 on the hypervisor 31 by executing a server virtualization program.

(A-1-2) Detailed Configuration of Monitoring Device 2 FIG. 1 is a block diagram showing the configuration of the monitoring device of the embodiment.

  In FIG. 1, the monitoring device 2 includes a trap receiver 21 and a PM healing / automatic recovery unit 22.

  The trap receiver 21 receives an SNMP trap from the monitoring target PM3. The trap receiving unit 21 notifies the received SNMP trap information to the PM healing / automatic recovery unit 22. The information to be notified is, for example, “trap ID” for identifying the SNMP trap, “parameter” indicating the detailed information notified by the SNMP trap, and the like.

  The PM healing / automatic recovery unit 22 includes an execution condition determination unit 23, a maintenance person notification unit 24, and a VM recovery unit 25.

  The execution condition determination unit 23 performs comparison determination between the SNMP trap information notified from the trap reception unit 21 and a preset automatic recovery execution condition (failure condition T). FIG. 3 is a diagram illustrating an example of a failure condition according to the embodiment. In FIG. 3, the failure condition T includes a “trap ID” indicating an ID (snmpTrap OID) for identifying an SNMP trap, and a “parameter number” indicating a parameter number used for condition determination among parameters included in the SNMP trap. , “Threshold” indicating a threshold used for determination of the parameter number, “condition” indicating a condition (match, mismatch, above, less than) for determining the threshold, and “occurrence count” indicating the occurrence count per unit time In addition, it has an “action” item indicating an action (automatic recovery, stop, notification of maintenance personnel, etc.) to be executed when the conditions are matched.

  The execution condition determination unit 23 searches for data that matches the failure condition T using the trap ID of the received SNMP trap information as a key. For example, when the notified trap ID is 0001, the data in the first row of the failure condition T (data in which the item of “trap ID” is 0001) matches. Next, the execution condition determination unit 23 compares the value of the designated location (“parameter number”) among the parameters of the received SNMP trap information according to the items of “threshold value”, “condition”, and “occurrence number”. To do. For example, if the received trap ID is 0001, the value of the second parameter among the received parameters matches the threshold (100), and the same notification has occurred 10 times within 30 seconds. Is determined to be a failure. Note that the “occurrence number” of the data in the 2nd to 4th rows in the failure condition T in FIG. Further, as a modification, when a plurality of SNMP traps having different trap IDs are received, it may be determined that PM3 has failed. The setting of the failure condition T shown in FIG. 3 is merely an example, and comparison conditions such as the number (position) of the parameter to be determined, the determination threshold value, match / mismatch / magnitude can be freely set in advance.

  When the execution condition determination unit 23 determines that the condition is met, the maintenance person notification unit 24 or the VM recovery unit 25 described later executes the designated “action”.

  The maintenance person notification unit 24 is a functional unit that notifies a maintenance person who manages the system. A variety of means can be used as means for notifying the maintenance person. For example, a screen indicating that a failure (or sign of failure) of PM3 has occurred may be displayed on the display screen of the monitoring device 2. Alternatively, an e-mail describing the contents of the failure may be transmitted to the maintenance person's computer, smartphone, tablet terminal, or the like.

  The VM recovery unit 25 is a functional unit that performs recovery processing of the VM 32 that was operating on the PM 3 in which a failure has occurred. The recovery process of the VM recovery unit 25 is executed using an API (Application Programming Interface), and details will be described in the operation section described later.

(A-2) Operation | movement of embodiment Next, operation | movement of the monitoring recovery system 1 of embodiment which has the above structures is demonstrated.

  FIG. 4 is a flowchart showing the operation of the monitoring and recovery system (monitoring device) according to the embodiment.

  When the monitoring device 2 (trap receiving unit 21) receives the SNMP trap from the PM machine 3 (PM machine 3-2 in the example of FIG. 2), the received SNMP trap information (trap ID, parameters, etc.) The PM healing / automatic recovery unit 22 (execution condition determination unit 23) is notified (S101).

  The PM healing / automatic recovery unit 22 (execution condition determination unit 23) searches whether the received SNMP trap (trap ID) is included in the failure condition T (S102). The execution condition determination unit 23 performs the next process if the trap ID is included in the failure condition T, and ends the determination process if the trap ID is not included.

  The execution condition determination unit 23 determines whether or not the number of received SNMP parameters is equal to or greater than the parameter number of the failure condition T (parameter number of data searched using the trap ID as a key) (in other words, the parameter number of the failure condition) (S103). The execution condition determination unit 23 performs the following process when the number of received SNMP parameters is equal to or greater than the parameter number of the failure condition T, and ends the determination process when the condition is not satisfied.

  The execution condition determination unit 23 determines whether or not the received trap parameter corresponding to (positioned to) the parameter number of the corresponding data of the failure condition T matches the threshold and the condition of the failure condition T (S104). The execution condition determination unit 23 performs the following process if the reception parameter at the corresponding position matches the threshold value and the condition of the failure condition T, and ends the determination process if it does not match.

  The execution condition determination unit 23 determines whether the number of occurrences is set in the corresponding data of the failure condition T (S105). The execution condition determination unit 23 performs the next process if the number of occurrences is set in the corresponding data of the failure condition T, and executes the process of step S108 described later if not set.

  The execution condition determination unit 23 updates the number of failure occurrences (S106). Although the method of managing the number of occurrences of failures is not limited, for example, the execution condition determining unit 23 determines the number of failure occurrences of a predetermined trap ID for each PM3 (3-1 to 3-3) as a unit. You may manage by the counter which counts per time.

  The execution condition determination unit 23 determines whether or not the number of occurrences of the failure updated by the processing in step S106 described above matches the number of occurrences of the corresponding data in the failure condition T (S107). The execution condition determination unit 23 performs the next process (the process of step S108) if it matches the corresponding data of the failure condition T, and ends the process if it does not match.

  When the PM healing / automatic recovery unit 22 (maintenance person notification unit 24, VM recovery unit 25) finally determines that the failure condition is met (when a failure is detected), the failure condition T is met. An action related to the data is executed (S108). For example, if the action of the corresponding data in the failure condition T is VM recovery, the VM recovery unit 25 performs automatic recovery processing. FIG. 5 is a diagram illustrating an image in which the monitoring apparatus according to the embodiment restores the virtual machine that was operating on the PM that has detected the occurrence of the failure. First, the VM recovery unit 25 activates the PM service stop API, and cuts off the power of the PM 3-2 that has detected the occurrence of a failure. Next, the VM recovery unit 25 activates the virtual machine recovery API and moves the virtual machines (VM # 3, VM # 4) on the failed PM 3-2 to the recovery PM 3-3 (for example, storage The backup data of VM # 3 and VM # 4 stored in the storage device is copied). Then, the VM restoration unit 25 activates the virtual machine activation API, and activates programs to be operated on the VM (sets to an active state).

  FIG. 6 is a diagram illustrating the operation of FIG. 4 based on a specific example of the SNMP trap according to the embodiment. FIG. 6A is a diagram illustrating a specific example of trap information received from PM 3-2. FIG. 6B is a diagram illustrating the failure condition T described above. When the monitoring device 2 (execution condition determination unit 23) receives the SNMP trap of FIG. 6A from PM 3-2, the trap ID is “0001”, and therefore the top data of the failure condition T is hit (S102). . The execution condition determination unit 23 compares “2”, which is the parameter number of the first data hit, with the number of parameters (2) of the received SNMP trap, and determines that the second parameter exists (S103). ). The execution condition determination unit 23 determines that the second parameter value (2) of the received SNMP trap matches the threshold value (100) (S104). The execution condition determination unit 23 determines that the number of occurrences is set in the top data of the failure condition T (S105). If the condition for the number of occurrences is satisfied (S106), as described above, the VM recovery unit 25 performs an automatic recovery process (S108).

(A-3) Effects of Embodiment According to this embodiment, the following effects can be achieved.

  Periodic monitoring from the monitoring device 2 side is unnecessary, and passive monitoring is possible. In addition, the fault monitoring eliminates the need for having a monitoring function specialized for the hypervisor by using a general-purpose SNMP trap for monitoring and fault detection. Furthermore, the PM healing / automatic restoration unit 22 can perform reliable failure detection and prevent erroneous detection by setting the parameters (detailed contents) included in the SNMP trap to be evaluated. In addition, since the conditions (failure condition T) for performing the evaluation can be set in advance by the user, monitoring according to the environment and the service to be provided can be performed.

  The PM healing / automatic recovery unit 22 can perform detailed settings of actions by monitoring SNMP trap units and determining parameters. For example, for a failure whose notification content is not a fatal failure but needs to be prevented, an action can be performed by registering conditions such as the occurrence frequency. The action to be executed can be set freely by the user from among automatic recovery, stop, and notification.

  In this embodiment, as described with reference to FIG. 5 above, the monitoring device 2 provides the processing for restoring the VM as an API, so that the failed PM can be determined without depending on the specifications unique to the virtual environment. It is possible to stop, move the VM on the stopped PM to a recovery PM, or perform VM recovery processing.

DESCRIPTION OF SYMBOLS 1 ... Monitoring recovery system, 2 ... Monitoring apparatus, 3 ... Physical machine, 21 ... Trap receiving part, 22 ... Automatic recovery part, 23 ... Execution condition determination part, 24 ... Maintenance person notification part, 25 ... VM recovery part, 31 ... Hypervisor, 32 ... virtual machine, N ... network, T ... failure condition.

Claims (5)

A monitoring device that monitors a failure of a first physical machine on which a virtual machine operates and detects a failure, moves the virtual machine on the first physical machine to a second physical machine and performs failure recovery. ,
Receiving means for receiving a notification indicating a failure actively transmitted from the first physical machine;
When a notification indicating the failure is received, a determination unit that determines that the failure is a failure of the first physical machine based on a notification parameter indicating the failure and a failure condition registered in advance.
If the determination unit determines that the failure is a failure of the first physical machine, the failure recovery is performed by moving the virtual machine on the first physical machine to the second physical machine and recovering the failure. And a monitoring device. The notification indicating the actively transmitted failure is an SNMP trap;
The monitoring apparatus according to claim 1, wherein the failure condition has at least a threshold value to be compared with a notification parameter indicating the failure for each SNMP trap type.   The monitoring apparatus according to claim 1, wherein the failure recovery unit is configured using an API. It is mounted on a monitoring device that monitors the failure of the first physical machine on which the virtual machine operates and detects a failure, moves the virtual machine on the first physical machine to the second physical machine and recovers from the failure. Computer
Receiving means for receiving a notification indicating a failure actively transmitted from the first physical machine;
When a notification indicating the failure is received, a determination unit that determines that the failure is a failure of the first physical machine based on a notification parameter indicating the failure and a failure condition registered in advance.
If the determination unit determines that the failure is a failure of the first physical machine, the failure recovery is performed by moving the virtual machine on the first physical machine to the second physical machine and recovering the failure. A monitoring program characterized by functioning as a means. The failure of the first physical machine on which the virtual machine operates is monitored, and when a failure is detected, the virtual machine on the first physical machine is moved to the second physical machine and used for a monitoring apparatus that performs failure recovery. A monitoring method,
Having a receiving means, a judging means, and a failure recovery means,
The receiving means receives a notification indicating a failure actively transmitted from the first physical machine;
When the notification indicating the failure is received, the determination unit determines that the failure is a failure of the first physical machine based on a notification parameter indicating the failure and a failure condition registered in advance.
When the determination unit determines that the failure is a failure of the first physical machine, the failure recovery unit moves the virtual machine on the first physical machine to the second physical machine. A monitoring method characterized by performing failure recovery.

Images