JP2013254354A - Computer device, software management method and program - Google Patents

Abstract

PROBLEM TO BE SOLVED: To avoid a situation in which a device of a standby system continues operating while remaining in a degeneration state in a case where a system changeover from an active system to the standby system occurs when the device of the standby system is synchronized with degeneration of the active system and is in a degeneration state.SOLUTION: When a system is switched and a physical server device 421 of a standby system takes over processing of a physical server device 401 of an active system, a VM state recovery section 427 determines whether or not a guest OS brought into a degeneration state by a VM state management section 428 before a system changeover is present, and causes the guest OS in the degeneration state to recover from the degeneration state when the guest OS is present.

Description

The present invention relates to a computer system in which computer devices are made redundant.
For example, the present invention relates to a computer system made redundant by using a virtual machine (VM) synchronization technique.

In the conventional virtual machine synchronization technology, a virtual machine is operated on a server configured as shown in FIG. 11 and configured with a dual system configuration of operation and standby.
In the configuration of FIG. 11, the contents of a CPU (Central Processing Unit) register and memory of a virtual machine operating on the active server are periodically copied to a virtual machine that is suspended on the standby server.
As a result, the states of the active and standby virtual machines are synchronized, and the operation in the standby system is continued even after a server failure occurs in the active server.
The CPU register and memory contents copy processing is triggered by input in the input / output processing inside the virtual machine (Non-Patent Document 1), or the copy processing is executed by periodic control at regular intervals ( Non-patent document 2).

Further, in the conventional CPU abnormality detection technology, for example, in UNIX (registered trademark), an abnormality has occurred by detecting a processor abnormality and then using dynamic processor deallocation (Non-patent Document 3). There is a technology that enables operation to be continued by disconnecting the processor and degenerating the system.
This technology is expected to be realized in the Linux (registered trademark) system equipped with x86 CPU in the future.

Development of fault-tolerant clustering technology using KVM, IPSJ research report. [System Software and Operating System] 2010-OS-115 (20), 1-8, 2010-07-27 Remus: High Availability via Asynchronous Virtual Machine Replication, USENIX NSDI'08 (April. 2010) Key Features of RAS Power SystemTM Reliability, Availability, and Serviceability of POWER7 (R) Systems, Daniel Henderson, Jim Mitchell, and George Ahrens, November 1, 2010

By combining the CPU abnormality detection technology with the VM technology, a system as shown in FIG. 12 can be constructed.
The system as shown in FIG. 12 has a configuration in which a physical CPU (hereinafter referred to as “CPU”) is assigned to a virtual CPU (hereinafter referred to as “vCPU”) held by the VM, and an abnormality of the CPU is detected. It is possible to notify VMs and vCPUs that are using.
When the virtual machine holds a plurality of vCPUs, the VM can be put into a degenerated state by disconnecting the vCPU assigned to the CPU in which the abnormality occurred when the CPU is abnormal from the VM.

A system in which the VM synchronization technology is applied to a system combining the CPU abnormality detection technology and the VM technology performs the operation as shown in FIG.
In FIG. 13, when an abnormality occurs in the active CPU, the VM assigned to the CPU enters a degenerated state by disconnecting the vCPU assigned to the CPU in which the abnormality has occurred.
At this time, due to VM synchronization, the VM state is copied to the standby system, and the VM that is temporarily stopped on the standby server even though no abnormality has occurred in the standby CPU is in the degenerated state. Become.
When system switching occurs from the active system to the standby system in a state where the standby VM is in a degenerated state, the standby VM starts operating in the degenerated state, and the degenerated state continues. There are challenges.

  One of the main objects of the present invention is to solve the above-described problems, and a main object of the present invention is to avoid a situation in which a standby computer device continues to operate in a degenerated state.

The computer device according to the present invention is:
Software that is common to software implemented in an operational computer device used as an operational system in a computer system in which the computer device is made redundant, is a computer device used as a standby system in the computer system,
When any software in the operational computer device is in a degenerated state, a degeneration execution unit that sets the software in the computer device corresponding to the software in the degenerated state in the active computer device to a degenerated state When,
When the system is switched and the computer device takes over the processing of the active computer, it is determined whether or not there is degenerate state software that the degeneration execution unit puts into a degenerated state before switching the system, and the degeneration And a state recovery unit that recovers the degraded state software from the degraded state when the state software exists.

  According to the present invention, when the system is switched, it is determined whether or not the degraded state software exists, and when the degraded state software exists, the standby state of the standby system is recovered in order to recover the degraded state software from the degraded state. It is possible to avoid a situation in which the computer device continues to operate in a degenerated state.

