WO2012070102A1 - 計算機装置及びプログラム - Google Patents

計算機装置及びプログラム Download PDF

Info

Publication number
WO2012070102A1
WO2012070102A1 PCT/JP2010/070812 JP2010070812W WO2012070102A1 WO 2012070102 A1 WO2012070102 A1 WO 2012070102A1 JP 2010070812 W JP2010070812 W JP 2010070812W WO 2012070102 A1 WO2012070102 A1 WO 2012070102A1
Authority
WO
WIPO (PCT)
Prior art keywords
guest
hardware
request
failure
response
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Ceased
Application number
PCT/JP2010/070812
Other languages
English (en)
French (fr)
Inventor
俊介 國分
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Mitsubishi Electric Corp
Original Assignee
Mitsubishi Electric Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Mitsubishi Electric Corp filed Critical Mitsubishi Electric Corp
Priority to PCT/JP2010/070812 priority Critical patent/WO2012070102A1/ja
Priority to JP2012545548A priority patent/JP5335150B2/ja
Publication of WO2012070102A1 publication Critical patent/WO2012070102A1/ja
Anticipated expiration legal-status Critical
Ceased legal-status Critical Current

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/14—Error detection or correction of the data by redundancy in operation
    • G06F11/1479—Generic software techniques for error detection or fault masking
    • G06F11/1482—Generic software techniques for error detection or fault masking by means of middleware or OS functionality
    • G06F11/1484—Generic software techniques for error detection or fault masking by means of middleware or OS functionality involving virtual machines
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533—Hypervisors; Virtual machine monitors
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533—Hypervisors; Virtual machine monitors
    • G06F9/45558—Hypervisor-specific management and integration aspects
    • G06F2009/45579—I/O management, e.g. providing access to device drivers or storage

