WO2024121952A1 - Failure restoration expediting system, failure restoration expediting method, and failure restoration expediting program - Google Patents

Failure restoration expediting system, failure restoration expediting method, and failure restoration expediting program Download PDF

Info

Publication number
WO2024121952A1
WO2024121952A1 PCT/JP2022/044983 JP2022044983W WO2024121952A1 WO 2024121952 A1 WO2024121952 A1 WO 2024121952A1 JP 2022044983 W JP2022044983 W JP 2022044983W WO 2024121952 A1 WO2024121952 A1 WO 2024121952A1
Authority
WO
WIPO (PCT)
Prior art keywords
unit
node
host
cluster
stonith
Prior art date
Application number
PCT/JP2022/044983
Other languages
French (fr)
Japanese (ja)
Inventor
雅人 西口
俊之 金澤
寛規 井上
達也 出水
Original Assignee
日本電信電話株式会社
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 日本電信電話株式会社 filed Critical 日本電信電話株式会社
Priority to PCT/JP2022/044983 priority Critical patent/WO2024121952A1/en
Publication of WO2024121952A1 publication Critical patent/WO2024121952A1/en

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00Error detection; Error correction; Monitoring
    • G06F11/07Responding to the occurrence of a fault, e.g. fault tolerance

Definitions

  • This disclosure relates to a system for accelerating failure recovery, a method for accelerating failure recovery, and a program for accelerating failure recovery.
  • Cluster systems provide availability to services.
  • a cluster is multiple computers working together to perform a task. These computers are called nodes.
  • Cluster systems provide a variety of high availability services. These high availability services include service failover: if the node providing a service fails, another node takes over the service.
  • the present disclosure provides a system, method, and program for accelerating failure recovery that can shorten the recovery time of a cluster in which a node has failed.
  • the fast failure recovery system includes a first instruction unit that instructs a server that controls a cluster to execute a power operation on a backup node, an acquisition unit that acquires the power state of the backup node in response to receiving a notification of the completion of the power operation, a determination unit that determines whether the power state of the backup node is powered on or off, and a second instruction unit that instructs the server to power on the backup node in response to determining that the power state of the backup node is powered off.
  • the high-speed failure recovery system can shorten the recovery time of a cluster in which a node has failed.
  • FIG. 1 shows an example of a cluster system in a virtual environment.
  • FIG. 2 shows an example of a countermeasure against split-brain.
  • FIG. 3 shows an example of the expected behavior when the fencing action is a reboot.
  • FIG. 4 shows an example of the problem case when the fencing action is a restart.
  • FIG. 5 shows an example of the expected behavior when the fencing action is stop.
  • FIG. 6 shows an example of the problem case when the fencing action is stalled.
  • FIG. 7 is a block diagram of an example environment for cluster recovery.
  • FIG. 8 shows an overview of one cluster recovery process according to the present disclosure.
  • FIG. 9 is a block diagram of an example of a host configuration according to the present disclosure.
  • FIG. 10 is a sequence diagram showing an example of a process for recovering a cluster in which a node has failed.
  • FIG. 11 shows an example of the hardware configuration of a computer.
  • the technology proposed in this specification relates to cluster recovery.
  • this technology relates to shortening the recovery time of a cluster system in STONITH (Shoot The Other Node In The Head).
  • STONITH Shoot The Other Node In The Head
  • a host sometimes fails.
  • This technology realizes STONITH with a short recovery time.
  • FIG. 1 shows a cluster system 10, which is an example of a cluster system in a virtual environment.
  • Cluster system 10 includes host 11a, host 11b, and a virtualization infrastructure control server 12.
  • Host 11a includes guest #1.
  • Host 11b includes guest #2.
  • Clustering software clusters the guests (13).
  • An example of clustering software is Pacemaker (registered trademark).
  • Virtualization infrastructure software clusters the hosts (14a, 14b).
  • An example of virtualization infrastructure software is vSphere.
  • vSphere on the host side is vSphere ESXi.
  • vSphere on the control server side is vSphere vCenter.
  • the clustering software responds to failures of processes and services running within the guest. If monitored resources fail, the clustering software performs system switching.
  • the virtualization infrastructure software responds to failures on the host side (e.g., hardware (H/W) failures). For example, if a failure occurs on a monitored host, the virtualization infrastructure software restarts the VM (Virtual Machine) on another host.
  • H/W hardware
  • FIG. 2 shows split-brain countermeasure 20, which is an example of a split-brain countermeasure.
  • Split-brain is a fatal problem that can occur in a cluster system.
  • split brain occurs in the following situations: network disconnection between systems (21), host failure (e.g. hardware failure), and failure to stop resources.
  • STONITH is an effective measure against split-brain.
  • STONITH is a fencing function that forcibly terminates a node whose status is unknown, and then causes the node to leave the cluster. If STONITH is successful, the standby system will perform system switchover.
  • STONITH performs power operations on the opposing node via the virtualization infrastructure control server 12.
  • the host 11a issues a power-off instruction to the virtualization infrastructure control server 12 (22a).
  • the virtualization infrastructure control server 12 then cuts off the power (22b).
  • STONITH As a result of STONITH, the standby node is fenced, thereby preventing a split-brain from occurring. To prevent double fencing, STONITH on the standby node is usually configured to delay the execution of STONITH.
  • the problem lies in failure cases (e.g. hardware failure) where STONITH is activated and the host-side clustering function is activated.
  • FIG. 3 shows expected action 30, which is an example of expected action when the fencing action is a reboot.
  • Expected action 30 includes six stages.
  • the virtualization platform control server restarts the VM on another host in a standby system.
  • the VM is restarted independently of the #1 system.
  • the virtualization platform control server detects a network outage using ping. When a network outage is detected, the virtualization platform control server restarts the VM in the standby system.
  • the #1 host performs a STONITH on the new VM, which is then rebooted.
  • Figure 4 shows problem case 40, which is an example of a problem case when the fencing action is a reboot.
  • Problem case 40 shows the actual action that occurred.
  • Problem case 40 includes seven stages.
  • the virtualization infrastructure control server restarts the VM on another host as a backup system.
  • the #1 host performs a STONITH on the new VM, which is then rebooted.
  • FIG. 5 shows expected behavior 50, which is an example of expected behavior when fencing operation is stopped. Expected behavior 50 includes six stages.
  • the virtualization infrastructure control server restarts the VM on another host as a backup system.
  • FIG. 6 shows problem case 60, which is an example of a problem case when fencing action is stopped. Problem case 60 shows the actual action that occurred. Problem case 60 includes seven stages.
  • the virtualization infrastructure control server restarts the VM on another host as a backup system.
  • the #1 host performs a STONITH to the new VM.
  • the new VM is stopped.
  • the problem exists not only in the case where the fencing action is a restart, but also in the case where the fencing action is a stop.
  • the host according to the present disclosure performs one or more cluster recovery processes described below.
  • FIG. 7 is a block diagram of environment 1, which is an example of an environment for cluster recovery. As shown in FIG. 7, environment 1 includes host 100, network 200, and control server 300. Host 100 is an example of a high-speed failure recovery system.
  • Host 100 is a system that performs processing to recover a cluster in which a node has failed.
  • processing is called cluster recovery processing.
  • An overview of cluster recovery processing is explained in Section 3.
  • the details of cluster recovery processing are explained in Section 5 using a sequence diagram.
  • Host 100 includes one or more computers, such as one or more servers.
  • An example configuration of host 100 is described in Section 4.
  • the network 200 is a network such as a LAN (Local Area Network), a WAN (Wide Area Network), or the Internet.
  • the network 200 connects the host 100 and the control server 300.
  • the control server 300 is a server that controls the cluster.
  • the control server 300 is, for example, a virtualization infrastructure control server.
  • FIG. 8 shows overview 70, which is an overview of one cluster recovery process according to the present disclosure.
  • Overview 70 compares the present technology with existing techniques (fencing: "restart” or “stop”).
  • the existing technology includes problem cases. For “reboot”, if the reboot is not completed, STONITH fails. For “stop”, the VM state is different depending on the timing of the host-side clustering function.
  • the technology proposed in this specification is based on the premise that the fencing operation is "stop."
  • host 100a node #1
  • hosts off host 100b node #0
  • host 100a checks the power status of host 100b. If the power status is powered off, host 100a powers on host 100b via control server 300.
  • This power operation solves the problem (fifth, sixth, and seventh stages) described above with reference to FIG. 6. As a result, this technology can shorten the recovery time of a cluster system in STONITH.
  • FIG. 9 is a block diagram of an example of the configuration of a host 100 according to the present disclosure.
  • the host 100 includes a communication unit 110, a control unit 120, and a memory unit 130.
  • the host 100 may include an input unit (e.g., a keyboard, a mouse) that accepts input from an administrator of the host 100.
  • the host 100 may also include an output unit (e.g., a liquid crystal display, an organic EL (Electro Luminescence) display) that displays information to the administrator.
  • an input unit e.g., a keyboard, a mouse
  • an output unit e.g., a liquid crystal display, an organic EL (Electro Luminescence) display
  • the communication unit 110 is implemented by a network device such as a network interface card (NIC).
  • NIC network interface card
  • the communication unit 110 is connected to the network 200 by wire or wirelessly.
  • the communication unit 110 can transmit and receive data to and from the control server 300 via the network 200.
  • the control unit 120 is implemented by a data processing device and various programs stored in a storage device.
  • the data processing device is, for example, a processor such as a central processing unit (CPU), a micro processing unit (MPU), or a general purpose graphic processing unit (GPGPU).
  • the control unit 120 can be implemented as a controller for controlling multiple operations of the host 100. For example, when one or more processors execute a program (multiple instructions) by using a random access memory (RAM) as a working area, the one or more processors perform multiple operations.
  • RAM random access memory
  • the control unit 120 can receive input data for the cluster recovery process from an external device.
  • the control unit 120 can store data such as the input data, data used in the cluster recovery process, and output data of the cluster recovery process in the storage unit 130.
  • the control unit 120 can obtain such data from the storage unit 130 as necessary.
  • the storage unit 130 is implemented by a RAM, a semiconductor memory such as a flash memory, a magnetic disk such as a hard disk, or an optical disk.
  • the storage unit 130 can store various programs and various data.
  • the control unit 120 includes a fencing unit 121, an identification unit 122, a request unit 123, a confirmation unit 124, a notification unit 125, and a recovery unit 126.
  • the fencing unit 121 is an example of a first instruction unit.
  • the identification unit 122 is an example of an acquisition unit.
  • the request unit 123 is an example of a determination unit and a second instruction unit.
  • the recovery unit 126 is an example of an integration unit. The data processing performed by each unit is described below.
  • the fencing unit 121 performs fencing operations.
  • the fencing unit 121 can perform STONITH on the remote node.
  • the identifying unit 122 identifies the state of the remote node.
  • the state of the remote node is a power state.
  • the request unit 123 requests the control server 300 to power on the remote node.
  • the confirmation unit 124 confirms the normality of the remote node.
  • the notification unit 125 transmits the notification to the maintenance person.
  • the recovery unit 126 recovers the cluster.
  • the example of cluster recovery processing includes processing for recovering a cluster in which a node has failed.
  • the processing for recovering a cluster in which a node has failed is performed, for example, by the host 100 in FIG. 7.
  • FIG. 10 is a sequence diagram showing process P100, which is an example of a process for recovering a cluster in which a node has failed.
  • Process P100 is performed by the STONITH device and a new module of the host 100a.
  • the STONITH device corresponds to the fencing unit 121.
  • the new module corresponds to the identification unit 122, the request unit 123, the confirmation unit 124, the notification unit 125, and the recovery unit 126.
  • Process P100 is based on the assumption that the fencing operation is "stopped.”
  • Host 100a corresponds to, for example, the #1 system in Figures 3, 4, 5, and 6.
  • host 100b corresponds to the standby system in Figures 3, 4, 5, and 6.
  • Control server 300 corresponds to the virtualization infrastructure control server in Figures 3, 4, 5, and 6.
  • Host 100a e.g., fencing unit 121 performs STONITH on host 100b via control server 300 (step S101).
  • the new module receives notification of STONITH completion from the STONITH device (step S102).
  • a "trap" command may be used for the notification.
  • the new module begins operation upon receiving the notification.
  • the host 100a (e.g., the identification unit 122) sends an instruction to the control server 300 to check the status of the VM (step S103).
  • the control server 300 sends a request for the VM status to the host 100b (step S104).
  • the host 100b sends the status of the VM to the control server 300 (step S105).
  • the control server 300 returns the status of the VM to the host 100a (step S106).
  • the host 100a then checks the status of the opposing node (VM).
  • the host 100a e.g., the request unit 123 issues an instruction to the control server 300 to power on the opposing node (step S107).
  • the control server 300 powers on the opposing node by sending a power-on request to the opposing node (step S108).
  • the control server 300 sends a request for the VM status to the host 100b (step S109).
  • Host 100b sends the VM status to control server 300 (step S110).
  • the control server 300 returns the VM state to the host 100a (step S111).
  • host 100a performs the following steps to further shorten recovery time.
  • the following steps are to check the normality of services and processes on the remote node. Specifically, host 100a checks whether there are any events that require maintenance personnel to respond.
  • the host 100a (e.g., the confirmation unit 124) sends an instruction to the control server 300 to confirm the normality (step S112).
  • the host 100a then checks the normality of the services and processes.
  • the host 100a (e.g., the notification unit 125) notifies the maintenance person. For example, the host 100a sends a notification regarding the maintenance request to the maintenance person (step S113). In this case, the host 100a does not recover the cluster.
  • host 100a e.g., recovery unit 1266 incorporates the opposing node into the cluster and then recovers the cluster (step S114).
  • process P100 is based on the assumption that the opposing node is configured not to be automatically incorporated into the cluster when the VM starts up.
  • the state of the VMs on the opposing node will be powered on.
  • the resulting power state of the opposing node will be the same as the node that performed STONITH.
  • the host 100 will automatically recover the cluster and then the equipment. This can reduce operational burden and shorten recovery time (the time from STONITH completion to resumption of service).
  • Hardware Configuration 11 is a diagram showing an example of a hardware configuration of a computer 1000. The systems and methods described in this specification are implemented by the computer 1000, for example.
  • Computer 1000 is an example of a computer that implements host 100 by executing a program.
  • Computer 1000 has memory 1010 and CPU 1020.
  • Computer 1000 also has hard disk drive interface 1030, disk drive interface 1040, serial port interface 1050, video adapter 1060, and network interface 1070. These components are connected by bus 1080.
  • the memory 1010 includes a ROM (Read Only Memory) 1011 and a RAM 1012.
  • the ROM 1011 stores a boot program such as a BIOS (Basic Input Output System).
  • BIOS Basic Input Output System
  • the hard disk drive interface 1030 is connected to a hard disk drive 1090.
  • the disk drive interface 1040 is connected to a disk drive 1100.
  • a removable storage medium e.g., a magnetic disk or an optical disk
  • the serial port interface 1050 is connected to, for example, a mouse 1110 and a keyboard 1120.
  • the video adapter 1060 is connected to, for example, a display 1130.
  • the hard disk drive 1090 stores an OS 1091, an application program 1092, a program module 1093, and program data 1094.
  • the program executed by the computer 1000 defines multiple operations of the host 100.
  • This program may be implemented as a program module 1093 written in code executable by the computer 1000.
  • the program module 1093 is stored, for example, in the hard disk drive 1090.
  • the hard disk drive 1090 stores a program module 1093 for executing processing similar to the functions of the components of the host 100.
  • the hard disk drive 1090 may be replaced with an SSD (Solid State Drive).
  • Hard disk drive 1090 can store a failure recovery acceleration program for cluster recovery processing.
  • Hard disk drive 1090 may store a computer program product including a failure recovery acceleration program (a plurality of instructions). When executed, the failure recovery acceleration program performs one or more methods, such as those described above.
  • the setting data used in the various processes described above can be implemented as program data 1094.
  • the setting data is stored, for example, in the memory 1010 or the hard disk drive 1090.
  • the CPU 1020 loads the program module 1093 or the program data 1094 stored in the memory 1010 or the hard disk drive 1090 into the RAM 1012 as necessary.
  • the CPU 1020 then performs the various processes described above.
  • the program module 1093 and program data 1094 may be stored in a removable storage medium instead of the hard disk drive 1090.
  • the CPU 1020 may load the program module 1093 and program data 1094 via the disk drive 1100 or the like.
  • the program module 1093 and program data 1094 may be stored in another computer connected to the computer 1000 via a network (LAN, WAN, etc.). In this case, the CPU 1020 may load the program module 1093 and program data 1094 via the network interface 1070.
  • host 100 includes fencing unit 121, identifying unit 122, and request unit 123.
  • fencing unit 121 instructs a server controlling the cluster to execute a power operation on the standby node.
  • identifying unit 122 acquires the power state of the standby node in response to receiving a notification of the completion of the power operation.
  • request unit 123 determines whether the power state of the standby node is powered on or powered off. In response to determining that the power state of the standby node is powered off, request unit 123 instructs the server to power on the standby node.
  • the power operation is STONITH.
  • the fencing action of STONITH is to stop.
  • the host 100 includes a verification unit 124.
  • the verification unit 124 verifies the health of the services or processes of the backup node.
  • the host 100 includes a recovery unit 126.
  • the recovery unit 126 incorporates a backup node into the cluster when the service or process is normal.
  • the host 100 includes a notification unit 125.
  • the notification unit 125 notifies the maintenance personnel of a maintenance request for the backup node when a service or process is not normal.
  • the components of the system are shown in the drawings.
  • the illustrated components conceptually represent the functionality of the system.
  • the components are not necessarily physically configured as shown in the drawings.
  • the components may be integrated or distributed, and the specific form of the system is not limited to that shown in the drawings. All or part of the system may be functionally or physically integrated or distributed depending on various loads and usage conditions.
  • module, section, -er suffix or -or suffix may be read as unit, means, circuit, etc.
  • a communication module, a control module, and a storage module may be read as a communication unit, a control unit, and a storage unit, respectively.
  • the configuration of the control unit 120 shown in Fig. 9 is exemplary, and the data processing described with respect to a particular unit does not necessarily have to be performed by that particular unit.
  • the identification unit 122 may perform the data processing described with respect to the request unit 123.
  • the control unit 120 may include other units not shown in Fig. 9. The other units may perform the data processing described with respect to the control unit 120.
  • the data processing device described with respect to the control unit 120 is not limited to the specific hardware described above.
  • the data processing device may be, for example, various computers or integrated circuits such as an ASIC (Application Specific Integrated Circuit), an FPGA (Field Programmable Gate Array), or a GPGPU (General Purpose Graphic Processing Unit).
  • ASIC Application Specific Integrated Circuit
  • FPGA Field Programmable Gate Array
  • GPGPU General Purpose Graphic Processing Unit

Landscapes

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

Abstract

In the present invention, a host instructs a server that controls clusters to execute a power supply operation on a reserve node. The host acquires the power supply state of the reserve node in response to receiving a notification that the power supply operation has been completed. The host assesses whether the power supply state of the reserve node is powered on or powered off. In response to the assessment that the power supply state of the reserve node is powered off, the host instructs the server to turn on the power supply to the reserve node.

Description

故障復旧高速化システム、故障復旧高速化方法及び故障復旧高速化プログラムFaster failure recovery system, faster failure recovery method, and faster failure recovery program
 本開示は、故障復旧高速化システム、故障復旧高速化方法及び故障復旧高速化プログラムに関する。 This disclosure relates to a system for accelerating failure recovery, a method for accelerating failure recovery, and a program for accelerating failure recovery.
 クラスタシステムは、可用性(availability)を、サービスにもたらす。クラスタは、タスクを行うために共同する複数のコンピュータである。これらのコンピュータは、ノード(nodes)と呼ばれる。 Cluster systems provide availability to services. A cluster is multiple computers working together to perform a task. These computers are called nodes.
 クラスタシステムは、様々な高可用性サービス(high availability service)を提供する。これらの高可用性サービスは、サービスのフェイルオーバ(failover)を含む。もし、サービスを提供しているノードが故障すれば、別のノードが、サービスを引き継ぐ。 Cluster systems provide a variety of high availability services. These high availability services include service failover: if the node providing a service fails, another node takes over the service.
 しかしながら、上記の先行技術は、ノードが故障したクラスタを復旧するのに長い時間がかかる場合がある。 However, the above prior art techniques can take a long time to restore a cluster where a node has failed.
 そこで、本開示は、ノードが故障したクラスタの復旧時間を短縮化することができる故障復旧高速化システム、故障復旧高速化方法及び故障復旧高速化プログラムを提供する。 The present disclosure provides a system, method, and program for accelerating failure recovery that can shorten the recovery time of a cluster in which a node has failed.
 本開示の一態様では、故障復旧高速化システムは、クラスタを制御するサーバに、予備系のノードに対する電源操作を実行するよう指示する第1指示部と、前記電源操作の完了の通知を受信することに応じて、前記予備系のノードの電源状態を取得する取得部と、前記予備系のノードの電源状態が電源オンまたは電源オフであるか、を判定する判定部と、前記予備系のノードの電源状態が電源オフである、と判定することに応じて、前記サーバに、前記予備系のノードの電源をオンにするよう指示する第2指示部とを備える。 In one aspect of the present disclosure, the fast failure recovery system includes a first instruction unit that instructs a server that controls a cluster to execute a power operation on a backup node, an acquisition unit that acquires the power state of the backup node in response to receiving a notification of the completion of the power operation, a determination unit that determines whether the power state of the backup node is powered on or off, and a second instruction unit that instructs the server to power on the backup node in response to determining that the power state of the backup node is powered off.
 故障復旧高速化システムは、ノードが故障したクラスタの復旧時間を短縮化することができる。 The high-speed failure recovery system can shorten the recovery time of a cluster in which a node has failed.
図1は、仮想環境でのクラスタシステムの例を示す。FIG. 1 shows an example of a cluster system in a virtual environment. 図2は、スプリットブレイン対策の例を示す。FIG. 2 shows an example of a countermeasure against split-brain. 図3は、フェンシングの動作が再起動である時の期待動作の例を示す。FIG. 3 shows an example of the expected behavior when the fencing action is a reboot. 図4は、フェンシングの動作が再起動である時の問題事例の例を示す。FIG. 4 shows an example of the problem case when the fencing action is a restart. 図5は、フェンシングの動作が停止である時の期待動作の例を示す。FIG. 5 shows an example of the expected behavior when the fencing action is stop. 図6は、フェンシングの動作が停止である時の問題事例の例を示す。FIG. 6 shows an example of the problem case when the fencing action is stalled. 図7は、クラスタ復旧のための環境の例のブロック図である。FIG. 7 is a block diagram of an example environment for cluster recovery. 図8は、本開示に係る1つのクラスタ復旧処理の概要を示す。FIG. 8 shows an overview of one cluster recovery process according to the present disclosure. 図9は、本開示に係るホストの構成の例のブロック図である。FIG. 9 is a block diagram of an example of a host configuration according to the present disclosure. 図10は、ノードが故障したクラスタを復旧するための処理の例を示すシーケンス図である。FIG. 10 is a sequence diagram showing an example of a process for recovering a cluster in which a node has failed. 図11は、コンピュータのハードウェア構成の例を示す。FIG. 11 shows an example of the hardware configuration of a computer.
 本開示の複数の実施形態が、添付の図面と、以下の説明に記載されている。なお、本発明は、これらの実施形態に限定されるものではない。これらの実施形態の様々な特徴は、これらの特徴が互いに矛盾しないという条件で、様々なやり方で組み合わされ得る。同種の符号は、同種の要素を示す。 Several embodiments of the present disclosure are described in the accompanying drawings and in the following description. However, the present invention is not limited to these embodiments. The various features of these embodiments may be combined in various ways, provided that the features are not mutually inconsistent. Like reference numerals refer to like elements.
〔目次〕
 以下の説明は、9個の節で構成されている:
 概要
 1.はじめに
 2.クラスタ復旧のための環境
 3.クラスタ復旧処理の概要
 4.ホストの構成
 5.クラスタ復旧処理のシーケンス図
 6.効果
 7.ハードウェア構成
 8.実施形態のまとめ
 9.補遺
〔table of contents〕
The following explanation is divided into nine sections:
Overview 1. Introduction 2. Environment for cluster recovery 3. Overview of cluster recovery process 4. Host configuration 5. Sequence diagram of cluster recovery process 6. Effects 7. Hardware configuration 8. Summary of embodiment 9. Addendum
〔1.はじめに〕
 本明細書で提案される技術は、クラスタ復旧に関連する。特に、本技術は、STONITH(Shoot The Other Node In The Head)におけるクラスタシステムの復旧時間の短縮化に関連する。仮想環境でのクラスタシステムでは、ホストが、時として、故障する。本技術は、復旧時間の短いSTONITHを実現する。
1. Introduction
The technology proposed in this specification relates to cluster recovery. In particular, this technology relates to shortening the recovery time of a cluster system in STONITH (Shoot The Other Node In The Head). In a cluster system in a virtual environment, a host sometimes fails. This technology realizes STONITH with a short recovery time.
 図1は、仮想環境でのクラスタシステムの例であるクラスタシステム10を示す。クラスタシステム10は、ホスト11a、ホスト11bおよび仮想化基盤制御サーバ12を含む。ホスト11aは、ゲスト#1を含む。ホスト11bは、ゲスト#2を含む。 FIG. 1 shows a cluster system 10, which is an example of a cluster system in a virtual environment. Cluster system 10 includes host 11a, host 11b, and a virtualization infrastructure control server 12. Host 11a includes guest #1. Host 11b includes guest #2.
 クラスタ構成が作成される場合に、可用性を高める目的で、クラスタリングがゲストとホストの両方で行われるケースがある。クラスタリングソフトウェアは、ゲストのクラスタ化を行う(13)。クラスタリングソフトウェアの一例は、Pacemaker(登録商標)である。仮想化基盤ソフトウェアは、ホストのクラスタ化を行う(14a、14b)。仮想化基盤ソフトウェアの一例は、vSphereである。ホスト側のvSphereは、vSphere ESXiである。制御サーバ側のvSphereは、vSphere vCenterである。 When a cluster configuration is created, there are cases where clustering is performed on both the guest and the host to increase availability. Clustering software clusters the guests (13). An example of clustering software is Pacemaker (registered trademark). Virtualization infrastructure software clusters the hosts (14a, 14b). An example of virtualization infrastructure software is vSphere. vSphere on the host side is vSphere ESXi. vSphere on the control server side is vSphere vCenter.
 クラスタリングソフトウェアは、ゲスト内で動作するプロセスやサービスの故障に対応する。監視対象のリソース(monitored resources)が故障した場合に、クラスタリングソフトウェアは、系切り替え(system switching)を行う。 The clustering software responds to failures of processes and services running within the guest. If monitored resources fail, the clustering software performs system switching.
 仮想化基盤ソフトウェアは、ホスト側での故障(例えば、ハードウェア(H/W)障害)に対応する。例えば、障害が監視対象のホストで発生した場合に、仮想化基盤ソフトウェアは、VM(Virtual Machine)を、別のホストで再開する。 The virtualization infrastructure software responds to failures on the host side (e.g., hardware (H/W) failures). For example, if a failure occurs on a monitored host, the virtualization infrastructure software restarts the VM (Virtual Machine) on another host.
 図2は、スプリットブレイン対策の例であるスプリットブレイン対策20を示す。スプリットブレインは、クラスタシステムで発生する致命的な問題である。 Figure 2 shows split-brain countermeasure 20, which is an example of a split-brain countermeasure. Split-brain is a fatal problem that can occur in a cluster system.
 まず、ノード間での疎通が、何らかの原因で、途絶える。その結果、対向ノード(correspondent node)の状態が、不明になる。その後、SBY系(Standby System)のノードが、ACT系(Standby System)に切り替わる。したがって、クラスタシステムは、複数のACT系が存在する状態になってしまう。この状態は、スプリットブレインと呼ばれる。スプリットブレインは、次のような状況で発生する:系間NW断(Network disconnection)(21)、ホストの故障(例えば、ハードウェア(H/W)障害)、リソース停止の失敗。 First, communication between nodes is cut off for some reason. As a result, the state of the corresponding node becomes unknown. After that, the standby system node switches to the active system. Therefore, the cluster system ends up in a state where there are multiple active systems. This state is called split brain. Split brain occurs in the following situations: network disconnection between systems (21), host failure (e.g. hardware failure), and failure to stop resources.
 サービスが正しく機能しないと、複数のノードからのデータ書き込みが、データ破損やデータ不整合につながる場合がある。 If the service does not function correctly, data writing from multiple nodes may lead to data corruption or data inconsistencies.
 STONITHは、スプリットブレイン対策の1つとして、有効である。STONITHは、その状態が不明となった対向ノードを、強制的に終了させ、それから、その対向ノードを、クラスタから離脱させるフェンシング機能である。SBY系は、STONITHの成功によって、系切り替えを行う。 STONITH is an effective measure against split-brain. STONITH is a fencing function that forcibly terminates a node whose status is unknown, and then causes the node to leave the cluster. If STONITH is successful, the standby system will perform system switchover.
 仮想環境でのSTONITHは、対向ノードの電源操作を、仮想化基盤制御サーバ12を介して行う。ホスト11aが、電源断(power-off)についての指示を、仮想化基盤制御サーバ12に与える(22a)。仮想化基盤制御サーバ12は、電源断を行う(22b)。 In a virtual environment, STONITH performs power operations on the opposing node via the virtualization infrastructure control server 12. The host 11a issues a power-off instruction to the virtualization infrastructure control server 12 (22a). The virtualization infrastructure control server 12 then cuts off the power (22b).
 STONITHの結果として、SBY側ノードがフェンシングされ、その結果、スプリットブレインの発生が阻止される。フェンシングの相打ち(double fencing)を防ぐたために、SBY側ノードにおけるSTONITHは、通常、STONITHの実行が遅延されるように、設定される。 As a result of STONITH, the standby node is fenced, thereby preventing a split-brain from occurring. To prevent double fencing, STONITH on the standby node is usually configured to delay the execution of STONITH.
 クラスタリングをゲストとホストの両方で行うシステムでは、課題が、STONITHが作動し、かつ、ホスト側のクラスタリング機能が作動する故障ケース(例えば、H/W障害)にある。 In a system where clustering is performed on both the guest and the host, the problem lies in failure cases (e.g. hardware failure) where STONITH is activated and the host-side clustering function is activated.
 STONITHを使ったフェンシングの動作は、「再起動」と「停止」を含む。 Fencing actions using STONITH include "restart" and "stop."
 フェンシングの動作が「再起動」であれば、STONITHの成功は、対向ノードの再起動の完了に基づいて、判定される。したがって、もし、再起動が、何らかの原因で完了しないと、STONITHが失敗し、その結果、系切り替えが発生しない。ACT側のホストの故障のようなケースでは、両系は、もし系切り替えが発生しないと、ダウン状態に陥る。 If the fencing action is "reboot", the success of STONITH is determined based on the completion of the reboot of the opposing node. Therefore, if the reboot does not complete for some reason, STONITH will fail, and as a result, system switchover will not occur. In cases such as a failure of the host on the ACT side, both systems will go down if system switchover does not occur.
 フェンシングの動作が「停止」であれば、差分が、STONITH完了後の対向ノードの状態に、ホスト側のクラスタリング機能による対向ノードに対する電源操作のタイミング次第では、発生する。  If the fencing operation is "stopped," the difference will occur in the state of the opposing node after STONITH is completed, depending on the timing of the power operation on the opposing node by the host's clustering function.
 STONITHの確実性と復旧時間(STONITH完了からサービスの再開までの時間)は、まとめると以下のようになる。 The reliability of STONITH and recovery time (the time from completion of STONITH to resumption of service) can be summarized as follows:
(STONITHの確実性:フェンシングの動作-再起動)
 VMを立ち上げるのに、時間がかかる。あるいは、VMの立ち上げが、成功しない。このようなケースでは、STONITHが失敗し、その結果、系切り替えが発生しない。このことは、運営に大きく影響する。
(STONITH Certainty: Fencing in Action - Restart)
It takes a long time to start up a VM. Or, the VM does not start up successfully. In such a case, STONITH fails, and as a result, system switchover does not occur. This has a significant impact on operations.
(復旧時間:フェンシングの動作-再起動)
 STONITH完了後、対向ノード上のVMの状態は、電源オンである。電源状態は、ノードと、その対向ノードで共通である。このケースは、復旧にかかる時間が短くてすむ。
(Recovery time: fencing action - restart)
After STONITH is completed, the state of the VM on the opposing node is powered on. The power state is common between the node and its opposing node. In this case, the time required for recovery is short.
(STONITHの確実性:フェンシングの動作-停止)
 もし、対向ノード上のVMが電源オフ状態であれば、STONITHが成功した、と判定される。したがって、このケースは、より確実なSTONITHを実行できる。
(STONITH Certainty: Fencing Action - Stop)
If the VM on the remote node is powered off, it is determined that the STONITH is successful. Therefore, in this case, the STONITH can be executed more reliably.
(復旧時間:フェンシングの動作-停止)
 STONITH完了後の対向ノードは、電源オフである。しかし、対向ノードは、ホスト側の電源操作のタイミング次第では、電源オンになることもある。したがって、このケースは、運用に大きな負担となる。さらに、このケースは、復旧にかかる時間が長くなる。
(Recovery time: fencing operation - stopped)
After STONITH is complete, the power of the opposing node is off. However, the opposing node may be powered on depending on the timing of the power operation on the host side. Therefore, this case places a heavy burden on operations. Furthermore, this case requires a long time for recovery.
 図3は、フェンシングの動作が再起動である時の期待動作の例である期待動作30を示す。期待動作30は、6つの段階を含む。 FIG. 3 shows expected action 30, which is an example of expected action when the fencing action is a reboot. Expected action 30 includes six stages.
(第1の段階)
 H/W故障が、#0系で発生する。NW断が、H/W故障に伴って発生する。
(First stage)
A hardware failure occurs in system #0. A network interruption occurs along with the hardware failure.
(第2の段階)
 STONITHが、NW断のため、失敗する。
(Second stage)
STONITH fails due to network outage.
(第3の段階)
 STONITHが、失敗しつづける。また、系切り替えも、作動しない。
(Third stage)
STONITH continues to fail, and system switchover doesn't work either.
(第4の段階)
 仮想化基盤制御サーバが、VMを、予備系(standby system)の別ホストで再開する。なお、VMの再開は、#1系とは独立して行われる。例えば、仮想化基盤制御サーバは、NW断を、pingを使って検知する。NW断が検知された場合に、仮想化基盤制御サーバは、VMを、予備系で再開する。
(Fourth stage)
The virtualization platform control server restarts the VM on another host in a standby system. The VM is restarted independently of the #1 system. For example, the virtualization platform control server detects a network outage using ping. When a network outage is detected, the virtualization platform control server restarts the VM in the standby system.
(第5の段階)
 #1系のホストが、STONITHを、新しいVMに対して行う。新しいVMは、再起動される。
(Fifth stage)
The #1 host performs a STONITH on the new VM, which is then rebooted.
(第6の段階)
 SBY系が、STONITH成功によって、ACT系昇格する。
(Sixth stage)
Due to the success of STONITH, the SBY system is promoted to the ACT system.
 図4は、フェンシングの動作が再起動である時の問題事例の例である問題事例40を示す。問題事例40は、実際に起きた動作を示す。問題事例40は、7つの段階を含む。 Figure 4 shows problem case 40, which is an example of a problem case when the fencing action is a reboot. Problem case 40 shows the actual action that occurred. Problem case 40 includes seven stages.
(第1の段階)
 H/W故障が、#0系で発生する。NW断が、H/W故障に伴って発生する。
(First stage)
A hardware failure occurs in system #0. A network interruption occurs along with the hardware failure.
(第2の段階)
 STONITHが、NW断のため、失敗する。
(Second stage)
STONITH fails due to network outage.
(第3の段階)
 STONITHが、失敗しつづける。また、系切り替えも、作動しない。
(Third stage)
STONITH continues to fail, and system switchover doesn't work either.
(第4の段階)
 仮想化基盤制御サーバが、VMを、予備系の別ホストで再開する。
(Fourth stage)
The virtualization infrastructure control server restarts the VM on another host as a backup system.
(第5の段階)
 #1系のホストが、STONITHを、新しいVMに対して行う。新しいVMは、再起動される。
(Fifth stage)
The #1 host performs a STONITH on the new VM, which is then rebooted.
(第6の段階)
 VMの再起動が、何らかの原因で成功しない。STONITHは、成功しない。
(Sixth stage)
Rebooting the VM is not successful for some reason. STONITH is not successful.
(第7の段階)
 系切り替えが作動せず、両系がダウン状態に陥る。
(Seventh stage)
System switching does not work and both systems go down.
 図5は、フェンシングの動作が停止である時の期待動作の例である期待動作50を示す。期待動作50は、6つの段階を含む。 FIG. 5 shows expected behavior 50, which is an example of expected behavior when fencing operation is stopped. Expected behavior 50 includes six stages.
(第1の段階)
 H/W故障が、#0系で発生する。NW断が、H/W故障に伴って発生する。
(First stage)
A hardware failure occurs in system #0. A network interruption occurs along with the hardware failure.
(第2の段階)
 STONITHが、NW断のため、失敗する。
(Second stage)
STONITH fails due to network outage.
(第3の段階)
 STONITHが、失敗しつづける。また、系切り替えも、作動しない。
(Third stage)
STONITH continues to fail, and system switchover doesn't work either.
(第4の段階)
 仮想化基盤制御サーバが、VMを、予備系の別ホストで再開する。
(Fourth stage)
The virtualization infrastructure control server restarts the VM on another host as a backup system.
(第5の段階)
 #1系のホストが、STONITHを、新しいVMに対して行う。新しいVMは、停止される。
(Fifth stage)
The host in the #1 series performs a STONITH on the new VM, which is then stopped.
(第6の段階)
 新しいVMは、STONITHにより、電源オフの状態である。SBY系が、STONITH成功によって、ACT系昇格する。
(Sixth stage)
The new VM is in a powered off state due to STONITH. The SBY system is promoted to the ACT system due to the success of STONITH.
 図6は、フェンシングの動作が停止である時の問題事例の例である問題事例60を示す。問題事例60は、実際に起きた動作を示す。問題事例60は、7つの段階を含む。 FIG. 6 shows problem case 60, which is an example of a problem case when fencing action is stopped. Problem case 60 shows the actual action that occurred. Problem case 60 includes seven stages.
(第1の段階)
 H/W故障が、#0系で発生する。NW断が、H/W故障に伴って発生する。
(First stage)
A hardware failure occurs in system #0. A network interruption occurs along with the hardware failure.
(第2の段階)
 STONITHが、NW断のため、失敗する。
(Second stage)
STONITH fails due to network outage.
(第3の段階)
 STONITHが、失敗しつづける。また、系切り替えも、作動しない。
(Third stage)
STONITH continues to fail, and system switchover doesn't work either.
(第4の段階)
 仮想化基盤制御サーバが、VMを、予備系の別ホストで再開する。
(Fourth stage)
The virtualization infrastructure control server restarts the VM on another host as a backup system.
(第5の段階)
 #1系のホストが、STONITHを、新しいVMに対して行う。新しいVMは、停止される。VMの再開は、継続中である。
(Fifth stage)
The #1 host performs a STONITH to the new VM. The new VM is stopped. The VM resumes while it continues.
(第6の段階)
 新しいVMは、STONITHにより、電源オフの状態である。SBY系が、STONITH成功によって、ACT系昇格する。しかし、VMの再開が、まだ継続中である。
(Sixth stage)
The new VM is powered off due to STONITH. The standby system is promoted to the active system due to the success of STONITH. However, the VM is still being resumed.
(第7の段階)
 VMの再開が、完了する。VMが、起動する。
(Seventh stage)
The VM resumes and then boots.
 図4および図6を参照して上で説明したように、課題が、フェンシングの動作が再起動であるケースだけでなく、フェンシングの動作が停止であるケースにもある。上記の課題を解決するために、本開示に係るホストは、以下で説明する1つまたは複数のクラスタ復旧処理を行う。 As described above with reference to Figures 4 and 6, the problem exists not only in the case where the fencing action is a restart, but also in the case where the fencing action is a stop. To solve the above problem, the host according to the present disclosure performs one or more cluster recovery processes described below.
〔2.クラスタ復旧のための環境〕
 まず、クラスタ復旧のための環境を、図7を参照して説明する。
[2. Cluster recovery environment]
First, the environment for cluster recovery will be described with reference to FIG.
 図7は、クラスタ復旧のための環境の例である環境1のブロック図である。図7に示されるように、環境1は、ホスト100、ネットワーク200および制御サーバ300を含む。ホスト100は、故障復旧高速化システムの一例である。 FIG. 7 is a block diagram of environment 1, which is an example of an environment for cluster recovery. As shown in FIG. 7, environment 1 includes host 100, network 200, and control server 300. Host 100 is an example of a high-speed failure recovery system.
 ホスト100は、ノードが故障したクラスタを復旧するための処理を行うシステムである。この明細書では、このような処理は、クラスタ復旧処理と呼ばれる。クラスタ復旧処理の概要を、3節で説明する。そして、クラスタ復旧処理の詳細を、5節でシーケンス図を使って説明する。 Host 100 is a system that performs processing to recover a cluster in which a node has failed. In this specification, such processing is called cluster recovery processing. An overview of cluster recovery processing is explained in Section 3. The details of cluster recovery processing are explained in Section 5 using a sequence diagram.
 ホスト100は、1つまたは複数のサーバ等の、1つまたは複数のコンピュータを含む。ホスト100の構成の例を、4節で説明する。 Host 100 includes one or more computers, such as one or more servers. An example configuration of host 100 is described in Section 4.
 ネットワーク200は、LAN(Local Area Network)、WAN(Wide Area Network)、インターネット等のネットワークである。ネットワーク200は、ホスト100および制御サーバ300を接続する。 The network 200 is a network such as a LAN (Local Area Network), a WAN (Wide Area Network), or the Internet. The network 200 connects the host 100 and the control server 300.
 制御サーバ300は、クラスタを制御するサーバである。制御サーバ300は、例えば、仮想化基盤制御サーバである。 The control server 300 is a server that controls the cluster. The control server 300 is, for example, a virtualization infrastructure control server.
〔3.クラスタ復旧処理の概要〕
 次に、1つのクラスタ復旧処理の概要(overview)を、図8を参照して説明する。なお、この概要は、本発明や、以下の節で説明する複数の実施形態を限定することを意図するものではない。
[3. Overview of cluster recovery process]
Next, an overview of a cluster recovery process is described with reference to Figure 8. Note that this overview is not intended to limit the invention or the embodiments described in the following sections.
 図8は、本開示に係る1つのクラスタ復旧処理の概要である概要70を示す。概要70は、既存技術(フェンシング:「再起動」または「停止」)と、本技術を比較するものである。 FIG. 8 shows overview 70, which is an overview of one cluster recovery process according to the present disclosure. Overview 70 compares the present technology with existing techniques (fencing: "restart" or "stop").
 図4および図6を参照して上で説明したように、既存技術は、問題事例を含む。「再起動」に関しては、もし、再起動が完了しなければ、STONITHが失敗する。「停止」に関しては、VMの状態が、ホスト側のクラスタリング機能のタイミング次第では、異なる。 As explained above with reference to Figures 4 and 6, the existing technology includes problem cases. For "reboot", if the reboot is not completed, STONITH fails. For "stop", the VM state is different depending on the timing of the host-side clustering function.
 本明細書で提案される技術は、フェンシングの動作が、「停止」であるという前提に基づく。本技術では、ホスト100a(ノード#1)が、ホスト100b(ノード#0)を、制御サーバ300を介して、電源オフにする。その後、ホスト100aは、ホスト100bの電源状態を確認する。もし、電源状態が電源オフであれば、ホスト100aは、ホスト100bを、制御サーバ300を介して、電源オンにする。この電源操作は、図6を参照して上で説明した問題(第5、第6および第7の段階)を解決するものである。その結果、本技術は、STONITHにおけるクラスタシステムの復旧時間を短縮化することができる。 The technology proposed in this specification is based on the premise that the fencing operation is "stop." In this technology, host 100a (node #1) powers off host 100b (node #0) via control server 300. After that, host 100a checks the power status of host 100b. If the power status is powered off, host 100a powers on host 100b via control server 300. This power operation solves the problem (fifth, sixth, and seventh stages) described above with reference to FIG. 6. As a result, this technology can shorten the recovery time of a cluster system in STONITH.
〔4.ホストの構成〕
 次に、ホスト100の構成の例を、図9を参照して説明する。
4. Host Configuration
Next, an example of the configuration of the host 100 will be described with reference to FIG.
 図9は、本開示に係るホスト100の構成の例のブロック図である。図9に示されるように、ホスト100は、通信部110、制御部120および記憶部130を含む。ホスト100は、ホスト100の管理者から入力を受け付ける入力部(例えば、キーボード、マウス)を含んでもよい。また、ホスト100は、管理者に情報を表示する出力部(例えば、液晶ディスプレイ、有機EL(Electro Luminescence)ディスプレイ)を含んでもよい。 FIG. 9 is a block diagram of an example of the configuration of a host 100 according to the present disclosure. As shown in FIG. 9, the host 100 includes a communication unit 110, a control unit 120, and a memory unit 130. The host 100 may include an input unit (e.g., a keyboard, a mouse) that accepts input from an administrator of the host 100. The host 100 may also include an output unit (e.g., a liquid crystal display, an organic EL (Electro Luminescence) display) that displays information to the administrator.
(通信部110)
 通信部110は、NIC(Network Interface Card)等のネットワーク機器によって実装される。通信部110は、有線または無線によりネットワーク200と接続される。通信部110は、ネットワーク200を介して、制御サーバ300との間で、データの送受信を行うことができる。
(Communication unit 110)
The communication unit 110 is implemented by a network device such as a network interface card (NIC). The communication unit 110 is connected to the network 200 by wire or wirelessly. The communication unit 110 can transmit and receive data to and from the control server 300 via the network 200.
(制御部120)
 制御部120は、データ処理装置と、記憶装置に記憶された各種プログラムによって実装される。データ処理装置は、例えば、CPU(Central Processing Unit)、MPU(Micro Processing Unit)、GPGPU(General Purpose Graphic Processing Unit)等のプロセッサである。制御部120は、ホスト100の複数の動作を制御するためのコントローラ(controller)として実装され得る。例えば、1つまたは複数のプロセッサが、RAM(Random Access Memory)を作業領域として使用することで、プログラム(複数の命令)を実行した場合に、この1つまたは複数のプロセッサは、複数の動作を行う。
(Control unit 120)
The control unit 120 is implemented by a data processing device and various programs stored in a storage device. The data processing device is, for example, a processor such as a central processing unit (CPU), a micro processing unit (MPU), or a general purpose graphic processing unit (GPGPU). The control unit 120 can be implemented as a controller for controlling multiple operations of the host 100. For example, when one or more processors execute a program (multiple instructions) by using a random access memory (RAM) as a working area, the one or more processors perform multiple operations.
 制御部120は、クラスタ復旧処理のための入力データを、外部装置から受信することができる。制御部120は、入力データ、クラスタ復旧処理において使用されるデータ、クラスタ復旧処理の出力データ等のデータを、記憶部130に格納することができる。制御部120は、このようなデータを、記憶部130から、必要に応じて取得することができる。 The control unit 120 can receive input data for the cluster recovery process from an external device. The control unit 120 can store data such as the input data, data used in the cluster recovery process, and output data of the cluster recovery process in the storage unit 130. The control unit 120 can obtain such data from the storage unit 130 as necessary.
(記憶部130)
 記憶部130は、RAM、フラッシュメモリ(Flash Memory)等の半導体メモリ、ハードディスク等の磁気ディスク、または光ディスクによって実装される。記憶部130は、各種プログラムおよび各種データを記憶することができる。
(Memory unit 130)
The storage unit 130 is implemented by a RAM, a semiconductor memory such as a flash memory, a magnetic disk such as a hard disk, or an optical disk. The storage unit 130 can store various programs and various data.
 図9に示されるように、制御部120は、フェンシング部121、特定部122、要求部123、確認部124、通知部125および復旧部126を含む。フェンシング部121は、第1指示部の一例である。特定部122は、取得部の一例である。要求部123は、判定部および第2指示部の一例である。復旧部126は、組み込み部の一例である。個々の部によって行われるデータ処理を、以下で説明する。 As shown in FIG. 9, the control unit 120 includes a fencing unit 121, an identification unit 122, a request unit 123, a confirmation unit 124, a notification unit 125, and a recovery unit 126. The fencing unit 121 is an example of a first instruction unit. The identification unit 122 is an example of an acquisition unit. The request unit 123 is an example of a determination unit and a second instruction unit. The recovery unit 126 is an example of an integration unit. The data processing performed by each unit is described below.
(フェンシング部121)
 フェンシング部121は、フェンシングの動作を行う。フェンシング部121は、STONITHを、対向ノードに対して行うことができる。
(Fencing Club 121)
The fencing unit 121 performs fencing operations. The fencing unit 121 can perform STONITH on the remote node.
(特定部122)
 特定部122は、対向ノードの状態を特定する。例えば、対向ノードの状態は、電源状態である。
(Identification unit 122)
The identifying unit 122 identifies the state of the remote node. For example, the state of the remote node is a power state.
(要求部123)
 要求部123は、制御サーバ300に、対向ノードの電源オンにするよう、要求する。
(Request Unit 123)
The request unit 123 requests the control server 300 to power on the remote node.
(確認部124)
 確認部124は、対向ノードの正常性を確認する。
(Confirmation Unit 124)
The confirmation unit 124 confirms the normality of the remote node.
(通知部125)
 通知部125は、通知を、保守者に送信する。
(Notification unit 125)
The notification unit 125 transmits the notification to the maintenance person.
(復旧部126)
 復旧部126は、クラスタを復旧する。
(Recovery Unit 126)
The recovery unit 126 recovers the cluster.
〔5.クラスタ復旧処理の詳細〕
 1つのクラスタ復旧処理の概要を、図8を参照して上で説明した。クラスタ復旧処理の詳細を、この節でシーケンス図を使って説明する。
[5. Details of cluster recovery process]
An overview of one cluster recovery process is given above with reference to Figure 8. The details of the cluster recovery process are given in this section with the aid of sequence diagrams.
 クラスタ復旧処理の例のシーケンス図を、図10を参照して説明する。クラスタ復旧処理の例は、ノードが故障したクラスタを復旧するための処理を含む。ノードが故障したクラスタを復旧するための処理は、例えば、図7のホスト100によって行われる。 A sequence diagram of an example of cluster recovery processing will be described with reference to FIG. 10. The example of cluster recovery processing includes processing for recovering a cluster in which a node has failed. The processing for recovering a cluster in which a node has failed is performed, for example, by the host 100 in FIG. 7.
 図10は、ノードが故障したクラスタを復旧するための処理の例である処理P100を示すシーケンス図である。処理P100は、STONITHデバイスと、ホスト100aの新規モジュールによって行われる。STONITHデバイスは、フェンシング部121に対応する。新規モジュールは、特定部122、要求部123、確認部124、通知部125および復旧部126に対応する。 FIG. 10 is a sequence diagram showing process P100, which is an example of a process for recovering a cluster in which a node has failed. Process P100 is performed by the STONITH device and a new module of the host 100a. The STONITH device corresponds to the fencing unit 121. The new module corresponds to the identification unit 122, the request unit 123, the confirmation unit 124, the notification unit 125, and the recovery unit 126.
 処理P100は、フェンシングの動作が、「停止」であるという前提に基づく。 Process P100 is based on the assumption that the fencing operation is "stopped."
 ホスト100a(ノード#1)は、例えば、図3、図4、図5および図6の#1系に対応する。この場合、ホスト100b(ノード#0)は、図3、図4、図5および図6の予備系に対応する。制御サーバ300は、図3、図4、図5および図6の仮想化基盤制御サーバに対応する。 Host 100a (node #1) corresponds to, for example, the #1 system in Figures 3, 4, 5, and 6. In this case, host 100b (node #0) corresponds to the standby system in Figures 3, 4, 5, and 6. Control server 300 corresponds to the virtualization infrastructure control server in Figures 3, 4, 5, and 6.
 ホスト100a(例えば、フェンシング部121)は、STONITHを、制御サーバ300を介して、ホスト100bに対して行う(ステップS101)。 Host 100a (e.g., fencing unit 121) performs STONITH on host 100b via control server 300 (step S101).
 新規モジュールは、STONITH完了の通知を、STONITHデバイスから受信する(ステップS102)。「trap」コマンドが、通知のために使用され得る。新規モジュールは、動作を、通知を受信することで、開始する。 The new module receives notification of STONITH completion from the STONITH device (step S102). A "trap" command may be used for the notification. The new module begins operation upon receiving the notification.
 ホスト100a(例えば、特定部122)は、VMの状態の確認についての指示を、制御サーバ300に送信する(ステップS103)。 The host 100a (e.g., the identification unit 122) sends an instruction to the control server 300 to check the status of the VM (step S103).
 制御サーバ300は、VMの状態の要求を、ホスト100bに送信する(ステップS104)。 The control server 300 sends a request for the VM status to the host 100b (step S104).
 ホスト100bは、VMの状態を、制御サーバ300に送信する(ステップS105)。 The host 100b sends the status of the VM to the control server 300 (step S105).
 制御サーバ300は、VMの状態を、ホスト100aに返却する(ステップS106)。その後、ホスト100aは、対向ノード(VM)の状態を確認する。 The control server 300 returns the status of the VM to the host 100a (step S106). The host 100a then checks the status of the opposing node (VM).
 もし、VM(対向ノード)の状態が電源オフであれば、ホスト100a(例えば、要求部123)は、対向ノードの電源オンについての指示を、制御サーバ300に出す(ステップS107)。 If the VM (opposing node) is powered off, the host 100a (e.g., the request unit 123) issues an instruction to the control server 300 to power on the opposing node (step S107).
 制御サーバ300は、対向ノードを、電源オン要求を対向ノードに送信することによって、電源オンにする(ステップS108)。 The control server 300 powers on the opposing node by sending a power-on request to the opposing node (step S108).
 制御サーバ300は、VMの状態の要求を、ホスト100bに送信する(ステップS109)。 The control server 300 sends a request for the VM status to the host 100b (step S109).
 ホスト100bは、VMの状態を、制御サーバ300に送信する(ステップS110)。 Host 100b sends the VM status to control server 300 (step S110).
 制御サーバ300は、VMの状態を、ホスト100aに返却する(ステップS111)。 The control server 300 returns the VM state to the host 100a (step S111).
 上記のステップに加えて、ホスト100aは、以下のステップを、さらに復旧時間を短縮化するために、行う。以下のステップは、対向ノード上のサービスやプロセスの正常性を確認することである。具体的には、ホスト100aは、保守者が対応しなければならないイベントの有無を、確認する。 In addition to the steps above, host 100a performs the following steps to further shorten recovery time. The following steps are to check the normality of services and processes on the remote node. Specifically, host 100a checks whether there are any events that require maintenance personnel to respond.
 ホスト100a(例えば、確認部124)は、正常性の確認についての指示を、制御サーバ300に送信する(ステップS112)。その後、ホスト100aは、サービスやプロセスの正常性を確認する。 The host 100a (e.g., the confirmation unit 124) sends an instruction to the control server 300 to confirm the normality (step S112). The host 100a then checks the normality of the services and processes.
 もし、保守者が対応する必要があれば、ホスト100a(例えば、通知部125)は、保守者に通知する。例えば、ホスト100aは、保守の要求に関する通知を、保守者に送信する(ステップS113)。この場合、ホスト100aは、クラスタを復旧しない。 If a maintenance person needs to take action, the host 100a (e.g., the notification unit 125) notifies the maintenance person. For example, the host 100a sends a notification regarding the maintenance request to the maintenance person (step S113). In this case, the host 100a does not recover the cluster.
 もし、保守者が対応する必要がなければ、ホスト100a(例えば、復旧部126)は、対向ノードをクラスタに組み込み、それから、クラスタを復旧する(ステップS114)。 If no maintenance personnel is required to take action, host 100a (e.g., recovery unit 126) incorporates the opposing node into the cluster and then recovers the cluster (step S114).
 なお、クラスタシステムにとっては、正常性の確認の後に、対向ノードをクラスタに組み込むのが、安全である。したがって、処理P100は、対向ノードが、VMが起動したときにクラスターに自動的に組み込まれないように、設定されている、という前提に基づく。 It is safe for the cluster system to incorporate the opposing node into the cluster after confirming its normality. Therefore, process P100 is based on the assumption that the opposing node is configured not to be automatically incorporated into the cluster when the VM starts up.
〔6.効果〕
 本技術は、フェンシングの動作が、「停止」である、という前提に基づく。したがって、STONITHの確実性は、担保される。
6. Effects
This technology is based on the premise that the action of fencing is "stop." Therefore, the reliability of STONITH is guaranteed.
 STONITHの完了後、対向ノード上のVMの状態は、電源オンになる。結果として生じる対向ノードの電源状態は、STONITHを行ったノードと同じである。加えて、もし、保守者が介在する必要がなければ、ホスト100は、自動的にクラスタを復旧し、それから、設備(equipment)を回復する。このことは、運用上の負担を軽減し、かつ、復旧時間(STONITH完了からサービスの再開までの時間)を短縮化することができる。 After STONITH is completed, the state of the VMs on the opposing node will be powered on. The resulting power state of the opposing node will be the same as the node that performed STONITH. In addition, if no maintenance intervention is required, the host 100 will automatically recover the cluster and then the equipment. This can reduce operational burden and shorten recovery time (the time from STONITH completion to resumption of service).
〔7.ハードウェア構成〕
 図11は、コンピュータのハードウェア構成の例であるコンピュータ1000を示す図である。この明細書で説明されたシステムや方法は、例えば、コンピュータ1000によって実装される。
7. Hardware Configuration
11 is a diagram showing an example of a hardware configuration of a computer 1000. The systems and methods described in this specification are implemented by the computer 1000, for example.
 コンピュータ1000は、プログラムを実行することでホスト100を実装するコンピュータの一例を示している。コンピュータ1000は、メモリ1010、CPU1020を有する。また、コンピュータ1000は、ハードディスクドライブインタフェース1030、ディスクドライブインタフェース1040、シリアルポートインタフェース1050、ビデオアダプタ1060およびネットワークインタフェース1070を有する。これらの構成要素は、バス1080によって接続される。 Computer 1000 is an example of a computer that implements host 100 by executing a program. Computer 1000 has memory 1010 and CPU 1020. Computer 1000 also has hard disk drive interface 1030, disk drive interface 1040, serial port interface 1050, video adapter 1060, and network interface 1070. These components are connected by bus 1080.
 メモリ1010は、ROM(Read Only Memory)1011およびRAM1012を含む。ROM1011は、例えば、BIOS(Basic Input Output System)等のブートプログラムを記憶する。ハードディスクドライブインタフェース1030は、ハードディスクドライブ1090に接続される。ディスクドライブインタフェース1040は、ディスクドライブ1100に接続される。着脱可能な記憶媒体(例えば、磁気ディスクや光ディスク)が、ディスクドライブ1100に挿入され得る。シリアルポートインタフェース1050は、例えば、マウス1110、キーボード1120に接続される。ビデオアダプタ1060は、例えば、ディスプレイ1130に接続される。 The memory 1010 includes a ROM (Read Only Memory) 1011 and a RAM 1012. The ROM 1011 stores a boot program such as a BIOS (Basic Input Output System). The hard disk drive interface 1030 is connected to a hard disk drive 1090. The disk drive interface 1040 is connected to a disk drive 1100. A removable storage medium (e.g., a magnetic disk or an optical disk) can be inserted into the disk drive 1100. The serial port interface 1050 is connected to, for example, a mouse 1110 and a keyboard 1120. The video adapter 1060 is connected to, for example, a display 1130.
 ハードディスクドライブ1090は、OS1091、アプリケーションプログラム1092、プログラムモジュール1093およびプログラムデータ1094を記憶する。コンピュータ1000によって実行されるプログラムは、ホスト100の複数の動作を規定する。このプログラムは、コンピュータ1000により実行可能なコードで記述されたプログラムモジュール1093として実装され得る。プログラムモジュール1093は、例えば、ハードディスクドライブ1090に記憶される。例えば、ハードディスクドライブ1090は、ホスト100の構成要素の機能と同様の処理を実行するためのプログラムモジュール1093を記憶する。なお、ハードディスクドライブ1090は、SSD(Solid State Drive)に置き換えられてもよい。 The hard disk drive 1090 stores an OS 1091, an application program 1092, a program module 1093, and program data 1094. The program executed by the computer 1000 defines multiple operations of the host 100. This program may be implemented as a program module 1093 written in code executable by the computer 1000. The program module 1093 is stored, for example, in the hard disk drive 1090. For example, the hard disk drive 1090 stores a program module 1093 for executing processing similar to the functions of the components of the host 100. The hard disk drive 1090 may be replaced with an SSD (Solid State Drive).
 ハードディスクドライブ1090は、クラスタ復旧処理のための故障復旧高速化プログラムを記憶することができる。ハードディスクドライブ1090は、故障復旧高速化プログラム(複数の命令)を含むコンピュータプログラムプロダクトを記憶してもよい。故障復旧高速化プログラムは、実行された場合に、上で説明したような、1つまたは複数の方法を行う。 Hard disk drive 1090 can store a failure recovery acceleration program for cluster recovery processing. Hard disk drive 1090 may store a computer program product including a failure recovery acceleration program (a plurality of instructions). When executed, the failure recovery acceleration program performs one or more methods, such as those described above.
 上で説明した様々な処理に用いられる設定データは、プログラムデータ1094として実装され得る。設定データは、例えば、メモリ1010やハードディスクドライブ1090に記憶される。CPU1020は、メモリ1010やハードディスクドライブ1090に記憶されたプログラムモジュール1093やプログラムデータ1094を、必要に応じて、RAM1012にロードする。そして、CPU1020は、上で説明した様々な処理を行う。 The setting data used in the various processes described above can be implemented as program data 1094. The setting data is stored, for example, in the memory 1010 or the hard disk drive 1090. The CPU 1020 loads the program module 1093 or the program data 1094 stored in the memory 1010 or the hard disk drive 1090 into the RAM 1012 as necessary. The CPU 1020 then performs the various processes described above.
 なお、プログラムモジュール1093やプログラムデータ1094は、ハードディスクドライブ1090ではなく、着脱可能な記憶媒体に記憶されてもよい。CPU1020は、プログラムモジュール1093やプログラムデータ1094を、ディスクドライブ1100等を介してロードしてもよい。あるいは、プログラムモジュール1093やプログラムデータ1094は、ネットワーク(LAN、WAN等)を介してコンピュータ1000に接続された他のコンピュータに記憶されてもよい。この場合、CPU1020は、プログラムモジュール1093やプログラムデータ1094を、ネットワークインタフェース1070を介してロードしてもよい。 The program module 1093 and program data 1094 may be stored in a removable storage medium instead of the hard disk drive 1090. The CPU 1020 may load the program module 1093 and program data 1094 via the disk drive 1100 or the like. Alternatively, the program module 1093 and program data 1094 may be stored in another computer connected to the computer 1000 via a network (LAN, WAN, etc.). In this case, the CPU 1020 may load the program module 1093 and program data 1094 via the network interface 1070.
〔8.実施形態のまとめ〕
 上で説明したように、ホスト100は、フェンシング部121、特定部122および要求部123を含む。少なくとも1つの実施形態では、フェンシング部121は、クラスタを制御するサーバに、予備系のノードに対する電源操作を実行するよう指示する。少なくとも1つの実施形態では、特定部122は、電源操作の完了の通知を受信することに応じて、予備系のノードの電源状態を取得する。少なくとも1つの実施形態では、要求部123は、予備系のノードの電源状態が電源オンまたは電源オフであるか、を判定する。予備系のノードの電源状態が電源オフである、と判定することに応じて、要求部123は、サーバに、予備系のノードの電源をオンにするよう指示する。
8. Summary of the embodiment
As described above, host 100 includes fencing unit 121, identifying unit 122, and request unit 123. In at least one embodiment, fencing unit 121 instructs a server controlling the cluster to execute a power operation on the standby node. In at least one embodiment, identifying unit 122 acquires the power state of the standby node in response to receiving a notification of the completion of the power operation. In at least one embodiment, request unit 123 determines whether the power state of the standby node is powered on or powered off. In response to determining that the power state of the standby node is powered off, request unit 123 instructs the server to power on the standby node.
 いくつかの実施形態では、電源操作は、STONITHである。 In some embodiments, the power operation is STONITH.
 いくつかの実施形態では、STONITHのフェンシングの動作は、停止である。 In some embodiments, the fencing action of STONITH is to stop.
 上で説明したように、ホスト100は、確認部124を含む。少なくとも1つの実施形態では、確認部124は、予備系のノードのサービスまたはプロセスの正常性を確認する。 As described above, the host 100 includes a verification unit 124. In at least one embodiment, the verification unit 124 verifies the health of the services or processes of the backup node.
 上で説明したように、ホスト100は、復旧部126を含む。復旧部126は、予備系のノードを、クラスタに、サービスまたはプロセスが正常である場合に組み込む。 As described above, the host 100 includes a recovery unit 126. The recovery unit 126 incorporates a backup node into the cluster when the service or process is normal.
 上で説明したように、ホスト100は、通知部125を含む。通知部125は、保守者に、予備系のノードのための保守要求を、サービスまたはプロセスが正常でない場合に通知する。 As described above, the host 100 includes a notification unit 125. The notification unit 125 notifies the maintenance personnel of a maintenance request for the backup node when a service or process is not normal.
〔9.補遺〕
 最後に、上記の説明を、その他の実施形態で補う。様々な実施形態を、図面を参照して上で説明してきた。これらの実施形態は、例示的であり、上記の説明は、本開示を、これらの実施形態に限定することを意図するものではない。この明細書で説明された特徴は、当業者の知識に基づく変形や改良を含む、様々な方法(ways)で実現され得る。
9. Addendum
Finally, the above description is supplemented with other embodiments. Various embodiments have been described above with reference to the drawings. These embodiments are exemplary, and the above description is not intended to limit the present disclosure to these embodiments. The features described in this specification can be realized in various ways, including modifications and improvements based on the knowledge of those skilled in the art.
(各種変形)
 この明細書では、いくつかの処理は、自動的に行われる処理として説明された。これらの処理の一部は、手動的に行われ得る。また、いくつかの他の処理は、手動的に行われる処理として説明された。これらの他の処理の全部または一部は、公知の方法を使って、自動的に行われ得る。
(Various variations)
In this specification, some processes have been described as being performed automatically. Some of these processes may be performed manually. Some other processes have been described as being performed manually. All or part of these other processes may be performed automatically using known methods.
 ホスト100の様々な実装が、本明細書で説明されるか、または図面に示されている。いくつかの実装は、各種のデータ、データ処理手順、具体的名称、またはパラメータを含む情報に関する。このような実装は、特に明記しない限り、任意に変更され得る。例えば、各種のデータは、図面に示されたデータに限られない。 Various implementations of the host 100 are described herein or shown in the drawings. Some implementations relate to information that includes various data, data processing procedures, specific names, or parameters. Such implementations may be modified in any way unless otherwise specified. For example, the various data are not limited to the data shown in the drawings.
 システムの構成要素が、図面に示されている。図示された構成要素は、システムの機能を、概念的に示すものである。構成要素は、必ずしも、図面に示されたように物理的に構成されているとは限らない。構成要素は、統合または分散されてもよく、システムの具体的形態は、図示された形態に限られない。システムの全部または一部は、各種の負荷や使用状況に応じて、機能的または物理的に統合または分散され得る。 The components of the system are shown in the drawings. The illustrated components conceptually represent the functionality of the system. The components are not necessarily physically configured as shown in the drawings. The components may be integrated or distributed, and the specific form of the system is not limited to that shown in the drawings. All or part of the system may be functionally or physically integrated or distributed depending on various loads and usage conditions.
(構成要素を表す用語)
 部(module、section、-er接尾辞または-or接尾辞)という用語は、ユニット、手段、回路などに読み替えることができる。例えば、通信部(communication module)、制御部(control module)および記憶部(storage module)は、それぞれ、通信ユニット、制御ユニットおよび記憶ユニットに読み替えることができる。
(Terms expressing components)
The terms module, section, -er suffix or -or suffix may be read as unit, means, circuit, etc. For example, a communication module, a control module, and a storage module may be read as a communication unit, a control unit, and a storage unit, respectively.
(制御部の構成)
 図9に示された制御部120の構成は、例示的であり、特定の部に関して説明されたデータ処理は、必ずしも、その特定の部によって行われなくてもよい。例えば、特定部122は、要求部123に関して説明されたデータ処理を行ってもよい。また、制御部120は、図9に示されていないその他の部を含んでもよい。その他の部は、制御部120に関して説明されたデータ処理を行ってもよい。
(Configuration of the control unit)
The configuration of the control unit 120 shown in Fig. 9 is exemplary, and the data processing described with respect to a particular unit does not necessarily have to be performed by that particular unit. For example, the identification unit 122 may perform the data processing described with respect to the request unit 123. Furthermore, the control unit 120 may include other units not shown in Fig. 9. The other units may perform the data processing described with respect to the control unit 120.
(データ処理装置)
 制御部120に関して説明されたデータ処理装置は、上で説明した特定のハードウェアに限定されるものはない。データ処理装置は、例えば、各種のコンピュータ、またはASIC(Application Specific Integrated Circuit)、FPGA(Field Programmable Gate Array)、GPGPU(General Purpose Graphic Processing Unit)等の集積回路であってもよい。
(Data Processing Device)
The data processing device described with respect to the control unit 120 is not limited to the specific hardware described above. The data processing device may be, for example, various computers or integrated circuits such as an ASIC (Application Specific Integrated Circuit), an FPGA (Field Programmable Gate Array), or a GPGPU (General Purpose Graphic Processing Unit).
   1 環境
 100 ホスト
 110 通信部
 120 制御部
 121 フェンシング部
 122 特定部
 123 要求部
 124 確認部
 125 通知部
 126 復旧部
 130 記憶部
 200 ネットワーク
 300 制御サーバ
REFERENCE SIGNS LIST 1 Environment 100 Host 110 Communication unit 120 Control unit 121 Fencing unit 122 Identification unit 123 Request unit 124 Confirmation unit 125 Notification unit 126 Recovery unit 130 Storage unit 200 Network 300 Control server

Claims (8)

  1.  クラスタを制御するサーバに、予備系のノードに対する電源操作を実行するよう指示する第1指示部と、
     前記電源操作の完了の通知を受信することに応じて、前記予備系のノードの電源状態を取得する取得部と、
     前記予備系のノードの電源状態が電源オンまたは電源オフであるか、を判定する判定部と、
     前記予備系のノードの電源状態が電源オフである、と判定することに応じて、前記サーバに、前記予備系のノードの電源をオンにするよう指示する第2指示部と
     を備える故障復旧高速化システム。
    a first instruction unit that instructs a server that controls the cluster to execute a power supply operation on a standby node;
    an acquisition unit that acquires a power state of the backup node in response to receiving a notification of the completion of the power operation;
    a determination unit that determines whether a power state of the backup node is powered on or powered off;
    a second instruction unit that instructs the server to turn on the power of the backup node in response to determining that the power state of the backup node is powered off.
  2.  前記電源操作は、STONITH(Shoot The Other Node In The Head)である
     請求項1に記載の故障復旧高速化システム。
    The high-speed failure recovery system according to claim 1 , wherein the power supply operation is STONITH (Shoot The Other Node In The Head).
  3.  前記STONITHのフェンシングの動作は、停止である
     請求項2に記載の故障復旧高速化システム。
    The system for accelerating failure recovery according to claim 2 , wherein the fencing action of the STONITH is a stop.
  4.  前記予備系のノードのサービスまたはプロセスの正常性を確認する確認部をさらに備える
     請求項1に記載の故障復旧高速化システム。
    The fast failure recovery system according to claim 1 , further comprising a confirmation unit that confirms normality of a service or process of the standby node.
  5.  前記予備系のノードを、前記クラスタに、前記サービスまたは前記プロセスが正常である場合に組み込む組み込み部をさらに備える
     請求項4に記載の故障復旧高速化システム。
    The failure recovery speed-up system according to claim 4 , further comprising an incorporating unit that incorporates the standby node into the cluster when the service or the process is normal.
  6.  保守者に、前記予備系のノードのための保守要求を、前記サービスまたは前記プロセスが正常でない場合に通知する通知部をさらに備える
     請求項4に記載の故障復旧高速化システム。
    5. The fast failure recovery system according to claim 4, further comprising a notification unit that notifies a maintenance person of a maintenance request for said standby node when said service or said process is not normal.
  7.  コンピュータが実行する故障復旧高速化方法であって、
     クラスタを制御するサーバに、予備系のノードに対する電源操作を実行するよう指示する第1指示工程と、
     前記電源操作の完了の通知を受信することに応じて、前記予備系のノードの電源状態を取得する取得工程と、
     前記予備系のノードの電源状態が電源オンまたは電源オフであるか、を判定する判定工程と、
     前記予備系のノードの電源状態が電源オフである、と判定することに応じて、前記サーバに、前記予備系のノードの電源をオンにするよう指示する第2指示工程と
     を含む故障復旧高速化方法。
    1. A computer-implemented method for accelerating failure recovery, comprising:
    a first instruction step of instructing a server that controls the cluster to execute a power supply operation on a standby node;
    an acquisition step of acquiring a power state of the backup node in response to receiving a notification of completion of the power operation;
    a determination step of determining whether a power state of the backup node is powered on or powered off;
    a second instruction step of instructing the server to power on the backup node in response to determining that the power state of the backup node is powered off.
  8.  コンピュータを、請求項1~6のうちいずれか1つに記載の故障復旧高速化システムとして機能させるための故障復旧高速化プログラム。 A program for accelerating fault recovery that causes a computer to function as a fault recovery acceleration system according to any one of claims 1 to 6.
PCT/JP2022/044983 2022-12-06 2022-12-06 Failure restoration expediting system, failure restoration expediting method, and failure restoration expediting program WO2024121952A1 (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
PCT/JP2022/044983 WO2024121952A1 (en) 2022-12-06 2022-12-06 Failure restoration expediting system, failure restoration expediting method, and failure restoration expediting program

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/JP2022/044983 WO2024121952A1 (en) 2022-12-06 2022-12-06 Failure restoration expediting system, failure restoration expediting method, and failure restoration expediting program

Publications (1)

Publication Number Publication Date
WO2024121952A1 true WO2024121952A1 (en) 2024-06-13

Family

ID=91378919

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2022/044983 WO2024121952A1 (en) 2022-12-06 2022-12-06 Failure restoration expediting system, failure restoration expediting method, and failure restoration expediting program

Country Status (1)

Country Link
WO (1) WO2024121952A1 (en)

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20100088440A1 (en) * 2008-10-03 2010-04-08 Donald E Banks Detecting and preventing the split-brain condition in redundant processing units
JP2013073289A (en) * 2011-09-27 2013-04-22 Nec Corp Multiplex system, data communication card, state abnormality detection method and program
JP2016062140A (en) * 2014-09-16 2016-04-25 日本電信電話株式会社 Virtual equipment management device, virtual equipment management method, and virtual equipment management program

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20100088440A1 (en) * 2008-10-03 2010-04-08 Donald E Banks Detecting and preventing the split-brain condition in redundant processing units
JP2013073289A (en) * 2011-09-27 2013-04-22 Nec Corp Multiplex system, data communication card, state abnormality detection method and program
JP2016062140A (en) * 2014-09-16 2016-04-25 日本電信電話株式会社 Virtual equipment management device, virtual equipment management method, and virtual equipment management program

Similar Documents

Publication Publication Date Title
US9720757B2 (en) Securing crash dump files
US7861117B2 (en) Method to recover from a boot device failure during reboot or system IPL
US8458510B2 (en) LPAR creation and repair for automated error recovery
US11314665B2 (en) Information processing system, information processing device, BIOS updating method for information processing device, and BIOS updating program for information processing device
WO2018095107A1 (en) Bios program abnormal processing method and apparatus
JPH11345219A (en) Application realizing method and application realizing device
CN114116280B (en) Interactive BMC self-recovery method, system, terminal and storage medium
KR20040047209A (en) Method for automatically recovering computer system in network and recovering system for realizing the same
US20240289243A1 (en) Server and control method therefor
US20040177242A1 (en) Dynamic computer system reset architecture
CN110865907B (en) Method and system for providing service redundancy between master server and slave server
JP2002259130A (en) Information processing system and is start control method
EP2648095B1 (en) System and method for controlling the booting of a computer
WO2023109880A1 (en) Service recovery method, data processing unit and related device
US20130111454A1 (en) Technique for updating program being executed
CN109358982B (en) Hard disk self-healing device and method and hard disk
WO2024121952A1 (en) Failure restoration expediting system, failure restoration expediting method, and failure restoration expediting program
CN104572198A (en) Service restoration method and device
KR102262942B1 (en) Gateway self recovery method by the wireless bridge of wireless network system system
CN115729667A (en) Virtual machine migration method, electronic device and storage medium
WO2022044270A1 (en) Updating device, updating method, and program
US20200125434A1 (en) Preventing corruption by blocking requests
CN117215859B (en) Main and standby BIOS automatic switching method, automatic switching device and computer
CN116820618A (en) Control method and device
JP2024134586A (en) Recovery control program, recovery control method, and information processing system

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: 22967804

Country of ref document: EP

Kind code of ref document: A1