FIG. 2 is a diagram illustrating a configuration example of a computer system according to the first embodiment. FIG. 3 is a flowchart showing an operation during normal operation of an operational system according to the first embodiment. FIG. 3 is a flowchart showing an operation during normal operation of an operational system according to the first embodiment. FIG. 3 is a flowchart showing an operation when an operational CPU abnormality occurs according to the first embodiment. FIG. 3 is a flowchart showing an operation during normal operation of the standby system according to the first embodiment. FIG. 3 is a flowchart showing an operation during normal operation of the standby system according to the first embodiment. FIG. 3 is a flowchart showing an operation after system switching of the standby system according to the first embodiment. FIG. 3 is a diagram showing an example of CPU allocation patterns according to the first embodiment. FIG. 4 is a diagram showing an example of CPU allocation patterns based on priorities according to the first embodiment. FIG. 3 is a diagram illustrating a hardware configuration example of a physical server device according to the first embodiment. The figure explaining virtual machine synchronization technology. The figure explaining the degeneracy process at the time of CPU abnormality occurrence. The figure explaining that a degeneracy state continues in the standby system after system switching. The figure explaining the case where there is no space in the physical CPU and the resource becomes insufficient.

Embodiment 1 FIG.
In this embodiment, in response to the problem described with reference to FIG. 13, the number of vCPUs decreased due to degeneration is added to the VM after the system is switched after the VM system is switched to the standby server. Recovery from the degraded state by assigning unused CPUs (hardware resources) to the added vCPUs with the same number of vCPUs as when operating normally (not in a degraded state) on the active server The structure which performs is demonstrated.

For example, as shown in FIG. 14, it is assumed that there are three VMMs (virtual machine monitors), each VMM operates with six physical CPUs, and each VM operates with two vCPUs.
In this environment, if an error occurs in the physical CPU of the active VM C and the system switch occurs after the active VM C and the standby VM C are in a degenerated state, after the system switch The standby VMC can be recovered from the degenerated state to the normal state by the above method.
However, if an error occurs in the physical CPU of the active VM D and the system switch occurs after the active VM D and the standby VM D are degenerated, the unused physical There is no CPU, and an unused physical CPU cannot be assigned to the vCPU of the standby VM D.

  In this embodiment, in order to cope with this problem, an availability guarantee priority indicating the priority of continuous operation of the system is introduced, a vCPU is added to the VM, and an allocation pattern and an allocation time of the CPU allocated to the vCPU are controlled. As a result, operation continuation is guaranteed in order from the VM with the highest availability guarantee priority.

  FIG. 1 shows a configuration example of a computer system according to the present embodiment.

Two physical server devices 401 and 421 are arranged on a LAN (Local Area Network) 400.
It is assumed that the physical server device 401 operates as an active server device.
Therefore, the physical server device 401 corresponds to an example of an operational computer device.
In addition, the physical server device 421 operates as a standby server device.
Therefore, the physical server device 421 corresponds to an example of a computer device.

The physical server device 401 is equipped with three CPUs 11, 12, and 13, and the physical server device 421 is equipped with three CPUs 21, 22, and 23.
On each physical server device, virtual machine monitors 402 and 422 are operating.
On the virtual machine monitor 402, a guest OS (Operating System) 403 having virtual CPUs (vCPU) 15 and 16 and a guest OS 404 having vCPU 14 are operating. On the virtual machine monitor 422, a guest OS 423 having vCPUs 24 and 25 is operating. And the guest OS 424 having the vCPU 26 are operating.
The virtual machine monitors 402 and 422 include VM degeneration availability determination units 405 and 425, CPU abnormality detection units 406 and 426, VM state recovery units 407 and 427, VM state management units 408 and 428, VM schedulers 409 and 429, and VM system switching. Sections 410 and 430, VM synchronization sections 411 and 431, CPU usage status management sections 412 and 432, abnormal part determination sections 413 and 433, and VM setting files 414 and 434.
Since the physical server device 401 is an active physical server device and the physical server device 421 is a standby physical server device, the guest OS 403 operates as an active VM, and the guest OS 423 is started as a standby VM corresponding to the guest OS 403. Is in a paused state.
Similarly, the guest OS 404 also operates as an active VM, the guest OS 424 is activated as a standby VM corresponding to the guest OS 404, and is in a suspended state.

  Here, among the components of the virtual machine monitors 402 and 422, components related to the characteristic operation of the present embodiment will be described.

  The VM setting files 414 and 434 are setting files for each VM (guest OS) in which the number of virtual CPUs (vCPUs) held during normal operation, degeneration availability setting, and availability guarantee priority settings are written.

  When a CPU abnormality occurs, the abnormal part determination units 413 and 433 identify the CPU in which the abnormality has occurred and the VM assigned to the CPU in which the abnormality has occurred.

  The VM system switching units 410 and 430 perform system switching when an abnormality occurs in the active physical server device 401.

