JP2019008340A - Redundant system and hardware failure detection method - Google Patents

Abstract

To provide a hardware failure detection method capable of rapidly detecting a failure and having a small risk of false detection and a small monitoring load, for a redundant system.SOLUTION: In a redundant system 1 configured by including a host OS 21 that runs on a plurality of computers 2, each virtual machine 23, and duplex configuration applications executed by the virtual machine 23, a host OS monitoring unit 31 that monitors activity/inactivity of each host OS 21, and a representative application selecting unit 32 for selecting a representative application executed by the virtual machine 23 on the host OS 21, when it detects that the response of the host OS 21 has been interrupted, furthermore, for selecting a corresponding application to be paired, and an application state confirmation unit 33 for confirming whether a status of the selected corresponding application is in single-system operation or not, are provided.SELECTED DRAWING: Figure 1

Description

  The present invention relates to a redundant system and a hardware failure detection method.

  In recent cloud services, in order to increase aggregation efficiency, it is common to provide a plurality of logical computers (virtual machines) on the hardware of a physical computer using virtualization technology and provide them to tenant users. A logical computer generally refers to a VM (Virtual Machine).

Such a cloud service can be managed and operated by a virtual resource management function. In recent years, OpenStack (registered trademark: see Non-Patent Document 1) has been attracting attention as software responsible for the virtual resource management function.
It is possible to ensure the redundancy of the cloud service by linking the virtual resource management function and the function of monitoring the physical computer and logical computer constituting the cloud service. Hereinafter, such a system that ensures the redundancy of the cloud service is referred to as a redundant system.

FIG. 5 is a functional block diagram illustrating a configuration example of a redundant system according to a comparative example.
The redundancy system 1A includes computers 2-1 to 2-3, a monitoring device 3, a virtual resource management function 4, and a computer IP address list 41.
Since the redundancy system 1A of the comparative example requires high availability, it is duplexed between the active application and the standby application. Even in a virtualized environment, the active application and the standby application are executed by different VMs, and each VM is operated on a different computer to be duplicated to provide redundancy against a hardware failure.

The host OS 21-1 operates on the computer (physical computer) 2-1, and the hypervisor 22-1 operates on the host OS 21-1. The hypervisor 22-1 embodies VMs (virtual machines) 23-1 and 23-2. The VM 23-1 executes the active application A, and the VM 23-2 executes the standby application b for duplicating the active application B.
The host OS 21-2 operates on the computer (physical computer) 2-2, and the hypervisor 22-2 operates on the host OS 21-2. The hypervisor 22-2 embodies the VMs 23-3 and 23-4. The VM 23-3 executes the active application B, and the VM 23-4 executes the standby application c for duplicating the active application C.
The host OS 21-3 operates on the computer (physical computer) 2-3, and the hypervisor 22-3 operates on the host OS 21-3. The hypervisor 22-3 embodies VMs 23-5 and 23-6. The VM 23-5 executes the active application C, and the VM 23-6 executes the standby application a for duplicating the active application A.

  The computers 2-1 to 2-3 may be simply referred to as a computer 2. The host OS 21-1 to 21-3 may be simply referred to as the host OS 21. The hypervisors 22-1 to 22-3 may be simply referred to as the hypervisor 22. The VMs 23-1 to 23-6 may be simply referred to as VM23.

The monitoring device 3 monitors the life and death of one or both of the computer 2 and the VM 23.
As a life and death monitoring method, for example, a method of sending a ping and confirming the presence or absence of a response is simple and often used. In this method, the monitoring device 3 can detect a hardware failure of the computer 2 by transmitting a ping to a physical NIC (Network Interface Card) of the computer 2. The monitoring device 3 can also detect a hardware failure of the computer 2 by sending a ping to the virtual NIC of the VM 23. A response may be confirmed by sending a ping to both the computer 2 and the VM 23, or a response may be confirmed by sending it to only one side.
The IP address assigned to the NIC of the Ping destination is stored in the computer IP address list 41. The monitoring device 3 refers to the computer IP address list 41 and sends a ping to the NIC to be confirmed.