Definitions

  • the present invention relates to a technique for managing a virtual machine system having a redundant configuration.
  • Non-Patent Document 1 and Non-Patent Document 2 Applying virtualization technology, for example, constructing two virtual machines on two server devices (physical computer devices), synchronizing the two virtual machines, duplexing the virtual machines, and FT (Fault Tolerant in software) : Fault tolerance) (hereinafter referred to as software FT) (for example, Non-Patent Document 1 and Non-Patent Document 2).
  • software FT Fault Tolerant in software
  • the state (memory, disk, etc.) of the guest OS (operating system) running on the active server device is synchronized (copied) on the standby server device for each operation or at a certain period.
  • the operation of the guest OS is restarted in the standby server device from the state of the guest OS copied on the standby server device. The operation can be resumed.
  • Patent Document 1 the operating state of the guest OS and the guest OS state that is periodically acquired (in Patent Document 1, snapshot data is used. Associated) and save. Furthermore, in the technology of Patent Document 1, when a failure occurs in the active server device, the synchronization data is selected retroactively to the guest OS operating state where the failure does not occur, and the selected synchronization data is used. The operation of the guest OS is resumed in the standby server apparatus. In this way, the technique disclosed in Patent Document 1 makes it possible to switch the guest OS without inheriting a processing abnormality due to a failure.
  • One of the main objects of the present invention is to solve the above-described problems, and is to enable normal operation of the guest OS in the standby system without being affected by a hardware failure. With a purpose.
  • the computer apparatus is: Hardware, and a first guest OS (Operating System) that operates on a virtual machine realized using the hardware and issues a request to the hardware, A computer device connected to an external device having a second guest OS that performs the same operation as the first guest OS, A request management unit that stores a copy of a request issued by the first guest OS in a predetermined storage area; It is determined whether or not a failure has occurred in the hardware before a response from the hardware to the request reaches the first guest OS.
  • a first guest OS Operating System
  • the response A failure detection unit for controlling the first guest OS so as not to reach the first guest OS;
  • the hardware failure is detected by the failure detection unit, the copy of the request stored in the storage area and the state of the first guest OS at the time when the hardware failure is detected
  • a takeover control unit for outputting an instruction message for instructing the second guest OS to take over the operation performed by the first guest OS. It is characterized by that.
  • the present invention it is determined whether a failure has occurred in the hardware before the response from the hardware reaches the first guest OS, and the response is received when the failure has occurred in the hardware. Detects a hardware failure because it controls the status so that it does not reach one guest OS and outputs a copy of the request and information indicating the state of the first guest OS at the time when a hardware failure is detected.
  • the second guest OS can be operated from the state immediately before the start. Thereby, the operation performed in the first guest OS can be normally taken over by the second guest OS without being affected by the hardware failure.
  • FIG. 3 is a diagram illustrating an example of a system configuration according to the first embodiment. The figure which shows the flow of the general I / O process in a virtual environment.
  • FIG. 3 is a diagram showing a flow of I / O processing according to the first embodiment.
  • FIG. 3 is a flowchart showing an example of I / O request transfer processing according to the first embodiment.
  • FIG. 3 is a flowchart showing an operation example of an I / O control unit according to the first embodiment.
  • FIG. 3 is a flowchart showing an example of I / O response transfer processing according to the first embodiment.
  • FIG. 3 is a flowchart showing an operation example of an I / O control unit, a failure detection unit, and a synchronization unit according to the first embodiment.
  • FIG. 4 is a diagram illustrating a hardware configuration example of a server device according to the first to third embodiments.
  • Embodiment 1 In the present embodiment, in a configuration in which an active server device and a standby server device are arranged, an active host OS or virtual machine is not added to the active guest OS without adding a failure detection mechanism.
  • the monitor detects a hardware failure, discards the failure information related to the hardware failure, and prevents the hardware failure information from being propagated to the active guest OS. In this way, the operating guest OS is prevented from recognizing a hardware failure.
  • the synchronous data for notifying the status of the active guest OS and the instruction data for instructing the standby guest OS to take over the operation of the active guest OS are subsequently sent from the active server device. Is output to the standby server device. Then, the standby server device uses the synchronization data to make the state of the standby guest OS the same as the state of the active guest OS without being affected by the hardware failure in the active server device. The standby guest OS normally takes over the operation of the active guest OS.
  • FIG. 1 shows a system configuration according to the present embodiment.
  • the server apparatus 100 and the server apparatus 200 are connected by a LAN (Local Area Network) 300.
  • the server apparatus 100 and the server apparatus 200 are different physical computer apparatuses.
  • the description will proceed with an example in which the server device 100 is an active server device and the server device 200 is a standby server device.
  • the server device 100 is an example of a computer device
  • the server device 200 is an example of an external device.
  • the fact that the server device 100 is an example of a computer device is expressed as an active server device (computer device), and the fact that the server device 200 is an example of an external device is a standby server device (external device). It expresses.
  • the hardware 101 includes, for example, a CPU (Central Processing Unit) 1011, a memory 1012, a disk 1013, and a NIC (Network Interface Card) 1014. Note that the hardware 101 may include other hardware elements.
  • a virtual machine monitor 102 operates on the hardware 101, and a host OS 103 and a guest OS 104 operate on the virtual machine monitor 102.
  • the guest OS 104 operates using virtual hardware (virtual CPU, virtual memory, virtual disk, virtual NIC, etc.) provided by a virtual machine realized by the virtual machine monitor 102 and the host OS 103.
  • the guest OS is an example of a first guest OS.
  • the guest OS 104 is an example of the first guest OS, and is shown in parentheses.
  • the status of the active guest OS 104 (the context of the guest OS 104) is I / O (Input / Output).
  • the server 109 is notified to the standby server device 200 by the synchronization unit 109 at every processing or at a constant cycle, and the guest OS 204 is synchronized with the guest OS 104 (the state of the guest OS 104 and the state of the guest OS 204 match) .
  • the guest OS 204 is a guest OS that performs the same operation as the guest OS 104, and is an example of a second guest OS. In FIG. 1, parentheses indicate that the guest OS 204 is an example of a second guest OS.
  • synchronization data Data that notifies the latest state of the guest OS 104 is referred to as synchronization data.
  • the difference between the synchronization data and the state indicated in the previous synchronization data is indicated.
  • the guest OS 204 each time new synchronization data is input, the previous synchronization data is overwritten with the new synchronization data. That is, there is only one synchronization data.
  • the synchronization unit 109 operates across the virtual machine monitor 102 and the host OS 103.
  • I / O requests include reading data from the disk 1013, writing data to the disk 1013, sending data to the network via the NIC 1014, and receiving data from the network via the NIC 1014.
  • the I / O request is a request from the guest OS 104 to the hardware 101. Further, an I / O response from the hardware 101 described later to the guest OS 104 is a response from the hardware 101 to the request.
  • the flow of I / O processing in the virtual environment is as shown in FIG. 2, and an I / O request from the process 105 is passed to the front-end driver 106 on the guest OS 104 and passes through the virtual machine monitor 102.
  • the back-end driver 107 on the host OS 103 passes the I / O request to the real device driver 108, and the real device driver 108 executes the I / O request to the actual hardware 101.
  • the I / O response processed by the hardware is returned to the real device driver 108, and the front end driver on the guest OS 104 passes from the real device driver 108 via the back end driver 107 on the host OS 103 and the virtual machine monitor 102. 106, and returned to the process 105 that issued the I / O request.
  • an I / O control unit 110 that controls I / O requests and I / O responses between the front-end driver 106 and the back-end driver 107 is arranged on the host OS 103.
  • a failure detection unit 111 for inspecting whether or not there is a failure with respect to the I / O response detected by the I / O control unit 110 is arranged.
  • a storage unit 112 that temporarily stores a copy of the I / O request from the guest OS 104 is arranged on the virtual machine monitor 102.
  • the I / O control unit 110 inputs an I / O request from the front-end driver 106, copies the input I / O request, and copies the I / O request.
  • the data is stored in the storage unit 112 and an I / O request is output to the backend driver 107.
  • the virtual machine monitor 102 stores a copy of the I / O request from the I / O control unit 110 in a physical storage area associated with the storage unit 112.
  • the virtual machine monitor 102 stores a copy of the I / O request in a predetermined address of the memory 1012 or a register of the CPU 1011. Thereafter, as in the case of FIG.
  • the I / O request reaches the hardware 101 from the back-end driver 107 via the real device driver 108.
  • the hardware 101 outputs an I / O response that is a response to the I / O request to the real device driver 108, and the I / O control unit 110 inputs the I / O response from the back-end driver 107.
  • the I / O control unit 110 outputs the input I / O response to the failure detection unit 111.
  • the failure detection unit 111 inputs an I / O response from the I / O control unit 110, examines the input I / O response, and if an error message exists in the I / O response, If it is determined that a failure has occurred, the I / O response is discarded, and if there is no error message in the I / O response, the I / O response is forwarded via the I / O control unit 110. Output to the end driver 106. Since the error message of the I / O response is a message for notifying a failure in the hardware 101, when the failure detection unit 111 detects an error message from the I / O response, a failure has occurred in the hardware 101.
  • the failure detection unit 111 issues a synchronization instruction to the synchronization unit 109 when a failure of the hardware 101 is detected by detecting an error message of the I / O response.
  • the synchronization unit 109 acquires a copy of the I / O request from the storage unit 112 in accordance with the synchronization instruction from the failure detection unit 111, and the guest OS 104 at the time when the failure of the hardware 101 is detected by the failure detection unit 111.
  • Information indicating the state is generated.
  • Information indicating the state of the guest OS 104 includes the process name of the process 105, the value of the programmable counter of the CPU 1011, the value of the storage area of the memory 1012 allocated to the guest OS 104, and the like.
  • the synchronization unit 109 outputs a copy of the I / O request and information indicating the state of the guest OS 104 at the time when the failure of the hardware 101 is detected to the server apparatus 200 as synchronization data.
  • the synchronization unit 109 outputs an instruction message that instructs the guest OS 204 to take over the operation performed by the guest OS 104 to the server device 200. Thereafter, in the server device 200, the guest OS 204 becomes the active system and takes over the operation of the guest OS 104.
  • the failure detection unit 111 checks the I / O response before the I / O response reaches the guest OS 104, determines whether or not a failure has occurred in the hardware 101, and the failure has occurred in the hardware 101.
  • Control is performed so that the I / O response does not reach the guest OS 104 when it occurs. Therefore, the state of the guest OS 104 notified to the guest OS 204 is a state before the detection of the hardware 101 failure, and the guest OS 204 can take over the operation of the guest OS 104 from the state before the detection of the hardware 101 failure.
  • the synchronization unit 109 is an example of a takeover control unit
  • the I / O control unit 110 is an example of a request management unit.
  • the synchronization unit 109 is an example of a takeover control unit and is expressed as a synchronization unit (takeover control unit)
  • the I / O control unit 110 is an example of a request management unit (I / O control unit ( Request management department).
  • the synchronization unit 109, the I / O control unit 110, and the failure detection unit 111 are programs that operate on the virtual machine monitor 102 or the host OS 103.
  • the programs of the synchronization unit 109, the I / O control unit 110, and the failure detection unit 111 are stored in the disk 1013 before execution, and are loaded from the disk 1013 to the memory 1012 and executed by the CPU 1011 before execution.
  • the above-described operation is performed.
  • the server device 200 has a module configuration example similar to that of the server device 100.
  • FIGS. 4 to 7 a series of flow from I / O request generation from the process 105 on the guest OS 104 to I / O response inspection and processing after I / O response inspection. Will be explained. 4 and 5 show the flow of the I / O request transfer process from the process 105 on the guest OS 104 to the hardware 101, and FIGS. 6 and 7 show the process 105 on the guest OS 104 from the hardware 101. The flow of the transfer process of the I / O response to is shown.
  • FIG. 4 and FIG. 5 will be described.
  • the process 105 on the guest OS 104 outputs an I / O request to the front end driver 106 (S101).
  • the front end driver 106 transfers the received I / O request to the back end driver 107 on the host OS 103 via the virtual machine monitor 102 (S102).
  • the I / O control unit 110 on the host OS 103 detects the I / O request and performs the processing shown in FIG. 5 (S103).
  • the I / O control unit 110 acquires an I / O request from the front-end driver 106, copies the acquired I / O request, outputs a copy of the I / O request to the storage unit 112, and stores the storage unit 112. A copy of the I / O request is stored in (S1031). Next, the I / O control unit 110 transfers the I / O request to the back-end driver 107 of the host OS 103 (S1032).
  • the back-end driver 107 receives an I / O request from the I / O control unit 110, and transfers the input I / O request to the real device driver 108 (S104).
  • the actual device driver 108 executes control of the hardware 101 based on the I / O request (S105).
  • the hardware 101 returns an I / O response to the real device driver 108 on the host OS 103 (S201).
  • the actual device driver 108 transfers the received I / O response to the back-end driver 107 (S202).
  • the back-end driver 107 transfers the I / O response to the front-end driver 106 on the guest OS 104 (S203).
  • the I / O control unit 110 on the host OS 103 detects an I / O response and performs the process shown in FIG. 7 (S204).
  • the I / O control unit 110 acquires an I / O response from the back-end driver 107, and transfers the acquired I / O response to the failure detection unit 111 (S2041).
  • the failure detection unit 111 inputs an I / O response from the I / O control unit 110 and checks whether there is an error message in the input I / O response (S2042). If the error message is not included in the I / O response, and therefore no failure has occurred in the hardware 101 (NO in S2043), the failure detection unit 111 directly controls the I / O response as I / O control.
  • the I / O control unit 110 transfers the I / O response to the front end driver 106 on the guest OS 104 (S2044).
  • the I / O control unit 110 deletes the I / O request stored in the storage unit 112 and ends the process (S2045). Then, the front-end driver 106 on the guest OS 104 returns an I / O response to the process 105 (S205).
  • an error message is included in the I / O response. For this reason, if a failure has occurred in the hardware 101 (YES in S2043), the failure detection unit 111 has detected the error message. And a synchronization instruction is output to the synchronization unit 109 (S2046).
  • the synchronization unit 109 acquires the I / O request stored in the storage unit 112 in S1031 of FIG. 5 from the storage unit 112, and generates information for notifying the state of the active guest OS 104.
  • the information for notifying the status of the I / O request and the guest OS 104 becomes the synchronization data, and the synchronization unit 109 transmits the synchronization data to the server device 200 and receives an instruction message instructing the guest OS 204 to take over the operation of the guest OS 104. It transmits to the server apparatus 200 (S2047). As described above, the state of the guest OS 104 immediately before the failure of the hardware 101 is propagated to the guest OS 104 is notified to the server device 200, and the guest OS 204 immediately before the failure of the hardware 101 is propagated to the guest OS 104.
  • the synchronization unit 109 forcibly stops the guest OS 104 of the active server device 100 after the synchronization is completed (after transmission of the synchronization data and the instruction message), and takes over the operation of the guest OS 104 to the guest OS 204 on the standby server device 200. (S2048). At this point, the operation of the guest OS 104 is resumed by the guest OS 204 on the synchronization-destination standby server apparatus 200, and the processing is continued without inheriting a hardware failure in the entire system.
  • the standby guest OS when a failure occurs in the active hardware, the standby guest OS is synchronized with the state immediately before the hardware failure is propagated to the active guest OS. Can do. As a result, the operation performed on the active guest OS can be normally transferred to the standby guest OS without being affected by the hardware failure of the active system, and the process is smoothly switched to the standby system. be able to. Further, according to the present embodiment, there is an advantage that only one synchronization data is managed. Furthermore, according to the present embodiment, there is an advantage that a mechanism for detecting a hardware failure is unnecessary on the guest OS.
  • the I / O control unit 110 and the failure detection unit 111 are included in the host OS, but the I / O control unit 110 and the failure detection unit 111 are included in the virtual machine monitor 102. Good. Further, a configuration in which the I / O control unit 110 is included in the host OS 103 and the failure detection unit 111 is included in the virtual machine monitor 102 may be employed. Further, the I / O control unit 110 may be included in the virtual machine monitor 102, and the failure detection unit 111 may be included in the host OS 103.
  • the operating state of the active guest OS is synchronized with the standby server using the virtual environment, and a hardware failure occurs in the active server
  • the hardware processing on the guest OS is performed via the virtual machine monitor, the hardware failure is detected by the host OS or the virtual machine monitor, and the hardware failure information is displayed.
  • Embodiment 2 The failure detection unit 111 according to the first embodiment detects a failure of the hardware 101 by checking whether there is no error message regarding the I / O response. On the other hand, the failure detection unit 111 may periodically check whether the hardware has no failure or the hardware is operating normally independently of the I / O response. In addition, the failure detection unit 111 checks whether there is a hardware failure or whether the hardware is operating normally when an I / O request from the front-end driver 106 arrives at the I / O control unit 110. You may do it. When a hardware failure is detected, the operations after S2046 in FIG. 7 described in the first embodiment are performed.
  • a hardware failure inspection / operation confirmation method by the failure detection unit 111 there are a method of performing communication confirmation by ping or the like regarding the network, and a method of inspecting the NIC up / down.
  • the disc for example, S.M. M.M. A. R. T.A. (Self-Monitoring, Analysis and Reporting Technology)
  • IPMI Intelligent Platform Management Interface
  • the failure detection unit 111 periodically checks for a failure in the hardware 101, a copy of the I / O request may not be stored in the storage unit 112 when the failure in the hardware 101 is detected. If the copy of the I / O request is not stored in the storage unit 112, the synchronization unit 109 synchronizes information indicating the state of the guest OS 104 at the time when the failure of the hardware 101 is detected in S2047 of FIG. The data is output to the server device 200 as data. On the other hand, when a copy of the I / O request is stored in the storage unit 112, the synchronization unit 109 indicates information indicating the state of the guest OS 104 when a failure of the hardware 101 is detected in S2047 of FIG.
  • a copy of the I / O request is output to the server device 200 as synchronization data.
  • the synchronization unit 109 uses the server apparatus 200 as a synchronous data copy of the I / O request together with information indicating the state of the guest OS 104 at the time when the failure of the hardware 101 is detected in S2047 of FIG. Output to.
  • the system configuration according to the present embodiment is also as shown in FIG.
  • the standby guest OS is returned to the state immediately before the hardware failure is propagated to the active guest OS. Can be synchronized. As a result, the operation performed on the active guest OS can be normally transferred to the standby guest OS without being affected by the hardware failure of the active system, and the process is smoothly switched to the standby system. be able to. Further, according to the present embodiment, it is possible to detect a hardware failure at a stage where an I / O request is made, and it is possible to detect a hardware failure earlier than in the first embodiment.
  • the hardware I / O processing on the guest OS is performed via the virtual machine monitor or the host OS, and the I / O from the guest OS on the host OS or the virtual machine monitor is used. Keep your request temporarily,
  • the host OS or virtual machine monitor detects a failure related to hardware I / O, and before the failure information related to the hardware I / O is notified to the guest OS, the host OS or virtual Discard failure information related to hardware I / O on the machine monitor,
  • the operating state in which the guest OS issued an I / O request is synchronized with the standby system, and the synchronization data is used to cause a failure on the standby server device.
  • the virtual environment synchronization system has been described in which the guest OS can be continuously operated by resuming the operation of the guest OS immediately before the occurrence of the error.
  • Embodiment 3 In the first embodiment, a flow from the occurrence of hardware failure to system switching in a system in which one guest OS is arranged in each server device is shown. However, there are a plurality of guest OSs to be synchronized by the software FT. Also good. In other words, the present embodiment targets a system in which two or more guest OSs are arranged in the active server device and a guest OS corresponding to each guest OS in the active server device is arranged in the standby server device. . When a failure occurs in the hardware of the active server device, the synchronization unit of the active server device outputs synchronization data to the standby server device for each guest OS.
  • the standby server device takes over the operation of the active guest OS by synchronizing each guest OS with the state of the active guest OS immediately before the failure of the active hardware based on the synchronization data. Make it.
  • the storage unit 112 shown in the first embodiment is prepared for each guest OS, and when an error message is detected in the I / O response, the synchronization unit 109 starts from the storage unit 112 for each guest OS. An I / O request for each guest OS is acquired, and synchronization data and instruction data are output for each guest OS.
  • the failure detection unit 111 detects a failure of the hardware 101 by a periodic inspection, or when an I / O request reaches the I / O control unit 110.
  • the synchronization unit 109 acquires an I / O request for each guest OS from the storage unit 112 for each guest OS, and for each guest OS Synchronous data and instruction data are output. Other operations are as described in the first embodiment and the second embodiment, and a description thereof will be omitted.
  • the standby guest OS can be synchronized with the state immediately before the hardware failure is propagated to the active guest OS. it can.
  • the standby guest OS can normally take over the operations performed on the active guest OS without being affected by the hardware failure of the active system. And the process can be smoothly switched to the standby system.
  • FIG. 8 is a diagram illustrating an example of hardware resources of the server apparatuses 100 and 200 described in the first to third embodiments.
  • the configuration in FIG. 8 is merely an example of the hardware configuration of the server apparatuses 100 and 200, and the hardware configuration of the server apparatuses 100 and 200 is not limited to the configuration illustrated in FIG. There may be.
  • the server apparatuses 100 and 200 include a CPU 911 (also referred to as a central processing unit, a central processing unit, a processing unit, an arithmetic unit, a microprocessor, a microcomputer, and a processor) that executes a program.
  • the CPU 911 receives, 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, a magnetic disk device 920, and a scanner device 907 via a bus 912. Connected and controls these hardware devices.
  • the CPU 911 may be connected to an FDD 904 (Flexible Disk Drive), a compact disk device 905 (CDD), and a printer device 906.
  • FDD 904 Flexible Disk Drive
  • CDD compact disk device
  • printer device 906 a storage device such as an optical disk device or a memory card (registered trademark) read / write device 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.
  • a communication board 915, a keyboard 902, a mouse 903, an FDD 904, a scanner device 907, and the like are examples of input devices.
  • the communication board 915, the display device 901, the printer device 906, and the like are examples of output devices.
  • the communication board 915 is connected to the LAN 300 as shown in FIG.
  • the communication board 915 can be connected to, for example, the Internet, a WAN (wide area network), or the like.
  • the magnetic disk device 920 stores a virtual machine monitor 921, a host 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 host OS 922.
  • the virtual machine monitor 921 itself includes the function of the host OS 922 or the virtual machine monitor 921 exists in the host OS 922.
  • the ROM 913 stores a BIOS (Basic Input Output System) program
  • the magnetic disk device 920 stores a boot program.
  • BIOS Basic Input Output System
  • the server devices 100 and 200 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 host OS 922 are activated by the BIOS program and the boot program.
  • the program group 923 includes programs for realizing the synchronization unit 109, the I / O control unit 110, and the failure detection unit 111 described in the first to third embodiments.
  • the file group 924 includes “Judgment of”, “Examination of”, “Detection of”, “Synchronization of”, “Check of”, “ Information, data, signal values, variable values, and parameters that indicate the results of the processing described as “control of”, “setting of”, “selection of”, etc. It is stored as an item.
  • 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.
  • the data and signal values are the RAM 914 memory, the FDD 904 flexible disk, the CDD 905 compact disk, and the magnetic field. Recording is performed on a recording medium such as a magnetic disk of the disk device 920, other optical disks, mini disks, DVDs, and the like. Data and signals are transmitted online via a bus 912, signal lines, cables, or other transmission media.
  • what is described as “to part” in the description of the first to third embodiments may be “to step”, “to procedure”, and “to process”. That is, what is described as “ ⁇ unit” may be realized by firmware stored in the ROM 913. Alternatively, it may be implemented only by software, or only by hardware such as elements, devices, substrates, and wirings, by a combination of software and hardware, or by a combination of 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 mini disk, and a DVD.
  • the program is read by the CPU 911 and executed by the CPU 911. In other words, the program causes the computer to function as the “unit” in the first to third embodiments. Alternatively, the computer executes the procedure and method of “unit” in the first to third embodiments. It is also possible to grasp the operations of the server apparatuses 100 and 200 described in the first to third embodiments as, for example, a data processing method.
  • the server devices 100 and 200 described in the first to third embodiments include a CPU as a processing device, a memory as a storage device, a magnetic disk, a keyboard as an input device, a mouse, a communication board, and a display device as an output device, A computer provided with a communication board or the like, and implements the functions indicated as “ ⁇ units” using the processing device, storage device, input device, and output device as described above.
  • server device 101 hardware, 102 virtual machine monitor, 103 host OS, 104 guest OS, 105 process, 106 front end driver, 107 back end driver, 108 real device driver, 109 synchronization unit, 110 I / O control unit, 111 failure detection unit, 112 storage unit, 200 server device, 201 hardware, 202 virtual machine monitor, 203 host OS, 204 guest OS, 300 LAN, 1011 CPU, 1012 memory, 1013 disk, 1014 NIC.

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Software Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Quality & Reliability (AREA)
  • Hardware Redundancy (AREA)

Abstract

　Ｉ／Ｏ制御部１１０は、ゲストＯＳ１０４からのＩ／Ｏリクエストを入力し、Ｉ／Ｏリクエストのコピーを保存部１１２に格納し、ハードウェア１０１がＩ／Ｏリクエストに対するＩ／Ｏレスポンスを出力した際に、障害検知部１１１がＩ／Ｏレスポンスを検査し、Ｉ／Ｏレスポンスにエラーメッセージがある場合に、ハードウェア１０１に障害が発生していると判断し、Ｉ／Ｏレスポンスを破棄し、同期部１０９に同期指示を行い、同期部１０９は、保存部１１２内のＩ／Ｏリクエストのコピーと、ハードウェア１０１の障害が検知された時点でのゲストＯＳ１０４の状態を示す情報をサーバ装置２００に出力し、サーバ装置２００では、同期部１０９からの情報をもとに、ゲストＯＳ２０４をゲストＯＳ１０４と同じ状態にし、ゲストＯＳ２０４がゲストＯＳ１０４の動作を引き継ぐ。

Description

計算機装置及びプログラム
　本発明は、冗長構成をとる仮想計算機システムを管理する技術に関する。
　仮想化技術を応用し、例えば、二つの仮想マシンを二つのサーバ装置（物理計算機装置）上で構築し、二つの仮想マシンを同期させて、仮想マシンを二重化し、ソフトウェア的にＦＴ（Ｆａｕｌｔ　Ｔｏｌｅｒａｎｔ：耐障害性）を実現する技術（以下、ソフトウェアＦＴと呼ぶ）がある（例えば、非特許文献１、非特許文献２）。
　このソフトウェアＦＴの環境では、運用系のサーバ装置で動作するゲストＯＳ（Ｏｐｅｒａｔｉｎｇ　Ｓｙｓｔｅｍ）の状態（メモリ、ディスク等）を動作ごと、または、ある一定周期ごとに待機系のサーバ装置上へ同期（コピー）しておく。
　そして、運用系のサーバ装置で障害が発生した場合に、待機系のサーバ装置上にコピーしておいたゲストＯＳの状態から、ゲストＯＳの動作を待機系のサーバ装置において再開させることで、すばやい動作の再開が可能となる。
　しかし、従来のソフトウェアＦＴ環境では、運用系のサーバ装置で発生したハードウェア故障に起因するディスクやネットワークなどのＩ／Ｏ（Ｉｎｐｕｔ／Ｏｕｔｐｕｔ）エラーに関する内部処理まで同期対象になりうる。
　つまり、ハードウェア故障に起因するディスクやネットワークなどのＩ／Ｏエラーに関する内部処理までが、待機系のサーバ装置にコピーされることになる。
　そして、運用系のサーバ装置にハードウェア故障が発生した場合に、ハードウェア故障に起因するＩ／Ｏエラーに関する内部処理が待機系のサーバ装置にコピーされ、また、待機系のゲストＯＳが運用系のゲストＯＳの動作を引き継ぐ。
　このとき、待機系のゲストＯＳでも、同様の状態（例えば、Ｉ／Ｏリトライ処理中の状態や、Ｉ／Ｏエラーが返された状態）で動作が異常になり、結果として、両系で異常になる可能性がある。
　これに対し、特許文献１に記載の技術では、ゲストＯＳの稼動状態と、定期的に取得するゲストＯＳ状態（特許文献１ではスナップショットデータとしているが、本明細書では、以降は同期データと称する）を関連付けて保存する。
　更に、特許文献１の技術では、運用系のサーバ装置で故障が発生した場合には、該当故障が発生していないゲストＯＳ稼動状態までさかのぼって同期データを選択し、選択した同期データを用いて待機系のサーバ装置においてゲストＯＳの動作を再開させる。
　このようにして、特許文献１の技術では、故障による処理異常を継承させることなくゲストＯＳを切り替えることを可能としている。
特開２００７－１８３７０１号公報
Ｒｅｍｕｓ：　Ｈｉｇｈ　Ａｖａｉｌａｂｉｌｉｔｙ　ｖｉａ　Ａｓｙｎｃｈｒｏｎｏｕｓ　Ｖｉｒｔｕａｌ　Ｍａｃｈｉｎｅ　Ｒｅｐｌｉｃａｔｉｏｎ、ｈｔｔｐ：／／ｎｓｓ．ｃｓ．ｕｂｃ．ｃａ／ｒｅｍｕｓ／ Ｋｅｍａｒｉ：　仮想マシン間の同期による耐故障クラスタリング、情報処理学会論文誌　コンピューティングシステム、Ｖｏｌ．３、Ｎｏ．１（Ｍａｒ．２０１０）
　しかし、特許文献１では故障を検知する機構をゲストＯＳ上に配置しているため、故障検知にタイムラグがあり、結局はゲストＯＳへハードウェア故障状態が伝播した状態を待機系のサーバ装置に通知することになる。
　このため、前述したように、待機系のゲストＯＳが動作を開始しても、待機系のサーバ装置においてハードウェア障害が発生したのと同様の状態になってしまう。
　また、特許文献１の方法では、複数の同期データを管理しておく必要があり、データ量が増大する。
　さらに、故障検知のタイミングによっては、相当量の時間をさかのぼった同期データから待機系のゲストＯＳが動作を再開させなければならない場合がある。
　この発明は、上記のような課題を解決することを主な目的の一つとしており、ハードウェア障害の影響を受けることなく、待機系においてゲストＯＳの動作を正常に引き継げるようにすることを主な目的とする。
　本発明に係る計算機装置は、
　ハードウェアと、前記ハードウェアを用いて実現される仮想マシン上で動作し、前記ハードウェアへのリクエストを発行する第１のゲストＯＳ（Ｏｐｅｒａｔｉｎｇ　Ｓｙｓｔｅｍ）とを有し、
　前記第１のゲストＯＳと同じ動作を行う第２のゲストＯＳを有する外部装置に接続されている計算機装置であって、
　前記第１のゲストＯＳにより発行されたリクエストのコピーを所定の記憶領域に格納するリクエスト管理部と、
　前記リクエストに対する前記ハードウェアからのレスポンスが前記第１のゲストＯＳに届く前に前記ハードウェアに障害が発生しているか否かを判断し、前記ハードウェアに障害が発生している場合に前記レスポンスが前記第１のゲストＯＳに届かないように制御する障害検知部と、
　前記障害検知部により前記ハードウェアの障害が検知された場合に、前記記憶領域に格納されている前記リクエストのコピーと前記ハードウェアの障害が検知された時点での前記第１のゲストＯＳの状態を示す情報を前記外部装置に出力し、前記第１のゲストＯＳが行っていた動作を前記第２のゲストＯＳにて引き継ぐよう指示する指示メッセージを前記外部装置に出力する引き継ぎ制御部とを有することを特徴とする。
　本発明によれば、ハードウェアからのレスポンスが第１のゲストＯＳに届く前にハードウェアに障害が発生しているか否かを判断し、ハードウェアに障害が発生している場合にレスポンスが第１のゲストＯＳに届かないように制御し、ハードウェアの障害が検知された時点での第１のゲストＯＳの状態を示す情報及びリクエストのコピーを外部装置に出力するため、ハードウェア障害を検知する直前の状態から第２のゲストＯＳを動作させることができる。
　これにより、ハードウェア障害の影響を受けることなく、第２のゲストＯＳに第１のゲストＯＳで行われてきた動作を正常に引き継がせることができる。
実施の形態１に係るシステム構成例を示す図。 仮想化環境での一般的なＩ／Ｏ処理の流れを示す図。 実施の形態１に係るＩ／Ｏ処理の流れを示す図。 実施の形態１に係るＩ／Ｏリクエストの転送処理の例を示すフローチャート図。 実施の形態１に係るＩ／Ｏ制御部の動作例を示すフローチャート図。 実施の形態１に係るＩ／Ｏレスポンスの転送処理の例を示すフローチャート図。 実施の形態１に係るＩ／Ｏ制御部、障害検知部及び同期部の動作例を示すフローチャート図。 実施の形態１～３に係るサーバ装置のハードウェア構成例を示す図。
　実施の形態１．
　本実施の形態では、運用系のサーバ装置と待機系のサーバ装置が配置されている構成において、運用系のゲストＯＳ上に故障を検知する機構を加えることなく、運用系のホストＯＳや仮想マシンモニタでハードウェアの障害を検知し、当該ハードウェア障害に関する障害情報を破棄し、運用系のゲストＯＳへハードウェアの障害情報が伝播しないようにする。
　このようにして、運用系のゲストＯＳにハードウェア障害を認識させないようにする。
　また、本実施の形態では、その後、運用系のサーバ装置から、運用系のゲストＯＳの状態を通知する同期データ及び運用系のゲストＯＳの動作を待機系のゲストＯＳで引き継ぐよう指示する指示データを待機系のサーバ装置に出力する。
　そして、待機系のサーバ装置は、同期データを用いて、待機系のゲストＯＳの状態を運用系のゲストＯＳの状態と同じにし、運用系のサーバ装置におけるハードウェア障害の影響を受けることなく、待機系のゲストＯＳが運用系のゲストＯＳの動作を正常に引き継ぐ。
　図１は、本実施の形態に係るシステム構成を示す。
　図１に示すように、ＬＡＮ（Ｌｏｃａｌ　Ａｒｅａ　Ｎｅｔｗｏｒｋ）３００によりサーバ装置１００とサーバ装置２００が接続されている。
　サーバ装置１００とサーバ装置２００は、それぞれ異なる物理計算機装置である。
　本実施の形態では、サーバ装置１００が運用系のサーバ装置であり、サーバ装置２００が待機系のサーバ装置である例にて説明を進める。
　このため、サーバ装置１００が計算機装置の例であり、また、サーバ装置２００が外部装置の例である。
　図１では、サーバ装置１００が計算機装置の例であることを運用系サーバ装置（計算機装置）と表現し、また、サーバ装置２００が外部装置の例であることを待機系サーバ装置（外部装置）と表現している。
　ハードウェア１０１（物理ハードウェア）には、例えば、ＣＰＵ（Ｃｅｎｔｒａｌ　Ｐｒｏｃｅｓｓｉｎｇ　Ｕｎｉｔ）１０１１、メモリ１０１２、ディスク１０１３及びＮＩＣ（Ｎｅｔｗｏｒｋ　Ｉｎｔｅｒｆａｃｅ　Ｃａｒｄ）１０１４が含まれている。
　なお、ハードウェア１０１には、これら以外のハードウェア要素が含まれていてもよい。
　ハードウェア１０１上では仮想マシンモニタ１０２が動作し、更に、仮想マシンモニタ１０２上ではホストＯＳ１０３とゲストＯＳ１０４が動作している。
　ゲストＯＳ１０４は、仮想マシンモニタ１０２及びホストＯＳ１０３により実現される仮想マシンにより提供される仮想ハードウェア（仮想ＣＰＵ、仮想メモリ、仮想ディスク、仮想ＮＩＣ等）を利用して動作する。
　なお、ゲストＯＳは、第１のゲストＯＳの例である。
　図１では、ゲストＯＳ１０４が第１のゲストＯＳの例であることを括弧書きで示している。
　運用系のサーバ装置１００が正常に動作している場合（ハードウェア障害が発生していない場合）には、運用系のゲストＯＳ１０４の状態（ゲストＯＳ１０４のコンテキスト）が、Ｉ／Ｏ（Ｉｎｐｕｔ／Ｏｕｔｐｕｔ）処理ごと、または、一定周期で、同期部１０９によって待機系のサーバ装置２００に通知され、ゲストＯＳ２０４がゲストＯＳ１０４と同期している（ゲストＯＳ１０４の状態とゲストＯＳ２０４の状態が一致している）。
　ゲストＯＳ２０４は、ゲストＯＳ１０４と同じ動作を行うゲストＯＳであり、第２のゲストＯＳの例である。
　図１では、ゲストＯＳ２０４が第２のゲストＯＳの例であることを括弧書きで示している。
　ゲストＯＳ１０４の最新状態を通知するデータを同期データという。
　同期データは、１つ前の同期データに示されていた状態との差分が示される。
　また、ゲストＯＳ２０４では、新たな同期データが入力される度に、以前の同期データが新たな同期データで上書きされる。すなわち、同期データは１つしかない。
　なお、同期部１０９は、仮想マシンモニタ１０２とホストＯＳ１０３に跨って動作する。
　ゲストＯＳ１０４では通常プロセス１０５が動作しており、その処理内容によっては、ハードウェア１０１へＩ／Ｏリクエストを出すことになる。
　Ｉ／Ｏリクエストの例としては、ディスク１０１３からのデータの読み出し、ディスク１０１３へのデータの書き込み、ＮＩＣ１０１４を介してのネットワークへのデータ送信、ＮＩＣ１０１４を介してのネットワークからのデータの受信がある。
　なお、Ｉ／Ｏリクエストは、ゲストＯＳ１０４からハードウェア１０１へのリクエストである。
　また、後述するハードウェア１０１からゲストＯＳ１０４へのＩ／Ｏレスポンスは、リクエストに対するハードウェア１０１からのレスポンスである。
　仮想化環境でのＩ／Ｏ処理の流れは図２のようになっており、プロセス１０５からのＩ／Ｏリクエストは、ゲストＯＳ１０４上のフロントエンドドライバ１０６へ渡され、仮想マシンモニタ１０２を経由して、ホストＯＳ１０３上のバックエンドドライバ１０７へ渡される。
　ホストＯＳ１０３上のバックエンドドライバ１０７はＩ／Ｏリクエストを実デバイスドライバ１０８へ渡し、実デバイスドライバ１０８は実際のハードウェア１０１へＩ／Ｏリクエストを実行する。
　ハードウェアで処理されたＩ／Ｏレスポンスは、実デバイスドライバ１０８へ返され、実デバイスドライバ１０８からホストＯＳ１０３上のバックエンドドライバ１０７、仮想マシンモニタ１０２を経由して、ゲストＯＳ１０４上のフロントエンドドライバ１０６へ転送され、Ｉ／Ｏリクエストを出したプロセス１０５へ返される。
　本実施の形態では、フロントエンドドライバ１０６とバックエンドドライバ１０７間のＩ／Ｏリクエスト及びＩ／Ｏレスポンスを制御するＩ／Ｏ制御部１１０をホストＯＳ１０３上に配置する。
　また、Ｉ／Ｏ制御部１１０で検知したＩ／Ｏレスポンスに関して、障害が無いかどうかを検査する障害検知部１１１を配置する。
　さらに、ゲストＯＳ１０４からのＩ／Ｏリクエストのコピーを一時的に保管しておく保存部１１２を仮想マシンモニタ１０２上に配置する。
　より詳しくは、図３に示すように、Ｉ／Ｏ制御部１１０は、フロントエンドドライバ１０６からのＩ／Ｏリクエストを入力し、入力したＩ／Ｏリクエストをコピーし、Ｉ／Ｏリクエストのコピーを保存部１１２に格納し、Ｉ／Ｏリクエストをバックエンドドライバ１０７に出力する。
　なお、仮想マシンモニタ１０２では、Ｉ／Ｏ制御部１１０からのＩ／Ｏリクエストのコピーを保存部１１２と関連付けられている物理記憶領域に記憶させる。
　仮想マシンモニタ１０２は、例えば、メモリ１０１２の所定のアドレス又はＣＰＵ１０１１のレジスタにＩ／Ｏリクエストのコピーを記憶させる。
　以降は、図２の場合と同様に、Ｉ／Ｏリクエストがバックエンドドライバ１０７から実デバイスドライバ１０８を経由してハードウェア１０１に到達する。
　次に、ハードウェア１０１は、Ｉ／Ｏリクエストに対するレスポンスであるＩ／Ｏレスポンスを実デバイスドライバ１０８に出力し、Ｉ／Ｏ制御部１１０はバックエンドドライバ１０７からＩ／Ｏレスポンスを入力する。
　そして、Ｉ／Ｏ制御部１１０は入力したＩ／Ｏレスポンスを障害検知部１１１に出力する。
　障害検知部１１１は、Ｉ／Ｏ制御部１１０からＩ／Ｏレスポンスを入力し、入力したＩ／Ｏレスポンスを検査し、Ｉ／Ｏレスポンスにエラーメッセージが存在している場合に、ハードウェア１０１に障害が発生していると判断し、当該Ｉ／Ｏレスポンスを破棄し、Ｉ／Ｏレスポンスにエラーメッセージが存在していない場合に、当該Ｉ／ＯレスポンスをＩ／Ｏ制御部１１０を介してフロントエンドドライバ１０６に出力する。
　なお、Ｉ／Ｏレスポンスのエラーメッセージはハードウェア１０１における障害を通知するメッセージであるため、障害検知部１１１は、Ｉ／Ｏレスポンスからエラーメッセージを検出した場合には、ハードウェア１０１に障害が発生していると判断できる。
　また、障害検知部１１１は、Ｉ／Ｏレスポンスのエラーメッセージの検出により、ハードウェア１０１の障害を検知した場合に、同期部１０９に同期指示を行う。
　同期部１０９では、障害検知部１１１からの同期指示に従い、保存部１１２からＩ／Ｏリクエストのコピーを取得するとともに、障害検知部１１１によりハードウェア１０１の障害が検知された時点でのゲストＯＳ１０４の状態を示す情報を生成する。
　ゲストＯＳ１０４の状態を示す情報は、プロセス１０５のプロセス名、ＣＰＵ１０１１のプログラマブルカウンタの値、ゲストＯＳ１０４に割り当てられているメモリ１０１２の記憶領域の値等である。
　同期部１０９は、Ｉ／Ｏリクエストのコピーと、ハードウェア１０１の障害が検知された時点でのゲストＯＳ１０４の状態を示す情報を同期データとしてサーバ装置２００に出力する。
　また、同期部１０９は、ゲストＯＳ１０４が行っていた動作をゲストＯＳ２０４にて引き継ぐよう指示する指示メッセージをサーバ装置２００に出力する。
　以降、サーバ装置２００では、ゲストＯＳ２０４が運用系となり、ゲストＯＳ１０４の動作を引き継ぐ。
　このように、障害検知部１１１がＩ／ＯレスポンスがゲストＯＳ１０４に届く前にＩ／Ｏレスポンスを検査し、ハードウェア１０１に障害が発生しているか否かを判断し、ハードウェア１０１に障害が発生している場合にＩ／ＯレスポンスがゲストＯＳ１０４に届かないように制御している。
　このため、ゲストＯＳ２０４に通知するゲストＯＳ１０４の状態は、ハードウェア１０１障害の検知前の状態であり、ゲストＯＳ２０４はハードウェア１０１障害の検知前の状態からゲストＯＳ１０４の動作を引き継ぐことができる。
　本実施の形態では、同期部１０９は引き継ぎ制御部の例であり、Ｉ／Ｏ制御部１１０はリクエスト管理部の例である。
　図１では、同期部１０９が引き継ぎ制御部の例であることを同期部（引き継ぎ制御部）と表現し、Ｉ／Ｏ制御部１１０がリクエスト管理部の例であることをＩ／Ｏ制御部（リクエスト管理部）と表現している。
　また、上述したように、同期部１０９、Ｉ／Ｏ制御部１１０、障害検知部１１１は、仮想マシンモニタ１０２又はホストＯＳ１０３で動作するプログラムである。
　同期部１０９、Ｉ／Ｏ制御部１１０、障害検知部１１１のプログラムは、例えば、実行前はディスク１０１３に格納されており、実行に際して、ディスク１０１３からメモリ１０１２にロードされ、ＣＰＵ１０１１により実行されて、上述の動作が行われる。
　なお、図示は省略しているが、サーバ装置２００においても、サーバ装置１００と同様のモジュール構成例となっている。
　次に、本実施の形態に係る動作（ハードウェアに関する故障をゲストＯＳへ通知しないようにして、待機系へ切り替える動作）を説明する。
　具体的には、図４～図７を用いて、ゲストＯＳ１０４上のプロセス１０５からのＩ／Ｏリクエスト発生から、Ｉ／Ｏレスポンスの検査、Ｉ／Ｏレスポンスの検査後の処置までの一連の流れを説明する。
　なお、図４及び図５は、ゲストＯＳ１０４上のプロセス１０５からハードウェア１０１へのＩ／Ｏリクエストの転送処理の流れを示し、図６及び図７は、ハードウェア１０１からゲストＯＳ１０４上のプロセス１０５へのＩ／Ｏレスポンスの転送処理の流れを示す。
　まず、図４及び図５について説明する。
　最初に、ゲストＯＳ１０４上のプロセス１０５は、フロントエンドドライバ１０６に対してＩ／Ｏリクエストを出力する（Ｓ１０１）。
　フロントエンドドライバ１０６は、受け取ったＩ／Ｏリクエストを仮想マシンモニタ１０２を経由してホストＯＳ１０３上のバックエンドドライバ１０７へ転送する（Ｓ１０２）。
　このとき、ホストＯＳ１０３上のＩ／Ｏ制御部１１０がＩ／Ｏリクエストを検知し、図５に示す処理を行う（Ｓ１０３）。
　まず、Ｉ／Ｏ制御部１１０はフロントエンドドライバ１０６からのＩ／Ｏリクエストを取得し、取得したＩ／Ｏリクエストをコピーし、Ｉ／Ｏリクエストのコピーを保存部１１２に出力し、保存部１１２にＩ／Ｏリクエストのコピーを格納する（Ｓ１０３１）。
　次に、Ｉ／Ｏ制御部１１０は、Ｉ／ＯリクエストをホストＯＳ１０３のバックエンドドライバ１０７へ転送する（Ｓ１０３２）。
　バックエンドドライバ１０７は、Ｉ／Ｏ制御部１１０からＩ／Ｏリクエストを入力し、入力したＩ／Ｏリクエストを実デバイスドライバ１０８へ転送する（Ｓ１０４）。
　実デバイスドライバ１０８はＩ／Ｏリクエストを元に、ハードウェア１０１の制御を実行する（Ｓ１０５）。
　以上が、プロセスからハードウェアへのＩ／Ｏリクエストまでの流れである。
　次に、Ｉ／Ｏリクエストに対するＩ／Ｏレスポンスがハードウェアから返されたときの流れを図６及び図７を参照して説明する。
　まず、ハードウェア１０１はホストＯＳ１０３上の実デバイスドライバ１０８へＩ／Ｏレスポンスを返す（Ｓ２０１）。
　実デバイスドライバ１０８は、受け取ったＩ／Ｏレスポンスをバックエンドドライバ１０７へ転送する（Ｓ２０２）。
　バックエンドドライバ１０７はゲストＯＳ１０４上のフロントエンドドライバ１０６へＩ／Ｏレスポンスを転送する（Ｓ２０３）。
　このとき、ホストＯＳ１０３上のＩ／Ｏ制御部１１０がＩ／Ｏレスポンスを検知し、図７に示す処理を行う（Ｓ２０４）。
　まず、Ｉ／Ｏ制御部１１０はバックエンドドライバ１０７からのＩ／Ｏレスポンスを取得し、取得したＩ／Ｏレスポンスを障害検知部１１１へ転送する（Ｓ２０４１）。
　障害検知部１１１は、Ｉ／Ｏ制御部１１０からＩ／Ｏレスポンスを入力し、入力したＩ／Ｏレスポンスにエラーメッセージが無いかチェックする（Ｓ２０４２）。
　Ｉ／Ｏレスポンスにエラーメッセージが含まれておらず、このため、ハードウェア１０１に障害が発生していない場合（Ｓ２０４３でＮＯ）は、障害検知部１１１はＩ／ＯレスポンスをそのままＩ／Ｏ制御部１１０に転送し、Ｉ／Ｏ制御部１１０がＩ／ＯレスポンスをゲストＯＳ１０４上のフロントエンドドライバ１０６へ転送する（Ｓ２０４４）。
　また、Ｉ／Ｏ制御部１１０は保存部１１２で保存しておいたＩ／Ｏリクエストを削除し、処理を終了する（Ｓ２０４５）。
　そして、ゲストＯＳ１０４上のフロントエンドドライバ１０６はプロセス１０５に対してＩ／Ｏレスポンスを返す（Ｓ２０５）。
　一方、Ｉ／Ｏレスポンスにエラーメッセージが含まれており、このため、ハードウェア１０１に障害が発生している場合（Ｓ２０４３でＹＥＳ）は、障害検知部１１１はエラーメッセージを検出したＩ／Ｏレスポンスを破棄し、同期部１０９へ同期指示を出力する（Ｓ２０４６）。
　同期部１０９は図５のＳ１０３１において保存部１１２で保存しておいたＩ／Ｏリクエストを保存部１１２から取得し、また、運用系のゲストＯＳ１０４の状態を通知する情報を生成する。
　これらＩ／ＯリクエストとゲストＯＳ１０４の状態を通知する情報が同期データとなり、同期部１０９は、同期データをサーバ装置２００に送信するとともに、ゲストＯＳ２０４においてゲストＯＳ１０４の動作を引き継ぐよう指示する指示メッセージをサーバ装置２００に送信する（Ｓ２０４７）。
　このように、ゲストＯＳ１０４へハードウェア１０１の障害が伝播される直前のゲストＯＳ１０４の状態がサーバ装置２００に通知され、ゲストＯＳ２０４は、ゲストＯＳ１０４へハードウェア１０１の障害が伝播される直前のゲストＯＳ１０４の状態に同期することができる。
　次に、同期部１０９は同期完了後（同期データ及び指示メッセージの送信後）、運用系サーバ装置１００のゲストＯＳ１０４を強制停止させ、待機系サーバ装置２００上のゲストＯＳ２０４にゲストＯＳ１０４の動作を引き継がせる（Ｓ２０４８）。
　この時点で、同期先の待機系サーバ装置２００上のゲストＯＳ２０４でゲストＯＳ１０４の動作が再開し、システム全体としてはハードウェアの故障を継承することなく処理が継続される。
　このように、本実施の形態によれば、運用系のハードウェアで故障が発生した場合に、運用系のゲストＯＳへハードウェア障害が伝播する直前の状態に待機系のゲストＯＳを同期させることができる。
　これにより、運用系のハードウェア障害の影響を受けることなく、待機系のゲストＯＳに運用系のゲストＯＳで行われてきた動作を正常に引き継がせることができ、処理を円滑に待機系へ切り替えることができる。
　また、本実施の形態によれば、管理する同期データは１つでよいという利点がある。
　更に、本実施の形態によれば、ゲストＯＳ上にハードウェア故障を検知する機構が不要であるという利点がある。
　なお、以上の説明では、Ｉ／Ｏ制御部１１０及び障害検知部１１１は、ホストＯＳに含まれている、Ｉ／Ｏ制御部１１０及び障害検知部１１１が仮想マシンモニタ１０２に含まれていてもよい。
　また、Ｉ／Ｏ制御部１１０がホストＯＳ１０３に含まれ、障害検知部１１１が仮想マシンモニタ１０２に含まれている構成でもよい。
　また、Ｉ／Ｏ制御部１１０が仮想マシンモニタ１０２に含まれ、障害検知部１１１がホストＯＳ１０３に含まれていている構成でもよい。
　以上、本実施の形態では、
　ハードウェア異常が発生した場合の二重系システム切替に関し、仮想化環境を用いて運用系ゲストＯＳの動作状態を待機系サーバ装置と同期しておき、運用系サーバ装置にハードウェア故障が生じた場合に、待機系サーバ装置上にて同期しておいたゲストＯＳのデータを用いて、動作を再開させる仮想化環境同期システムにおいて、
　仮想化環境では、ゲストＯＳ上のハードウェアの処理が仮想マシンモニタを経由して行われることを利用し、ホストＯＳ、または、仮想マシンモニタでハードウェア故障を検知し、そのハードウェア故障情報が該当ゲストＯＳに通知される前に、ホストＯＳ、または、仮想マシンモニタでハードウェア故障情報通知を止め、
　該当ゲストＯＳがハードウェア故障を検知する前の動作状態を待機系へ同期させ、その同期データを用いて待機系サーバ装置上でゲストＯＳ動作を再開させることで、
　該当ゲストＯＳが継続して動作が可能な仮想化環境同期システムを説明した。
　実施の形態２．
　実施の形態１の障害検知部１１１は、Ｉ／Ｏレスポンスに関してエラーメッセージが無いかどうかをチェックしてハードウェア１０１の障害を検知していた。
　これに対し、障害検知部１１１は、Ｉ／Ｏレスポンスから独立して定期的にハードウェアに故障が無いか、ハードウェアが正常に稼働しているかを検査するようにしてもよい。
　また、障害検知部１１１は、フロントエンドドライバ１０６からのＩ／ＯリクエストがＩ／Ｏ制御部１１０に到着した段階でハードウェアに故障が無いか、ハードウェアが正常に稼働しているかを検査するようにしてもよい。
　そして、ハードウェア故障が検知された場合には、実施の形態１で説明した図７のＳ２０４６以降の動作を行うようにする。
　ここで、障害検知部１１１によるハードウェア故障の検査／稼動確認方法としては、ネットワークに関してはｐｉｎｇ等で疎通確認を実施したり、ＮＩＣのｕｐ／ｄｏｗｎを検査する方法がある。
　また、ディスクに関しては、例えば、Ｓ．Ｍ．Ａ．Ｒ．Ｔ．（Ｓｅｌｆ－Ｍｏｎｉｔｏｒｉｎｇ，　Ａｎａｌｙｓｉｓ　ａｎｄ　Ｒｅｐｏｒｔｉｎｇ　Ｔｅｃｈｎｏｌｏｇｙ）情報からディスクの状態を取得して検査する方法がある。
　さらに、サーバ装置本体の状態としては、ＩＰＭＩ（Ｉｎｔｅｌｌｉｇｅｎｔ　Ｐｌａｔｆｏｒｍ　Ｍａｎａｇｅｍｅｎｔ　Ｉｎｔｅｒｆａｃｅ）を用いて、電源、ファン、プロセッサ、メモリ等の故障を検知することも可能である。
　なお、障害検知部１１１が定期的にハードウェア１０１の故障を検査する場合は、ハードウェア１０１の障害を検知した時点では保存部１１２にＩ／Ｏリクエストのコピーが格納されていない場合もある。
　保存部１１２にＩ／Ｏリクエストのコピーが格納されていない場合は、同期部１０９は、図７のＳ２０４７において、ハードウェア１０１の障害が検知された時点でのゲストＯＳ１０４の状態を示す情報を同期データとしてサーバ装置２００に出力する。
　一方、保存部１１２にＩ／Ｏリクエストのコピーが格納されている場合は、同期部１０９は、図７のＳ２０４７において、ハードウェア１０１の障害が検知された時点でのゲストＯＳ１０４の状態を示す情報とともに、Ｉ／Ｏリクエストのコピーを同期データとしてサーバ装置２００に出力する。
　フロントエンドドライバ１０６からのＩ／ＯリクエストがＩ／Ｏ制御部１１０に到着した段階で障害検知部１１１がハードウェア１０１の故障を検査する場合は、保存部１１２にＩ／Ｏリクエストのコピーが格納されているので、同期部１０９は、図７のＳ２０４７において、ハードウェア１０１の障害が検知された時点でのゲストＯＳ１０４の状態を示す情報とともに、Ｉ／Ｏリクエストのコピーを同期データとしてサーバ装置２００に出力する。
　なお、本実施の形態に係るシステム構成も図１に示す通りである。
　このように、本実施の形態によれば、Ｉ／Ｏレスポンスのエラーメッセージ以外によるハードウェア故障検知によっても、運用系のゲストＯＳへハードウェア障害が伝播する直前の状態に待機系のゲストＯＳを同期させることができる。
　これにより、運用系のハードウェア障害の影響を受けることなく、待機系のゲストＯＳに運用系のゲストＯＳで行われてきた動作を正常に引き継がせることができ、処理を円滑に待機系へ切り替えることができる。
　また、本実施の形態によれば、Ｉ／Ｏリクエストのあった段階でのハードウェア故障検知が可能であり、実施の形態１に比べて早期にハードウェア故障を検知することができる。
　以上、本実施の形態では、
　仮想化環境では、ゲストＯＳ上のハードウェアのＩ／Ｏ処理が仮想マシンモニタやホストＯＳを経由して行われることを利用し、ホストＯＳ、または、仮想マシンモニタでゲストＯＳからのＩ／Ｏリクエストを一時的に保管しておき、
　ホストＯＳ、または、仮想マシンモニタでハードウェアのＩ／Ｏに関わる障害を検知し、そのハードウェアのＩ／Ｏに関わる障害情報が該当ゲストＯＳに通知される前に、ホストＯＳ、または、仮想マシンモニタでハードウェアのＩ／Ｏに関わる障害情報の通知を破棄し、
　該当ゲストＯＳがハードウェアの障害を検知する前の、該当ゲストＯＳがＩ／Ｏリクエストを出した状態の動作状態を待機系へ同期させ、その同期データを用いて待機系サーバ装置上で、故障が発生する直前のゲストＯＳの動作を再開させることで、該当ゲストＯＳが継続して動作が可能な仮想化環境同期システムを説明した。
　また、本実施の形態では、
　ホストＯＳ、または、仮想マシンモニタで検知するハードウェアの障害情報において、
　ホストＯＳ、または、仮想マシンモニタでハードウェアの稼動確認を定期的に実施し、それと同時にゲストＯＳの動作状態を待機系へ同期させ、
　ハードウェアが停止している等のハードウェア故障が検知された場合には、直前の同期データを用いて待機系サーバ装置上でゲストＯＳの動作を再開させることで、該当ゲストＯＳが継続して動作が可能な仮想化環境同期システムを説明した。
　実施の形態３．
　実施の形態１では、各サーバ装置に１つのゲストＯＳが配置されているシステムにおけるハードウェア故障発生から系切替までの流れを示したが、ソフトウェアＦＴによる同期対象となるゲストＯＳは複数であってもよい。
　つまり、本実施の形態では、運用系のサーバ装置に２以上のゲストＯＳが配置され、待機系のサーバ装置に運用系の各ゲストＯＳに対応するゲストＯＳが配置されているシステムを対象とする。
　そして、運用系のサーバ装置のハードウェアに障害が発生した場合に、運用系のサーバ装置の同期部が、ゲストＯＳごとに、同期データを待機系のサーバ装置に出力する。
　待機系のサーバ装置は、同期データに基づき、各ゲストＯＳを、運用系のハードウェアに障害が発生する直前の運用系のゲストＯＳの状態に同期させて、運用系のゲストＯＳの動作を引き継がせる。
　本実施の形態では、実施の形態１で示した保存部１１２をゲストＯＳごとに用意し、Ｉ／Ｏレスポンスにエラーメッセージが検出された場合に、同期部１０９がゲストＯＳごとの保存部１１２から各ゲストＯＳのＩ／Ｏリクエストを取得し、ゲストＯＳごとに同期データ及び指示データを出力する。
　また、実施の形態２に示したように、定期的な検査により障害検知部１１１がハードウェア１０１の障害を検知した場合、または、Ｉ／Ｏ制御部１１０にＩ／Ｏリクエストが到達した段階で障害検知部１１１が検査を実施してハードウェア１０１の障害を検知した場合にも、同期部１０９がゲストＯＳごとの保存部１１２から各ゲストＯＳのＩ／Ｏリクエストを取得し、ゲストＯＳごとに同期データ及び指示データを出力する。
　その他の動作は、実施の形態１及び実施の形態２に示した通りであり、説明を省略する。
　このように、本実施の形態によれば、複数のゲストＯＳを同期対象とした環境でも、運用系のゲストＯＳへハードウェア障害が伝播する直前の状態に待機系のゲストＯＳを同期させることができる。
　これにより、複数のゲストＯＳを同期対象とした環境でも、運用系のハードウェア障害の影響を受けることなく、待機系のゲストＯＳに運用系のゲストＯＳで行われてきた動作を正常に引き継がせることができ、処理を円滑に待機系へ切り替えることができる。
　最後に、実施の形態１～３に示したサーバ装置１００、２００のハードウェア構成例について説明する。
　図８は、実施の形態１～３に示すサーバ装置１００、２００のハードウェア資源の一例を示す図である。
　なお、図８の構成は、あくまでもサーバ装置１００、２００のハードウェア構成の一例を示すものであり、サーバ装置１００、２００のハードウェア構成は図８に記載の構成に限らず、他の構成であってもよい。
　図８において、サーバ装置１００、２００は、プログラムを実行するＣＰＵ９１１（Ｃｅｎｔｒａｌ　Ｐｒｏｃｅｓｓｉｎｇ　Ｕｎｉｔ、中央処理装置、処理装置、演算装置、マイクロプロセッサ、マイクロコンピュータ、プロセッサともいう）を備えている。
　ＣＰＵ９１１は、バス９１２を介して、例えば、ＲＯＭ（Ｒｅａｄ　Ｏｎｌｙ　Ｍｅｍｏｒｙ）９１３、ＲＡＭ（Ｒａｎｄｏｍ　Ａｃｃｅｓｓ　Ｍｅｍｏｒｙ）９１４、通信ボード９１５、表示装置９０１、キーボード９０２、マウス９０３、磁気ディスク装置９２０、スキャナ装置９０７と接続され、これらのハードウェアデバイスを制御する。
　更に、ＣＰＵ９１１は、ＦＤＤ９０４（Ｆｌｅｘｉｂｌｅ　Ｄｉｓｋ　Ｄｒｉｖｅ）、コンパクトディスク装置９０５（ＣＤＤ）、プリンタ装置９０６と接続していてもよい。また、磁気ディスク装置９２０の代わりに、光ディスク装置、メモリカード（登録商標）読み書き装置などの記憶装置でもよい。
　ＲＡＭ９１４は、揮発性メモリの一例である。ＲＯＭ９１３、ＦＤＤ９０４、ＣＤＤ９０５、磁気ディスク装置９２０の記憶媒体は、不揮発性メモリの一例である。これらは、記憶装置の一例である。
　通信ボード９１５、キーボード９０２、マウス９０３、ＦＤＤ９０４、スキャナ装置９０７などは、入力装置の一例である。
　また、通信ボード９１５、表示装置９０１、プリンタ装置９０６などは、出力装置の一例である。
　通信ボード９１５は、図１に示すように、ＬＡＮ３００に接続される。通信ボード９１５は、ＬＡＮ以外にも、例えば、インターネット、ＷＡＮ（ワイドエリアネットワーク）などに接続することが可能である。
　磁気ディスク装置９２０には、仮想マシンモニタ９２１、ホストＯＳ９２２、プログラム群９２３、ファイル群９２４が記憶されている。
　プログラム群９２３のプログラムは、ＣＰＵ９１１、仮想マシンモニタ９２１、ホストＯＳ９２２により実行される。
　また、仮想マシンモニタ９２１自身がホストＯＳ９２２の機能を含む場合や、ホストＯＳ９２２内に仮想マシンモニタ９２１が存在する場合もある。
　ＲＯＭ９１３には、ＢＩＯＳ（Ｂａｓｉｃ　Ｉｎｐｕｔ　Ｏｕｔｐｕｔ　Ｓｙｓｔｅｍ）プログラムが格納され、磁気ディスク装置９２０にはブートプログラムが格納されている。
　サーバ装置１００、２００の起動時には、ＲＯＭ９１３のＢＩＯＳプログラム及び磁気ディスク装置９２０のブートプログラムが実行され、ＢＩＯＳプログラム及びブートプログラムにより仮想マシンモニタ９２１、ホストＯＳ９２２が起動される。
　プログラム群９２３には、実施の形態１～３に示される同期部１０９、Ｉ／Ｏ制御部１１０及び障害検知部１１１を実現するプログラムが含まれる。
　更に、ファイル群９２４には、実施の形態１～３の説明において、「～の判断」、「～の検査」、「～の検出」、「～の同期」、「～のチェック」、「～の制御」、「～の設定」、「～の選択」等として説明している処理の結果を示す情報やデータや信号値や変数値やパラメータが、「～ファイル」や「～データベース」の各項目として記憶されている。
　「～ファイル」や「～データベース」は、ディスクやメモリなどの記録媒体に記憶される。ディスクやメモリなどの記憶媒体に記憶された情報やデータや信号値や変数値やパラメータは、読み書き回路を介してＣＰＵ９１１によりメインメモリやキャッシュメモリに読み出され、抽出・検索・参照・比較・演算・計算・処理・編集・出力・印刷・表示などのＣＰＵの動作に用いられる。
　抽出・検索・参照・比較・演算・計算・処理・編集・出力・印刷・表示のＣＰＵの動作の間、情報やデータや信号値や変数値やパラメータは、メインメモリ、レジスタ、キャッシュメモリ、バッファメモリ等に一時的に記憶される。
　また、実施の形態１～３で説明しているフローチャートの矢印の部分は主としてデータや信号の入出力を示し、データや信号値は、ＲＡＭ９１４のメモリ、ＦＤＤ９０４のフレキシブルディスク、ＣＤＤ９０５のコンパクトディスク、磁気ディスク装置９２０の磁気ディスク、その他光ディスク、ミニディスク、ＤＶＤ等の記録媒体に記録される。また、データや信号は、バス９１２や信号線やケーブルその他の伝送媒体によりオンライン伝送される。
　また、実施の形態１～３の説明において「～部」として説明しているものは「～ステップ」、「～手順」、「～処理」であってもよい。すなわち、「～部」として説明しているものは、ＲＯＭ９１３に記憶されたファームウェアで実現されていても構わない。
　或いは、ソフトウェアのみ、或いは、素子・デバイス・基板・配線などのハードウェアのみ、或いは、ソフトウェアとハードウェアとの組み合わせ、さらには、ファームウェアとの組み合わせで実施されても構わない。ファームウェアとソフトウェアは、プログラムとして、磁気ディスク、フレキシブルディスク、光ディスク、コンパクトディスク、ミニディスク、ＤＶＤ等の記録媒体に記憶される。プログラムはＣＰＵ９１１により読み出され、ＣＰＵ９１１により実行される。
　すなわち、プログラムは、実施の形態１～３の「～部」としてコンピュータを機能させるものである。
　あるいは、実施の形態１～３の「～部」の手順や方法をコンピュータに実行させるものである。
　また、実施の形態１～３で説明したサーバ装置１００、２００の動作を例えばデータ処理方法として把握することも可能である。
　このように、実施の形態１～３に示すサーバ装置１００、２００は、処理装置たるＣＰＵ、記憶装置たるメモリ、磁気ディスク等、入力装置たるキーボード、マウス、通信ボード等、出力装置たる表示装置、通信ボード等を備えるコンピュータであり、上記したように「～部」として示された機能をこれら処理装置、記憶装置、入力装置、出力装置を用いて実現するものである。
　１００　サーバ装置、１０１　ハードウェア、１０２　仮想マシンモニタ、１０３　ホストＯＳ、１０４　ゲストＯＳ、１０５　プロセス、１０６　フロントエンドドライバ、１０７　バックエンドドライバ、１０８　実デバイスドライバ、１０９　同期部、１１０　Ｉ／Ｏ制御部、１１１　障害検知部、１１２　保存部、２００　サーバ装置、２０１　ハードウェア、２０２　仮想マシンモニタ、２０３　ホストＯＳ、２０４　ゲストＯＳ、３００　ＬＡＮ、１０１１　ＣＰＵ、１０１２　メモリ、１０１３　ディスク、１０１４　ＮＩＣ。

Claims (8)

  1. 　ハードウェアと、前記ハードウェアを用いて実現される仮想マシン上で動作し、前記ハードウェアへのリクエストを発行する第１のゲストＯＳ（Ｏｐｅｒａｔｉｎｇ　Ｓｙｓｔｅｍ）とを有し、
    　前記第１のゲストＯＳと同じ動作を行う第２のゲストＯＳを有する外部装置に接続されている計算機装置であって、
    　前記第１のゲストＯＳにより発行されたリクエストのコピーを所定の記憶領域に格納するリクエスト管理部と、
    　前記リクエストに対する前記ハードウェアからのレスポンスが前記第１のゲストＯＳに届く前に前記ハードウェアに障害が発生しているか否かを判断し、前記ハードウェアに障害が発生している場合に前記レスポンスが前記第１のゲストＯＳに届かないように制御する障害検知部と、
    　前記障害検知部により前記ハードウェアの障害が検知された場合に、前記記憶領域に格納されている前記リクエストのコピーと前記ハードウェアの障害が検知された時点での前記第１のゲストＯＳの状態を示す情報を前記外部装置に出力し、前記第１のゲストＯＳが行っていた動作を前記第２のゲストＯＳにて引き継ぐよう指示する指示メッセージを前記外部装置に出力する引き継ぎ制御部とを有することを特徴とする計算機装置。
  2. 　前記計算機装置は、更に、
    　前記ハードウェアを用いて仮想マシンを実現するホストＯＳと仮想マシンモニタとを有し、
    　前記リクエスト管理部と、前記障害検知部と、前記引き継ぎ制御部は、それぞれ、
    　前記ホストＯＳ及び前記仮想マシンモニタの少なくともいずれかにおいて動作することを特徴とする請求項１に記載の計算機装置。
  3. 　前記障害検知部は、
    　前記リクエストに対する前記ハードウェアからのレスポンスが前記第１のゲストＯＳに届く前に前記レスポンスを入力し、入力した前記レスポンスを検査し、前記レスポンスにおいてエラーメッセージが存在する場合に、前記ハードウェアに障害が発生していると判断し、前記レスポンスが前記第１のゲストＯＳに届かないように制御することを特徴とする請求項１又は２に記載の計算機装置。
  4. 　前記計算機装置は、更に、
    　前記ハードウェアを用いて仮想マシンを実現するホストＯＳを有し、
    　前記ホストＯＳは、
    　前記第１のゲストＯＳに含まれるフロントエンドドライバから出力された前記ハードウェアへのリクエストを入力し、前記ハードウェアからのレスポンスを前記フロントエンドドライバに対して出力するバックエンドドライバを有し、
    　前記リクエスト管理部は、
    　前記フロントエンドドライバから前記リクエストを入力し、入力した前記リクエストのコピーを前記記憶領域に格納し、前記リクエストを前記バックエンドドライバに出力し、
    　前記障害検知部は、
    　前記バックエンドドライバから出力された前記レスポンスを入力し、入力した前記レスポンスを検査し、前記レスポンスにエラーメッセージが存在している場合に、前記レスポンスを破棄し、前記レスポンスにエラーメッセージが存在していない場合に、前記レスポンスを前記フロントエンドドライバに対して出力することを特徴とする請求項３に記載の計算機装置。
  5. 　前記障害検知部は、
    　前記リクエストに対する前記ハードウェアからのレスポンスが前記第１のゲストＯＳに届く前に前記ハードウェアを検査し、前記ハードウェアに障害が発生しているか否かを判断し、前記ハードウェアに障害が発生している場合に前記レスポンスが前記第１のゲストＯＳに届かないように制御することを特徴とする請求項１～４のいずれかに記載の計算機装置。
  6. 　前記障害検知部は、
    　一定周期にて、前記ハードウェアを検査し、前記ハードウェアに障害が発生しているか否かを判断し、
    　前記引き継ぎ制御部は、
    　前記障害検知部により前記ハードウェアの障害が検知された際に前記記憶領域に前記リクエストのコピーが格納されている場合は、前記記憶領域に格納されている前記リクエストのコピーと前記ハードウェアの障害が検知された時点での前記第１のゲストＯＳの状態を示す情報を前記外部装置に出力し、
    　前記障害検知部により前記ハードウェアの障害が検知された際に前記記憶領域に前記リクエストのコピーが格納されていない場合は、前記ハードウェアの障害が検知された時点での前記第１のゲストＯＳの状態を示す情報を前記外部装置に出力することを特徴とする請求項１～５のいずれかに記載の計算機装置。
  7. 　前記計算機装置は、
    　前記仮想マシン上で動作する複数の第１のゲストＯＳを有し、
    　前記複数の第１のゲストＯＳに対応させて複数の第２のゲストＯＳを有する外部装置に接続され、
    　前記リクエスト管理部は、
    　各々の第１のゲストＯＳにより発行されたリクエストのコピーを各々の第１のゲストＯＳに割り当てられている記憶領域に格納し、
    　前記引き継ぎ制御部は、
    　前記障害検知部により前記ハードウェアの障害が検知された場合に、第１のゲストＯＳごとに、記憶領域に格納されているリクエストのコピーと前記ハードウェアの障害が検知された時点での第１のゲストＯＳの状態を示す情報を前記外部装置に出力し、第１のゲストＯＳが行っていた動作を対応する第２のゲストＯＳにて引き継ぐよう指示する指示メッセージを前記外部装置に出力することを特徴とする請求項１～６のいずれかに記載の計算機装置。
  8. 　ハードウェアと、前記ハードウェアを用いて実現される仮想マシン上で動作し、前記ハードウェアへのリクエストを発行する第１のゲストＯＳ（Ｏｐｅｒａｔｉｎｇ　Ｓｙｓｔｅｍ）とを有し、
    　前記第１のゲストＯＳと同じ動作を行う第２のゲストＯＳを有する外部装置に接続されている計算機装置に、
    　前記第１のゲストＯＳにより発行されたリクエストのコピーを所定の記憶領域に格納させ、
    　前記リクエストに対する前記ハードウェアからのレスポンスが前記第１のゲストＯＳに届く前に前記ハードウェアに障害が発生しているか否かを判断させ、前記ハードウェアに障害が発生している場合に前記レスポンスが前記第１のゲストＯＳに届かないように制御させ、
    　前記ハードウェアの障害が検知された場合に、前記記憶領域に格納されている前記リクエストのコピーと前記ハードウェアの障害が検知された時点での前記第１のゲストＯＳの状態を示す情報を前記外部装置に対して出力させ、前記第１のゲストＯＳが行っていた動作を前記第２のゲストＯＳにて引き継ぐよう指示する指示メッセージを前記外部装置に対して出力させることを特徴とするプログラム。
PCT/JP2010/070812 2010-11-22 2010-11-22 計算機装置及びプログラム Ceased WO2012070102A1 (ja)

Priority Applications (2)

Application Number Priority Date Filing Date Title
PCT/JP2010/070812 WO2012070102A1 (ja) 2010-11-22 2010-11-22 計算機装置及びプログラム
JP2012545548A JP5335150B2 (ja) 2010-11-22 2010-11-22 計算機装置及びプログラム

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/JP2010/070812 WO2012070102A1 (ja) 2010-11-22 2010-11-22 計算機装置及びプログラム

Publications (1)

Publication Number Publication Date
WO2012070102A1 true WO2012070102A1 (ja) 2012-05-31

Family

ID=46145479

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2010/070812 Ceased WO2012070102A1 (ja) 2010-11-22 2010-11-22 計算機装置及びプログラム

Country Status (2)

Country Link
JP (1) JP5335150B2 (ja)
WO (1) WO2012070102A1 (ja)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP6242557B1 (ja) * 2017-03-21 2017-12-06 三菱電機株式会社 制御装置および制御プログラム
EP3608784A1 (en) * 2018-08-10 2020-02-12 Yokogawa Electric Corporation Control system and control apparatus

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2017045084A (ja) * 2015-08-24 2017-03-02 日本電信電話株式会社 障害検知装置及び障害検知方法

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2008107896A (ja) * 2006-10-23 2008-05-08 Nec Corp 物理資源制御管理システム、物理資源制御管理方法および物理資源制御管理用プログラム
JP2009245216A (ja) * 2008-03-31 2009-10-22 Toshiba Corp 情報処理装置および障害回復方法

Family Cites Families (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP4544146B2 (ja) * 2005-11-29 2010-09-15 株式会社日立製作所 障害回復方法
JP2009080692A (ja) * 2007-09-26 2009-04-16 Toshiba Corp 仮想計算機システム及び同システムにおけるサービス引き継ぎ制御方法

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2008107896A (ja) * 2006-10-23 2008-05-08 Nec Corp 物理資源制御管理システム、物理資源制御管理方法および物理資源制御管理用プログラム
JP2009245216A (ja) * 2008-03-31 2009-10-22 Toshiba Corp 情報処理装置および障害回復方法

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
YOSHIAKI TAMURA ET AL.: "Kemari: Virtual Machine Synchronization for Fault Tolerance", TRANSACTIONS OF INFORMATION PROCESSING SOCIETY OF JAPAN TRANSACTION, vol. 3, no. 1, 15 April 2010 (2010-04-15), pages 13 - 24 *

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP6242557B1 (ja) * 2017-03-21 2017-12-06 三菱電機株式会社 制御装置および制御プログラム
WO2018173123A1 (ja) * 2017-03-21 2018-09-27 三菱電機株式会社 制御装置および制御プログラム
EP3608784A1 (en) * 2018-08-10 2020-02-12 Yokogawa Electric Corporation Control system and control apparatus

Also Published As

Publication number Publication date
JPWO2012070102A1 (ja) 2014-05-19
JP5335150B2 (ja) 2013-11-06

Similar Documents

Publication Publication Date Title
JP5851503B2 (ja) 高可用性仮想機械環境におけるアプリケーションの高可用性の提供
US9262257B2 (en) Providing boot data in a cluster network environment
US8984330B2 (en) Fault-tolerant replication architecture
CN105683919B (zh) 用于安全关键软件应用的多核处理器故障检测
US10929234B2 (en) Application fault tolerance via battery-backed replication of volatile state
US10185636B2 (en) Method and apparatus to virtualize remote copy pair in three data center configuration
JP5392594B2 (ja) 仮想計算機冗長化システム、コンピュータシステム、仮想計算機冗長化方法、及びプログラム
JP2012221321A (ja) フォールトトレラント計算機システム、フォールトトレラント計算機システムの制御方法、及びフォールトトレラント計算機システムの制御プログラム
US11960366B2 (en) Live migrating virtual machines to a target host upon fatal memory errors
US20060259815A1 (en) Systems and methods for ensuring high availability
US7530000B2 (en) Early detection of storage device degradation
TWI592796B (zh) 運用於雲端服務之虛擬機之封包察覺式容錯方法及系統、電腦可讀取之記錄媒體及電腦程式產品
WO2015033433A1 (ja) ストレージ装置及び障害部位特定方法
US20250225023A1 (en) Server maintainability configuration method and apparatus, electronic device and storage medium
CN105579973A (zh) 冗余系统以及冗余系统管理方法
US9063854B1 (en) Systems and methods for cluster raid data consistency
US9798615B2 (en) System and method for providing a RAID plus copy model for a storage network
JP5335150B2 (ja) 計算機装置及びプログラム
JP5440073B2 (ja) 情報処理装置，情報処理装置の制御方法および制御プログラム
JP2011100300A (ja) 計算機装置及び情報処理方法及びプログラム
JP5880608B2 (ja) フォールトトレラントサーバ
KR101564144B1 (ko) 펌웨어 관리 장치 및 방법
JP5832408B2 (ja) 仮想計算機システム及びその制御方法
US12386712B2 (en) Storage system
JP2017151511A (ja) 情報処理装置、動作ログ取得方法および動作ログ取得プログラム

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 10860094

Country of ref document: EP

Kind code of ref document: A1

WWE Wipo information: entry into national phase

Ref document number: 2012545548

Country of ref document: JP

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 10860094

Country of ref document: EP

Kind code of ref document: A1