The VM state management units 408 and 428 collect and manage vCPU usage status and availability guarantee priority information for each VM, and share them between the active virtual machine monitor and the standby virtual machine monitor.
Specifically, when one of the VMs is in a degraded state due to the occurrence of a CPU abnormality, the VM state management unit 408 displays information on the VM in the degraded state, the separated vCPU, and the like as a VM state management unit. 428 is notified.
Then, the VM state management unit 428 puts the corresponding VM in the standby physical server device 421 into a degenerated state based on the information notified from the VM state management unit 408.
The VM state management unit 428 corresponds to an example of a degeneration execution unit.

The VM state recovery units 407 and 427 add insufficient vCPUs after system switching from the active system to the standby system, and the vCPU usage status and availability guarantee priority for each VM managed by the VM state management units 408 and 428 Based on the above, the CPU allocation time allocated to each added vCPU is controlled.
That is, when the system is switched and the standby physical server device 421 takes over the processing of the active physical server device 401, the VM state recovery unit 427 is in a degenerated state before switching the system. It is determined whether or not there is a degenerated VM (degraded software), and if there is a degenerated VM, the degenerated VM is recovered from the degenerated state.
Also, the VM state recovery unit 427 determines whether there is a physical CPU that can be used exclusively by the degraded VM, and when there is no physical CPU that can be used exclusively by the degraded VM, the physical state used by other VMs The CPU is shared between the degraded VM and the other VM, and the degraded VM is recovered from the degraded state.
Also, the VM state recovery unit 427 restricts the use of the physical CPU of the VM whose availability guarantee priority is lower than that of the degraded VM depending on the usage status of the physical CPU, and secures the physical CPU to be allocated to the degraded VM. There is also a case.
The VM state recovery unit 427 corresponds to an example of a state recovery unit.

  Next, the operation will be described separately for the operation system and the standby system during normal operation, the operation of the operation system when a CPU abnormality occurs, and the operation of the standby system immediately after system switching.

First, the operation of the active system and the standby system during normal operation will be described.
FIG. 2 and FIG. 3 are flowcharts showing operations during normal operation of the active physical server device 401.
FIGS. 5 and 6 are flowcharts showing the operation of the standby physical server device 421 during normal operation.

In the active physical server device 401, after the VM synchronization unit 411 starts operation in S501, the CPU / memory contents of the VM are transmitted to the standby VM synchronization unit 431 in S502.
Thereafter, the operation of S502 is repeated periodically.
In parallel with the operation of the VM synchronization unit 411, after the VM state management unit 408 starts operation in S503, the VM setting file 414 is read in S504, and the availability guarantee priority information for each VM is stored in the standby system. It is shared with the VM state management unit 428, collects the vCPU usage status of the VM that is operating in S505 (the pause state is not included in the operation), and shares it with the standby VM state management unit 428.
Thereafter, the operation of S505 is repeated periodically.

In the standby system, after the VM synchronization unit 431 starts operation in S701, in S702, the CPU CPU / memory contents of the VM transmitted from the active VM synchronization unit 411 are received in S502, and the standby system This is reflected in the temporarily stopped VM.
In parallel with the operation of the VM synchronization unit 431, after the VM state management unit 428 starts operation in S703, the VM setting file 434 is read in S704, and the availability guarantee priority information for each VM is obtained. It is shared with the VM state management unit 408, collects the vCPU usage status of the VM that is operating in S705 (the pause state is not included in the operation), and shares it with the active VM state management unit 408.
Thereafter, the operation of S705 is repeated periodically.
The above is the operation of the active system and the standby system during normal operation.

  Next, the operation of the operational system when a CPU abnormality occurs will be described (FIG. 4).