The virtual resource management function 4 manages the VM 23 embodied on the computer 2 in cooperation with the monitoring device 3.
With this configuration, when the monitoring device 3 detects a hardware failure of the computer 2, the virtual resource management function 4 deletes the VM 23 from the host OS 21 on the failed hardware, and on the host OS 21 on the different hardware. Can be regenerated. Such automatic deletion and regeneration of a VM may be hereinafter referred to as recovery processing or auto healing.

OpenStack Project, “OpenStack Open Source Cloud Computing Software”, [online], [Search June 16, 2017], Internet <URL: http://www.openstack.org/>

  If the system is composed only of physical computers, response delays to monitoring are unlikely to occur during normal operation. However, in a virtual environment in which a plurality of VMs coexist on one physical computer, the response delay varies greatly even when no hardware failure has occurred. Therefore, even if the physical computer and the VM are operating normally, there is a possibility that no response is returned within a predetermined time (timeout time). In that case, the monitoring device 3 may erroneously recognize that the response has been lost, and may erroneously detect a hardware failure.

  When such a false detection occurs, the virtual resource management function 4 automatically deletes the VM 23 and regenerates it on another host OS 21. Depending on the application, such measures may cause service interruption, load on computer processing and communication, and the like. Therefore, it should not be performed in such a case.

  In order to avoid auto-healing due to such erroneous detection of a failure, a method of extending the ping timeout time is also conceivable. However, with this method, since it takes a long time to detect a failure, recovery cannot be started quickly.

  As a hardware failure detection means, there is a method of periodically checking the status and acquiring a log for each application. However, the confirmation for each application has a larger response processing load and data transfer communication load than simple response confirmation by ping. Therefore, if each application is frequently checked in an environment where a plurality of VMs exist at the same time, a service failure may occur.

  The present invention has been made in view of such points, and it is an object of the present invention to provide a redundant system and a hardware failure detection method that can quickly detect a failure, have a low risk of erroneous detection, and have a small monitoring load. To do.

In order to solve the above-described problem, the invention according to claim 1
In a redundant system configured to include a host OS running on a plurality of physical computers, each virtual machine, and a duplex configuration application executed by the virtual machine,
A host OS monitoring unit that monitors the life and death of each of the host OSs;
If the host OS monitoring unit detects that the response of any of the host OSs is interrupted, it selects a representative application to be executed by the detected virtual machine on the host OS, and further selects a representative application pair. A representative application selection section for selecting a corresponding application,
An application state confirmation unit for confirming whether or not the state of the corresponding application selected by the representative application selection unit is in single system operation;
A redundant system characterized by comprising:

  In this way, the redundant system can reduce the risk of erroneously detecting a failure while suppressing the load during normal operation. Further, in this configuration, the state is inquired with respect to a virtual machine embodied on a normal computer, and the state is not inquired with respect to a virtual machine embodied on a computer suspected of a failure. As a result, it is possible to avoid further applying processing and communication loads to a computer suspected of being damaged.

In order to solve the above-described problem, the invention according to claim 2
If any one of the corresponding applications confirmed by the application status confirmation unit is in single system operation, the virtual machine on the host OS detected by the host OS monitoring unit is restored on another host OS. Recovery processing department,
The redundancy system according to claim 1 is provided.

  By doing in this way, the redundant system can perform only necessary auto healing based on highly accurate failure detection. Thereby, interruption of service, increase in the load of computer processing and communication, etc. can be avoided.

In order to solve the above-described problem, the invention according to claim 3
Representative application candidates storing correspondence relationships between each physical computer, the virtual machine embodied on the physical computer, a representative application executed by the virtual machine, and a corresponding application that is a pair of the representative application Database,
The redundancy system according to claim 1 is provided.

  In this way, the redundant system identifies the corresponding application that is paired with the representative application on the computer suspected of failure, and checks the status of the corresponding application. Thereby, the redundant system can detect a failure quickly.