If a CPU abnormality occurs in the active physical server device 401 in S601, the CPU abnormality detection unit 406 detects the CPU abnormality in S602, and the abnormality location determination unit 413 is called in S603, causing an abnormality. The VM assigned to the CPU that has failed and the CPU in which an abnormality has occurred are identified.
In step S <b> 604, the VM degeneration possibility determination unit 405 accesses the VM setting file 414 to check whether the VM identified in step S <b> 603 has been set to be degenerate.
If the degradable setting is not set at this time, the process proceeds to S609, the system switching is performed by the VM system switching unit 410, the active VM is stopped, and the operation of the temporarily stopped VM is resumed. Let
If the degradable setting is set, the VM degradability determination unit 405 accesses and confirms information managed by the VM state management unit 408 in S605 as to whether or not the VM can be degenerated.
At this time, if the degeneration is impossible, the process proceeds to S609, the system switching is performed by the VM system switching unit 410, the active VM is stopped, and the operation of the temporarily stopped VM of the standby system is resumed. .
If degeneration is possible, the CPU abnormality detection unit 406 notifies the corresponding VM of the CPU abnormality in S606.
Next, in S607, the VM that has received the CPU abnormality notification disconnects the vCPU assigned to the CPU in which the abnormality has occurred, and enters a degenerated state.
In S608, the VM state management unit 408 detects that the VM is in a degenerated state and the number of vCPUs held by the VM has decreased, and shares it with the standby VM state management unit 428.
That is, the VM state management unit 408 notifies the standby state VM state management unit 428 of the vCPU separated from the VM in the degenerated state.
The VM state management unit 428 disconnects the vCPU corresponding to the vCPU notified from the VM state management unit 408, and puts the corresponding VM in the standby physical server device 421 into a degenerated state.

  The above is the operation when a CPU abnormality occurs in the operational system. If a CPU abnormality occurs after the processing of S605, S606, S607, and S608 and the VM is in a degenerated state, the processing from S602 is performed again.

  Finally, the operation of the standby system immediately after system switching will be described (FIG. 7).

In system operation S609 (FIG. 4), system switching is performed. After system switching is completed in S801, the VM state recovery unit 427 determines whether or not the VM immediately after system switching is in a degenerated state in S802. The information managed by the unit 428 is accessed and confirmed.
That is, the VM state recovery unit 427 determines whether there is a VM that has been put into a degenerated state by the VM state management unit 428 before system switching.
If there is no degenerated VM, the process moves to S809 to complete the process.
If there is a degraded VM, the process moves to S803, and the VM state recovery unit 427 adds a vCPU that is insufficient due to the degradation.
Next, in S804, the VM state recovery unit 427 confirms whether there is an unused CPU to be allocated to the added vCPU by using information of the CPU usage status management unit 432.
At this time, if there are as many unused CPUs as the number of added vCPUs, the VM state recovery unit 427 assigns an unused CPU to the vCPU in S805, and the process moves to S809, where the process is completed.

When there is no unused physical CPU, the VM state recovery unit 427 uses the vCPU usage status of the VM that is operating in the standby system in S806, and the standby VM state management unit 428 performs the active VM state management in S705. The vCPU usage status of the active system shared with the unit 408 is compared, and it is confirmed whether or not recovery is possible by changing the CPU allocation pattern.
If recovery is possible by changing the CPU allocation pattern, the VM state recovery unit 427 acquires the vCPU usage status of other VMs operating in the standby system until immediately before system switching from the VM state management unit 428 in S807. The surplus CPU resource amount immediately after the system switching is calculated, the CPU allocation pattern to the vCPU (including the added vCPU) is changed, the process proceeds to S809, and the process is completed.
On the other hand, if the CPU allocation pattern cannot be recovered due to the CPU allocation pattern change, the process moves to S808, and the VM state recovery unit 427 allocates the CPU allocated to the VM with the lower availability guarantee priority based on the availability guarantee priority. The time is reduced, and a CPU allocation time is allocated to a VM with a high availability guarantee priority. The process moves to S809, and the process is completed.
The above is the operation of the standby system immediately after system switching.