In order to solve the above-described problem, the invention according to claim 4 provides:
A state confirmation logic for storing a state confirmation command for confirming whether the state of the representative application is in single system operation, and a response to the state confirmation command;
The redundancy system according to claim 1 is provided.

  By doing so, the redundant system can check the status of the corresponding application with the logic corresponding to the corresponding application to be checked. Even if the application has different status confirmation logic, the status can be confirmed.

In order to solve the above-described problem, the invention according to claim 5 provides:
Each of the virtual machines is embodied by a hypervisor operating on the host OS.
The redundant system according to claim 1 is provided.

  By doing in this way, the redundant system can apply a Type 2 hypervisor.

In order to solve the above-described problem, the invention according to claim 6 provides:
Each virtual machine that executes the application and a virtual machine that executes the host OS are embodied by a hypervisor operating on each physical computer.
The redundant system according to claim 1 is provided.

  By doing in this way, the redundant system can apply a Type 1 hypervisor.

In order to solve the above-described problem, the invention according to claim 7 provides:
In a redundant system configured to include a host OS running on a plurality of physical computers, each virtual machine, and a duplex configuration application executed by the virtual machine,
The host OS monitoring unit monitors the life and death of each host OS,
If the host OS monitoring unit detects that the response of any host OS has been interrupted, the representative application selection unit selects a representative application to be executed by the detected virtual machine on the host OS,
Select the corresponding application to be paired with the representative application,
The application status confirmation unit confirms whether the status of the corresponding application is in single system operation,
A hardware failure detection method for a redundant system characterized by this.

  In this way, the redundant system can reduce the risk of erroneously detecting a failure while suppressing the load during normal operation. Further, in this configuration, the state is inquired with respect to a virtual machine embodied on a normal computer, and the state is not inquired with respect to a virtual machine embodied on a computer suspected of a failure. As a result, it is possible to avoid further applying processing and communication loads to a computer suspected of having a failure.

In order to solve the above-described problem, the invention according to claim 8 provides:
If any one of the representative applications confirmed by the application state confirmation unit is in single system operation, the virtual machine on the host OS that has detected that the response has been interrupted is restored by the recovery processing unit. Recover on the host OS,
The hardware failure detection method for a redundant system according to claim 7 is characterized.

  By doing in this way, the redundant system can perform only necessary auto healing based on highly accurate failure detection. Thereby, interruption of service, increase in the load of computer processing and communication, etc. can be avoided.

  According to the present invention, it is possible to provide a redundant system and a hardware failure detection method that can quickly detect a failure, reduce the risk of erroneous detection, and reduce the monitoring load.

It is a functional block diagram which shows the structural example of the redundancy system which concerns on this embodiment. It is a flowchart of the hardware failure detection method which concerns on this embodiment. It is an example of the table of the status confirmation logic which concerns on this embodiment. It is a sequence diagram which shows the flow from execution of host OS monitoring which concerns on this embodiment to recovery processing. It is a functional block diagram which shows the structural example of the redundancy system of a comparative example.

  Next, the redundancy system 1 and the like in a mode for carrying out the present invention (hereinafter referred to as “the present embodiment”) will be described.

Since the redundancy system 1 of the present embodiment requires high availability, the redundancy system 1 is duplexed between an active application and a standby application. Even in a virtual environment, the active application and the standby application are executed by different VMs, and each VM is operated on a different computer, thereby providing redundancy for a hardware failure.
In the duplex configuration, when a failure occurs in one system, it is possible to check the operating state by inquiring to the other system that is normal. In this embodiment, using this property, a two-stage monitoring function using a duplex configuration application in a virtual environment is provided.

FIG. 1 is a functional block diagram showing a configuration example of a redundancy system 1 according to this embodiment.
The redundancy system 1 includes computers 2-1 to 2-3, a monitoring device 3, and a virtual resource management function 4.

The host OS 21-1 operates on the computer (physical computer) 2-1, and the hypervisor 22-1 operates on the host OS 21-1. The hypervisor 22-1 embodies VMs (virtual machines) 23-1 and 23-2.
The host OS 21-2 operates on the computer (physical computer) 2-2, and the hypervisor 22-2 operates on the host OS 21-2. The hypervisor 22-2 embodies the VMs 23-3 and 23-4.
The host OS 21-3 operates on the computer (physical computer) 2-3, and the hypervisor 22-3 operates on the host OS 21-3. The hypervisor 22-3 embodies VMs 23-5 and 23-6.

  The computers 2-1 to 2-3 may be simply referred to as a computer 2. The host OS 21-1 to 21-3 may be simply referred to as the host OS 21. The hypervisors 22-1 to 22-3 may be simply referred to as the hypervisor 22. The VMs 23-1 to 23-6 may be simply referred to as VM23.

  The virtual resource management function 4 includes a computer IP address list 41. Information of the VM 23 is stored and managed in the virtual resource management function 4.

  The monitoring device 3 includes a host OS monitoring unit 31, a representative application selection unit 32, a representative application candidate database 34, an application state confirmation unit 33, and a state confirmation logic 35. The monitoring device 3 is a function separate from the virtual resource management function 4. The virtual resource management function 4 can be deployed on the same computer or a different computer, and the deployment method is not limited. In the drawings, the database may be described as “DB”.

The active application A is executed by the VM 23-1 embodied on the computer 2-1. The standby application a that is a pair of the active application A is executed by the VM 23-6 embodied on the computer 2-3.
The active application B is executed by the VM 23-3 embodied on the computer 2-2. The standby application b that is a pair with the active application B is executed by the VM 23-2 embodied on the computer 2-1.
The active application C is executed by the VM 23-5 embodied on the computer 2-3. The standby application c that is a pair of the active application C is executed by the VM 23-4 embodied on the computer 2-2.
Thus, these applications are duplicated.

Duplicated applications A and a, B and b, and C and c regularly inquire (polling) the paired applications and hold the state of the paired applications.
The user stores information on the duplicated application in the representative application candidate database 34 in advance. Specifically, for example, the correspondence between the computer 2-1, the VM 23-1 embodied thereon, the representative application A executed by the VM 23-1, and the corresponding application a that is a pair of the representative application A Store relationships. Storage can be done in a known manner.
The representative application candidate can be stored, for example, when information of the VM 23 is stored in the virtual resource management function 4. In addition, when the number of representative application candidates is less than the number initially stored by the user due to deletion or the like, the representative application candidates can be additionally stored as needed.

The host OS monitoring unit 31 monitors the life and death of the host OS 21 common to all VMs 23 that are executing applications. Monitoring of the host OS 21 has a lower load than monitoring for each individual VM 23. For example, monitoring is performed by confirming a response by ping transmission, as in the existing technology. The host OS monitoring unit 31 acquires the IP address assigned to the physical NIC of the computer 2 from the computer IP address list 41. Based on the acquired IP address, a ping is periodically sent to the physical NIC of the computer 2 to check the response.
As a life and death monitoring method, a method of periodically transmitting keep alive from the host OS 21 to the host OS monitoring unit 31 may be employed, or the host OS may be monitored by other methods.

Consider a case where a response within a certain time is not obtained from the host OS 21-1.
At this time, it is suspected that a failure has occurred in the hardware of the computer 2-1. In order to confirm the failure, the representative application selection unit 32 selects one or more representative applications from the representative application candidate database 34. The selection method may be random, VM generation order, or any other method. In this example, the active application A executed by the VM 23-1 embodied on the computer 2-1 and the standby application b executed by the VM 23-2 are selected as representative applications.

Further, the representative application selection unit 32 specifies an application that is paired with the selected representative application and that is running on another computer 2 from the representative application candidate database 34. Such an application is hereinafter referred to as a corresponding application.
In this example, the standby application a to be executed by the VM 23-6 embodied on the computer 2-3 is specified as the application corresponding to the representative application A. Further, the active application B that is executed by the VM 23-3 embodied on the computer 2-2 is specified as the corresponding application of the representative application b.