In S807, the VM state recovery unit 427 calculates the surplus CPU amount as shown in FIG. 8, and shares the CPU that can provide the CPU amount necessary for the degenerate VM to operate in the normal state with other VMs. The process of changing the allocation pattern is performed.
In the example of FIG. 8, the vCPU 3 is a VM vCPU in a degenerated state, and this vCPU 3 can be realized if 30% of the CPU time is allocated, and the physical CPU 2 has 50% of the CPU time remaining. Is allocated to the vCPU 3, so that the degenerated VM is restored to the normal state.

In S808, as shown in FIG. 9, the VM state recovery unit 427 increases the surplus CPU amount by reducing the CPU amount allocated to the VM with the low availability guarantee priority, and allocates it to the VM with the high availability guarantee priority. The process is performed.
In the example of FIG. 9, the vCPU 3 is a VM vCPU in a degenerated state, and this vCPU 3 can be realized if 30% of the CPU time is allocated.
The surplus of both the physical CPU 1 and the physical CPU 2 is only 25%, and cannot be recovered by changing the CPU allocation pattern in FIG.
For this reason, the CPU amount allocated to the VM (using vCPU 1) having a lower availability guarantee priority than the VM in the degenerated state (using vCPU 3) is reduced by 5% to make the surplus CPU amount 30%, and this 30% Is assigned to the vCPU 3, and the degenerated VM is restored to the normal state.

  As described above, the availability guarantee is performed by the VM state management unit that collects the vCPU usage status for each VM and manages whether the VM is in a degraded state, and the VM state recovery unit that executes the processing of S807 and S808. Based on the priority and the CPU allocation status immediately after system switching, the CPU allocation pattern and CPU allocation to the vCPU are changed to recover from the degraded state in order from the one with the highest availability guarantee priority, and the operation after system switching is guaranteed. The effect that is done.

As described above, in the present embodiment,
A synchronization source VM in VM synchronization, an active physical server device on which a virtual machine monitor that manages the synchronization source VM operates,
A synchronization destination VM in VM synchronization, and a standby physical server device on which a virtual machine monitor that manages the synchronization destination VM operates,
Inside the virtual machine monitor,
A CPU abnormality detection unit that detects an abnormality when a CPU abnormality occurs;
An abnormal point determination unit that identifies a vCPU and a VM assigned to a CPU in which an abnormality has occurred;
A VM configuration file in which the availability guarantee priority for each VM and the degeneracy permission setting are written;
A VM state management unit that manages the current VM degradation status and vCPU usage status, and shares the VM degradation status and vCPU usage status with the standby system;
Add vCPU to the VM after switching based on the VM degeneration status and vCPU usage status shared with the active VM state management unit after system switching, and change the allocation of unused CPU, CPU allocation pattern and CPU allocation A VM state recovery unit to perform,
The vCPU usage status and availability guarantee priority when the VM running on the active physical server device is in a degraded state due to a CPU failure and the VM that has been inherited by VM synchronization is operating normally in the active system Information is acquired from the VM state management unit, and the CPU allocation pattern to the vCPU and the CPU allocation amount are changed on the basis of the availability assurance priority and the CPU allocation status immediately after the system switchover, in descending order of the availability assurance priority. Recover from the degenerate state and guarantee the operation after system switchover.
The virtual machine synchronization device and abnormality detection / system switching method were explained.

In the above description, the computer system in which the virtual machine is constructed is described as an example. However, the application target of the present embodiment is not limited to this.
A computer system that puts software in a standby computer device corresponding to software in a degraded state in the active computer device into a degraded state when any software in the active computer device is in a degraded state. For example, the method described in this embodiment can be applied.
Then, if the method shown in this embodiment is applied, it is determined whether or not degraded software is present in the standby computer device after system switching. If degraded software is present, degraded software is present. Can be recovered from the degenerated state.

Finally, a hardware configuration example of the physical server devices 401 and 421 described in this embodiment will be described.
FIG. 10 is a diagram illustrating an example of hardware resources of the physical server devices 401 and 421 described in this embodiment.
Note that the configuration in FIG. 10 is merely an example of the hardware configuration of the physical server devices 401 and 421, and the hardware configuration of the physical server devices 401 and 421 is not limited to the configuration illustrated in FIG. It may be a configuration.