For the corresponding application a and the corresponding application B, the application state confirmation unit 33 confirms the state and determines whether or not the one-system operation is in progress. As described above, the corresponding application confirms and holds the state of the representative application to be paired by polling. Therefore, the state of the representative application can be confirmed by checking the state of the corresponding application. If the corresponding application is in duplex operation, the representative application is in operation. If the corresponding application is in single system operation, the representative application is stopped.
The application status confirmation command and the abnormal state determination logic differ for each application. Therefore, it is assumed that the user stores an application-specific interface in the state confirmation logic 35 in advance. Details of the state confirmation logic 35 will be described later.

The application state confirmation unit 33 refers to the state confirmation logic 35 and confirms the state of the corresponding application with the logic corresponding to the corresponding application to be confirmed. As a result of confirmation, if it is found that only one of the corresponding applications is operating (single system operation) in any of the duplex configuration applications, the monitoring device 3 indicates that a failure has occurred in the hardware of the computer 2-1. judge.
Based on this determination, the virtual resource management function 4 deletes the VM 23-1 and the VM 23-2 embodied on the computer 2-1 and regenerates them on the host OS 21 other than the computer 2-1.

As shown in FIG. 1, the VM 23 of the present embodiment is embodied by a hypervisor 22 that operates on the host OS 21. Such a hypervisor is called a Type 2 hypervisor.
It is also possible to adopt a method of embodying a VM that executes an application and a VM that executes the host OS by a Type 1 hypervisor that operates on the computer without going through the host OS. Also in this case, hardware failure detection can be performed by the same method as in this embodiment.

FIG. 2 is a flowchart of the hardware failure detection method according to this embodiment.
First, the host OS monitoring unit 31 monitors the life and death of the host OS 21 (step S10). In practice, the host OS monitoring unit 31 monitors the life and death of the host OSs 21-1 to 21-3, but here, for the sake of simplification, the description will be made focusing on one host OS 21.

As a result of the monitoring, if there is a response within a certain time, the host OS monitoring unit 31 continues to perform monitoring periodically thereafter (step S10: response).
As a result of monitoring, when there is no response within a certain time (step S10: timeout), the host OS monitoring unit 31 detects that the response of the host OS 21 has been interrupted. The representative application selection unit 32 selects a representative application to be executed by the VM 23 on the host OS 21 based on the representative application candidate database 34 (step S11). The representative application selection unit 32 selects one or more representative applications for one computer.

  The monitoring device 3 repeats the processes in steps S12 to S15 for each selected representative application.

The contents of the repetition process are described below.
The representative application selection unit 32 specifies a corresponding application that is a pair of representative applications from the representative application candidate database 34 (step S13). Note that the application state confirmation unit 33 may specify the corresponding application.
For the identified corresponding application, the application state confirmation unit 33 performs state confirmation (step S14).

As a result of checking the status of the corresponding application, if it is a duplex operation (step S14: normal / duplex operation), it can be determined that the representative application is normal. In this case, the application state confirmation unit 33 determines that the monitoring result (timeout) is a false detection or a failure that remains in the communication path. Therefore, without shifting to the recovery process, the monitoring device 3 repeats the process for the next representative application (step S15).
In step S15, when no abnormality is detected for all the representative applications, the host OS monitoring unit 31 returns to the life / death monitoring for the host OS 21 again (step S10).
When the state is confirmed with respect to the representative application operating on the computer 2 suspected of malfunctioning, it is expected that the representative application does not respond or the response time becomes long. On the other hand, it is considered that the corresponding application that is a pair of representative applications is operating on the computer 2 that is operating normally. Thus, the corresponding application responds quickly. Thereby, the redundancy system 1 can detect a failure quickly.

As a result of checking the state of the corresponding application, if the single system operation is performed in which only the corresponding application is operating (step S14: abnormal / single system operation), it can be determined that a failure has occurred in the representative application. In this case, the application state confirmation unit 33 determines that the monitoring result (timeout) is due to a hardware failure of the computer 2, and proceeds to the recovery process in step S16.
In the recovery process, the virtual resource management function 4 deletes the VM 23 deployed in the host OS 21 on the failed computer 2 and regenerates the VM 23 on another host OS 21. Thereafter, the host OS monitoring unit 31 returns to monitoring the host OS 21 again (step S10).

FIG. 3 is an example of a table of the state confirmation logic 35 according to the present embodiment.
In this example, the state confirmation logic 35 stores a representative application (application type), a state confirmation command, and a normal confirmation logic in association with each other.
The application state confirmation unit 33 refers to the state confirmation logic 35 to execute a state confirmation command corresponding to the corresponding application to be confirmed, and perform normal confirmation using the normal confirmation logic.
Specifically, the application state confirmation unit 33 executes the state confirmation command Xxxxx for the application A, and determines that the state of the application A is normal when the character string AAA is included in the response to the command. .
The application state confirmation unit 33 executes the state confirmation command Yyyy for the application B, and determines that the state of the application B is normal when the character string BBB is included in the response to the command.
The application state confirmation unit 33 executes the state confirmation command Zzzzz for the application C, and determines that the state of the application C is normal when the character string CCC is included in the response to the command.

  The state confirmation logic 35 may be associated not only with a normal confirmation logic as in this example but also with an abnormality confirmation logic. In this case, the application state confirmation unit 33 confirms the abnormality of the corresponding application. At that time, the application state confirmation unit 33 may acquire not only the fact that an abnormality has occurred but also information such as a log of the corresponding application.

  FIG. 4 is a sequence diagram showing a flow from execution of host OS monitoring to recovery processing according to the present embodiment. In this example, the host OS 21 is monitored by transmitting a ping from the host OS monitoring unit 31 of the monitoring device 3.

  First, the host OS monitoring unit 31 of the monitoring device 3 transmits a ping to the physical NIC of the computer 2-1 (step S20). If it is normal, the host OS 21-1 returns a response within a predetermined time (step S21).

In the case of ping transmission (step S22), if no response is returned within a certain time due to a communication failure or the like (step S23), the monitoring device 3 detects a timeout (step S24).
At this time, the application status confirmation unit 33 of the monitoring device 3 confirms the status of the corresponding application a that is paired with the representative application A executed by the VM 23-1 deployed in the host OS 21-1 (step S25). As described above, the cause of this timeout is a communication failure, no hardware failure has occurred in the computer 2-1, and the representative application A is operating normally. The corresponding application a confirming the normal operation of the representative application A by polling responds that the duplex operation in which both the representative application A and the corresponding application a are operating is performed (step S26).

  Next, the application status confirmation unit 33 of the monitoring device 3 confirms the status of the corresponding application B paired with another representative application b (step S27). Since no hardware failure has occurred in the computer 2-1, the corresponding application B also responds that the duplex operation is being performed (step S28).

  As described above, when all the representative applications on the computer 2-1 are operating normally, the monitoring apparatus 3 returns to the regular monitoring again without proceeding to the recovery process (step S29). In response to the monitoring, the host OS 21-1 returns a response within a predetermined time if it is normal (step S30).

Here, consider a case where a failure has occurred in the hardware of the computer 2-1. At this time, no response is returned to the ping transmitted from the host OS monitoring unit 31 of the monitoring device 3 (step S31), and the monitoring device 3 detects a timeout (step S32).
At this time, the application status confirmation unit 33 of the monitoring device 3 confirms the status of the corresponding application a that is paired with the representative application A executed by the VM 23-1 deployed in the host OS 21-1 (step S33). The representative application A is not operating normally due to a hardware failure that has occurred in the computer 2-1. The corresponding application a that has confirmed the abnormality of the representative application A by polling responds that only the corresponding application a is in a single system operation (step S34).

  In response to the response from the corresponding application a, the monitoring device 3 that has detected a hardware failure of the computer 2-1 shifts to a recovery process and causes the virtual resource management function 4 to execute automatic recovery (step S 35).