In FIG. 10, the physical server devices 401 and 421 include a CPU 911 that executes a program.
The CPU 911 is connected to, for example, a ROM (Read Only Memory) 913, a RAM (Random Access Memory) 914, a communication board 915, a display device 901, a keyboard 902, a mouse 903, and a magnetic disk device 920 via a bus 912. Control hardware devices.
Further, the CPU 911 may be connected to an FDD 904 (Flexible Disk Drive) or a compact disk device 905 (CDD).
Further, instead of the magnetic disk device 920, an SSD (Solid State Drive) may be used.
The RAM 914 is an example of a volatile memory.
The storage media of the ROM 913, the FDD 904, the CDD 905, and the magnetic disk device 920 are an example of a nonvolatile memory. These are examples of the storage device.
The communication board 915, the keyboard 902, the mouse 903, the FDD 904, and the like are examples of input devices.
The communication board 915, the display device 901, and the like are examples of output devices.

  The communication board 915 is connected to the LAN 400 as shown in FIG.

The magnetic disk device 920 stores a virtual machine monitor 921, a guest OS 922, a program group 923, and a file group 924.
The programs in the program group 923 are executed by the CPU 911, the virtual machine monitor 921, and the guest OS 922.
The virtual machine monitor 921 includes each element in the virtual machine monitors 402 and 422 of FIG.

The ROM 913 stores a BIOS (Basic Input Output System) program, and the magnetic disk device 920 stores a boot program.
When the physical server devices 401 and 421 are activated, the BIOS program in the ROM 913 and the boot program in the magnetic disk device 920 are executed, and the virtual machine monitor 921 and the guest OS 922 are activated by the BIOS program and the boot program.

Further, in the description of the present embodiment, the file group 924 includes “control of”, “determination of”, “determination of”, “detection of”, “synchronization”, “identification of”, and “control of”. "," Setting of "," selection of "," confirmation of "," assignment of ", etc. It is stored as each item of "~ file" and "~ database".
The “˜file” and “˜database” are stored in a recording medium such as a disk or a memory. Information, data, signal values, variable values, and parameters stored in a storage medium such as a disk or memory are read out to the main memory or cache memory by the CPU 911 via a read / write circuit, and extracted, searched, referenced, compared, and calculated. Used for CPU operations such as calculation, processing, editing, output, printing, and display.
Information, data, signal values, variable values, and parameters are stored in the main memory, registers, cache memory, and buffers during the CPU operations of extraction, search, reference, comparison, calculation, processing, editing, output, printing, and display. It is temporarily stored in a memory or the like.
Also, the arrows in the flowchart described in this embodiment mainly indicate input / output of data and signals, and the data and signal values are the RAM 914 memory, the FDD904 flexible disk, the CDD905 compact disk, and the magnetic disk device. 920 magnetic disks, other optical disks, Blu-ray (registered trademark) disks, DVDs, and other recording media.
Data and signals are transmitted online via a bus 912, signal lines, cables, or other transmission media.

In addition, what is described as “to part” in the description of the present embodiment may be “to step”, “to procedure”, and “to process”.
That is, the “software management method” according to the present invention can be realized by the steps, procedures, and processes shown in the flowchart described in the present embodiment.
Further, what is described as “˜unit” may be realized by firmware stored in the ROM 913.
Alternatively, it may be implemented only by software, or a combination of hardware such as an element, a device, a board, and wiring and software, and further a combination with firmware. Firmware and software are stored as programs in a recording medium such as a magnetic disk, a flexible disk, an optical disk, a compact disk, a Blu-ray (registered trademark) disk, and a DVD.

  11 CPU, 12 CPU, 13 CPU, 14 vCPU, 15 vCPU, 16 vCPU, 21 CPU, 22 CPU, 23 CUP, 24 vCPU, 25 vCPU, 26 vCPU, 400 LAN, 401 Physical server device, 402 Virtual machine monitor, 403 Guest OS, 404 Guest OS, 405 VM degeneration availability determination unit, 406 CPU abnormality detection unit, 407 VM state recovery unit, 408 VM state management unit, 409 VM scheduler, 410 VM system switching unit, 411 VM synchronization unit, 412 CPU use Status management unit, 413 abnormality location determination unit, 414 VM setting file, 421 physical server device, 422 virtual machine monitor, 423 guest OS, 424 guest OS, 425 VM degeneration availability determination unit, 426 CPU abnormality detection unit, 428 M state management unit, 427 VM state recovery unit, 429 VM scheduler, 430 VM-based switching unit, 431 VM synchronization unit, 432 CPU usage management unit, 433 abnormal point determination unit, 434 VM configuration file.