The embodiments are described in detail for easy understanding of the present invention, and are not necessarily limited to those having all the configurations described. In addition, it is possible to add, delete, and replace other configurations for a part of the configuration of each embodiment.
In addition, the above-described mechanisms and configurations are those that are considered necessary for the description, and do not necessarily indicate all the mechanisms and configurations on the product.

  As described above, in this embodiment, a redundant system and a hardware failure detection method that reduce the risk of erroneous detection of errors and reduce the steady load on computer resources shared by multiple services executed in a virtual environment are provided. Can be provided. This hardware failure detection method does not require special hardware and can be implemented only by software.

(Modification)
The present invention is not limited to the above-described embodiment, and can be modified without departing from the spirit of the present invention. For example, there are the following (a) to (c).
(A) The alive monitoring method is not limited to ping, and an arbitrary command may be transmitted to the host OS to monitor the response.
(B) Other life and death monitoring methods are not limited to keep alive, and may be monitored by any heartbeat communication.
(C) In the above embodiment, the status is confirmed with respect to a corresponding application that is paired with any of the representative applications, and if it is a one-system operation, all virtual machines on the computer on which this representative application is operating are automatically It has recovered. However, the present invention is not limited to this, and only the virtual machine related to the representative application that detects the failure may be automatically recovered.

1 Redundant system 2-1, 2-2, 2-3 Computer (physical computer)
21-1, 21-2, 21-3 Host OS
22-1, 22-2, 22-3 Hypervisor 23-1, 23-2, 23-3, 23-4, 23-5, 23-6 Virtual machine (VM) (logical computer)
3 Monitoring device 31 Host OS monitoring unit 32 Representative application selection unit 33 Application state confirmation unit 34 Representative application candidate database (representative application candidate DB)
35 Status confirmation logic 4 Recovery processing part (virtual resource management function)
41 Computer IP address list A, B, C Application (current application) (Representative application) (Compatible application)
a, b, c Application (standby application) (Representative application) (Supported application)

Claims (8)

In a redundant system configured to include a host OS running on a plurality of physical computers, each virtual machine, and a duplex configuration application executed by the virtual machine,
A host OS monitoring unit that monitors the life and death of each of the host OSs;
If the host OS monitoring unit detects that the response of any of the host OSs is interrupted, it selects a representative application to be executed by the detected virtual machine on the host OS, and further selects a representative application pair. A representative application selection section for selecting a corresponding application,
An application state confirmation unit for confirming whether or not the state of the corresponding application selected by the representative application selection unit is in single system operation;
A redundant system comprising: If any one of the corresponding applications confirmed by the application status confirmation unit is in single system operation, the virtual machine on the host OS detected by the host OS monitoring unit is restored on another host OS. Recovery processing department,
The redundancy system according to claim 1, further comprising: Representative application candidates storing correspondence relationships between each physical computer, the virtual machine embodied on the physical computer, a representative application executed by the virtual machine, and a corresponding application that is a pair of the representative application Database,
The redundancy system according to claim 1, further comprising: A state confirmation logic for storing a state confirmation command for confirming whether the state of the representative application is in single system operation, and a response to the state confirmation command;
The redundancy system according to claim 1, further comprising: Each of the virtual machines is embodied by a hypervisor operating on the host OS.
The redundant system according to claim 1, wherein: Each virtual machine that executes the application and a virtual machine that executes the host OS are embodied by a hypervisor operating on each physical computer.
The redundant system according to claim 1, wherein: In a redundant system configured to include a host OS running on a plurality of physical computers, each virtual machine, and a duplex configuration application executed by the virtual machine,
The host OS monitoring unit monitors the life and death of each host OS,
If the host OS monitoring unit detects that the response of any host OS has been interrupted, the representative application selection unit selects a representative application to be executed by the detected virtual machine on the host OS,
Select the corresponding application to be paired with the representative application,
The application status confirmation unit confirms whether the status of the corresponding application is in single system operation,
A hardware failure detection method for a redundant system. If any one of the representative applications confirmed by the application state confirmation unit is in single system operation, the virtual machine on the host OS that has detected that the response has been interrupted is restored by the recovery processing unit. Recover on the host OS,
The method for detecting a hardware failure in a redundant system according to claim 7.

Images