Claims (9)

Software that is common to software implemented in an operational computer device used as an operational system in a computer system in which the computer device is made redundant, is a computer device used as a standby system in the computer system,
When any software in the operational computer device is in a degenerated state, a degeneration execution unit that sets the software in the computer device corresponding to the software in the degenerated state in the active computer device to a degenerated state When,
When the system is switched and the computer device takes over the processing of the active computer, it is determined whether or not there is degenerate state software that the degeneration execution unit puts into a degenerated state before switching the system, and the degeneration A computer apparatus, comprising: a state recovery unit that recovers the degenerate state software from the degenerated state when the state software exists. The state recovery unit is
When the degraded state software exists, it is determined whether there is a hardware resource in the computer device that can be exclusively used by the degraded state software, and when there is no hardware resource that can be exclusively used by the degraded state software, A hardware resource used by other software in the computer device is shared between the degraded software and the other software in the computer device, and the degraded software is recovered from the degraded state. The computer apparatus according to claim 1. The state recovery unit is
If there is no hardware resource that can be used exclusively by the software in the degraded state, if there is a surplus resource that can be allocated to the software in the degraded state in the hardware resource used by other software in the computer device, the hardware resource The computer apparatus according to claim 2, wherein the surplus resource is allocated to the degenerated state software, and the degenerated state software is recovered from the degenerated state. The state recovery unit is
If there is no surplus resource that can be allocated to the degraded software in hardware resources used by other software in the computer device, the use of hardware resources of any software in the computer device is restricted. 4. The surplus resource is generated in the hardware resource, the surplus resource of the generated hardware resource is allocated to the degraded state software, and the degraded state software is recovered from the degraded state. Computer equipment. The state recovery unit is
If the hardware resources used by other software in the computer device do not have surplus resources that can be allocated to the degraded software, the use of hardware resources of software having a lower priority than the degraded software is restricted. The computer apparatus according to claim 4, wherein surplus resources are generated in the hardware resources. The computer device includes:
A virtual machine monitor, on the virtual machine monitor,
A guest OS (operating system) common on the virtual machine monitor of the operational computer device is implemented, and a guest OS is implemented,
The degeneration execution unit
When any guest OS in the operational computer device is in a degraded state, the guest OS in the computer device corresponding to the guest OS in the degraded state in the operational computer device is degraded,
The state recovery unit is
When a system is switched and the computer device takes over the processing of the active computer, it is determined whether or not there is a degenerated guest OS that the degeneration execution unit has put into a degenerated state before system switching, and The computer apparatus according to claim 1, wherein, when a degenerated guest OS exists, the degenerated guest OS is recovered from the degenerated state.   The computer apparatus according to claim 6, wherein the degeneration execution unit and the state recovery unit are included in the virtual machine monitor. A software management method implemented by a computer device used as a standby system in the computer system, in which software common to software installed in an operational computer device used as an active system in a computer system in which the computer device is made redundant is installed There,
When any software in the operational computer device is in a degraded state, the computer device is in a degraded state for the software in the computer device corresponding to the software in the degraded state in the operational computer device A degeneration implementation step,
Whether or not there is degenerate state software that has been put into a degenerated state by the degeneration execution step before the system is switched when the computer is switched over and the computer device takes over the processing of the active computer And a state recovery step of recovering the degraded state software from the degraded state when the degraded state software exists. Software common to software installed in an operational computer device used as an operational system in a computer system in which the computer device is made redundant is installed, and the computer device used as a standby system in the computer system includes:
When any software in the operational computer apparatus is in a degenerated state, a degeneration execution step for bringing the software in the computer apparatus corresponding to the software in the degenerated state in the operational computer apparatus into a degenerated state When,
When the system is switched and the computer device takes over the processing of the active computer, it is determined whether there is degenerate state software that has been put into a degenerated state by the degeneration execution step before the system is switched, A program for executing a state recovery step of recovering the degraded state software from the degraded state when the degraded state software exists.

Images