Accelerated failure recovery system, accelerated failure recovery method, and accelerated failure recovery program

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

[Technical Field]

[0001] The present disclosure relates to a system for accelerating failure recovery, a method for accelerating failure recovery, and a program for accelerating failure recovery. [Background technology]

[0002] A cluster system provides availability to a service. A cluster is multiple computers that work together to perform a task. These computers are called nodes.

[0003] Cluster systems provide a variety of high availability services, including service failover: if the node providing a service fails, another node takes over the service. [Prior art documents] [Non-patent literature]

[0004] [Non-Patent Document 1] "Chapter 1. High Availability Add-On Overview, Red Hat Enterprise Linux 8, Red Hat Customer Portal" [online], [Retrieved December 6, 2022], Internet <https: / / access.redhat.com / documentation / ja-jp / red_hat_enterprise_linux / 8 / html / configuring_and_managing_high_availability_clusters / assembly_overview-of-high-availability-configuring-and-managing-high-availability-clusters> Summary of the Invention [Problem to be solved by the invention]

[0005] However, the above prior art techniques may take a long time to restore a cluster in which a node has failed.

[0006] Therefore, the present disclosure provides a system, a method, and a program for accelerating failure recovery that can shorten the recovery time of a cluster in which a node has failed. [Means for solving the problem]

[0007] In one aspect of the present disclosure, a failure recovery acceleration system includes a first instruction unit that instructs a server controlling a cluster to perform a power operation on a backup node, an acquisition unit that acquires the power state of the backup node in response to receiving 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 powered 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. [Effects of the Invention]

[0008] The failure recovery speed-up system can shorten the recovery time of a cluster in which a node has failed. [Brief explanation of the drawings]

[0009] [Figure 1] FIG. 1 shows an example of a cluster system in a virtual environment. [Figure 2] Figure 2 shows an example of a split-brain solution. [Figure 3] Figure 3 shows an example of the expected behavior when the fencing action is a reboot. [Figure 4] Figure 4 shows an example of the problem case when the fencing action is a reboot. [Figure 5] Figure 5 shows an example of the expected behavior when the fencing action is stopped. [Figure 6] Figure 6 shows an example of the problem case when the fencing action is down. [Figure 7] FIG. 7 is a block diagram of an example environment for cluster recovery. [Figure 8] FIG. 8 shows an overview of one cluster recovery process according to the present disclosure. [Figure 9] FIG. 9 is a block diagram of an example configuration of a host according to the present disclosure. [Figure 10] FIG. 10 is a sequence diagram illustrating an example of a process for recovering a cluster in which a node has failed. [Figure 11] FIG. 11 shows an example of the hardware configuration of a computer. DETAILED DESCRIPTION OF THE INVENTION

[0010] Several embodiments of the present disclosure are described in the accompanying drawings and the following description, but the present invention is not limited to these embodiments. The various features of these embodiments can be combined in various ways, provided that these features are not mutually inconsistent. Like reference numerals refer to like elements.

[0011] 〔table of contents〕 The following explanation is divided into nine sections: overview 1. Introduction 2. Cluster recovery environment 3. Cluster recovery process overview 4. Configuring the host 5. Sequence diagram of cluster recovery process 6.Effects 7. Hardware Configuration 8. Summary of embodiments 9. Addendum

[0012] 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, hosts sometimes fail. This technology achieves STONITH with a short recovery time.

[0013] 1 shows a cluster system 10, which is an example of a cluster system in a virtual environment. The cluster system 10 includes a host 11a, a host 11b, and a virtualization infrastructure control server 12. The host 11a includes a guest #1. The host 11b includes a guest #2.

[0014] When a cluster configuration is created, clustering may be 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.

[0015] The clustering software responds to failures of processes and services running within the guest. If a monitored resource fails, the clustering software performs system switching.

[0016] The virtualization infrastructure software responds to failures on the host side (for example, 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.

[0017] Figure 2 shows an example of a split-brain countermeasure, the split-brain countermeasure 20. Split-brain is a fatal problem that can occur in a cluster system.

[0018] First, communication between nodes is interrupted for some reason. As a result, the state of the correspondent node becomes unknown. After that, the SBY (Standby System) node switches to the ACT (Standby System). As a result, the cluster system ends up with multiple ACT systems. This state is called a split brain. Split brain occurs in the following situations: network disconnection between systems (21), host failure (e.g., hardware failure), or failure to stop resources.

[0019] If the service does not function correctly, data writing from multiple nodes can lead to data corruption or data inconsistency.

[0020] 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 that node to leave the cluster. If STONITH is successful, the SBY system will perform system switchover.

[0021] STONITH in a virtual environment performs power control of the remote 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 performs the power-off (22b).

[0022] As a result of STONITH, the SBY node is fenced, thereby preventing split brain from occurring. To prevent double fencing, STONITH on the SBY node is usually configured to delay the execution of STONITH.

[0023] In a system where clustering is performed on both the guest and the host, the problem lies in failure cases (for example, H / W failure) where STONITH is activated and the clustering function on the host side is activated.

[0024] Fencing actions using STONITH include "reboot" and "stop."

[0025] If the fencing action is "reboot", the success of STONITH is determined based on the completion of the peer node's reboot. Therefore, if the reboot does not complete for some reason, STONITH will fail, and as a result, system switchover will not occur. In the case of a failure of the host on the ACT side, both systems will enter the down state if system switchover does not occur.

[0026] If the fencing operation is "stopped", the difference will be the state of the peer node after STONITH is completed, depending on the timing of the power operation on the peer node by the host's clustering function.

[0027] The reliability and recovery time of STONITH (the time from completion of STONITH to resumption of service) can be summarized as follows:

[0028] (STONITH Certainty: Fencing Actions - Restart) It takes a long time to start a VM, or the VM does not start successfully. In such cases, STONITH fails, and as a result, no system switchover occurs. This has a significant impact on operations.

[0029] (Recovery time: Fencing action - Restart) After STONITH is complete, the VMs on the peer node are powered on. The power state is the same for both the node and its peer. This case results in a shorter recovery time.

[0030] (STONITH certainty: fencing operation - stopped) If the VM on the peer node is powered off, STONITH is considered successful, so this case allows for more reliable STONITH execution.

[0031] (Recovery time: fencing up - down) After STONITH is complete, the peer node is powered off. However, depending on the timing of the power operation on the host side, the peer node may be powered on. This case therefore places a heavy burden on operations. Furthermore, this case also increases the time it takes to recover.

[0032] 3 shows an example of an expected action 30 when the fencing action is a reboot. The expected action 30 includes six stages.

[0033] (First stage) A hardware failure occurs in system #0. A network outage occurs along with the hardware failure.

[0034] (Second stage) STONITH fails due to network outage.

[0035] (Third stage) STONITH keeps failing and system switchover doesn't work either.

[0036] (Fourth stage) The virtualization platform control server restarts the VM on another host in the standby system. Note that the VM is restarted independently of the #1 system. For example, the virtualization platform control server detects network outages using ping. When a network outage is detected, the virtualization platform control server restarts the VM on the standby system.

[0037] (5th stage) The #1 host performs STONITH on the new VM, which is then restarted.

[0038] (Sixth stage) If STONITH is successful, the SBY system is promoted to the ACT system.

[0039] 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:

[0040] (First stage) A hardware failure occurs in system #0. A network outage occurs along with the hardware failure.

[0041] (Second stage) STONITH fails due to network outage.

[0042] (Third stage) STONITH keeps failing and system switchover doesn't work either.

[0043] (Fourth stage) The virtualization infrastructure control server restarts the VM on another backup host.

[0044] (5th stage) The #1 host performs STONITH on the new VM, which is then restarted.

[0045] (Sixth stage) Rebooting the VM doesn't work for some reason. STONITH doesn't work.

[0046] (7th stage) System switching does not work and both systems go down.

[0047] 5 shows an example of expected behavior 50 when the fencing action is to stop. Expected behavior 50 includes six stages.

[0048] (First stage) A hardware failure occurs in system #0. A network outage occurs along with the hardware failure.

[0049] (Second stage) STONITH fails due to network outage.

[0050] (Third stage) STONITH keeps failing and system switchover doesn't work either.

[0051] (Fourth stage) The virtualization infrastructure control server restarts the VM on another backup host.

[0052] (5th stage) The #1 host performs STONITH on the new VM, which is then stopped.

[0053] (Sixth stage) The new VM is powered off due to STONITH. The SBY system is promoted to the ACT system when STONITH is successful.

[0054] 6 shows problem case 60, which is an example of a problem case when the fencing action is stop. Problem case 60 shows the action that actually occurred. Problem case 60 includes seven stages.

[0055] (First stage) A hardware failure occurs in system #0. A network outage occurs along with the hardware failure.

[0056] (Second stage) STONITH fails due to network outage.

[0057] (Third stage) STONITH keeps failing and system switchover doesn't work either.

[0058] (Fourth stage) The virtualization infrastructure control server restarts the VM on another backup host.

[0059] (5th stage) The #1 host performs STONITH on the new VM. The new VM is stopped. Restarting the VM continues.

[0060] (Sixth stage) The new VM is powered off due to STONITH. The SBY system is promoted to the ACT system due to successful STONITH. However, the VM is still being restarted.

[0061] (7th stage) The VM resumes and starts.

[0062] 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, a host according to the present disclosure performs one or more cluster recovery procedures described below.

[0063] [2. Cluster Recovery Environment] First, the environment for cluster recovery will be described with reference to FIG.

[0064] 7 is a block diagram of an environment 1, which is an example of an environment for cluster recovery. As shown in FIG. 7, the environment 1 includes a host 100, a network 200, and a control server 300. The host 100 is an example of a failure recovery acceleration system.

[0065] Host 100 is a system that performs processing to recover a cluster in which a node has failed. In this specification, this processing is called a cluster recovery process. An overview of the cluster recovery process is explained in Section 3. The details of the cluster recovery process are explained in Section 5 using a sequence diagram.

[0066] Host 100 includes one or more computers, such as one or more servers. Example configurations of Host 100 are described in Section 4.

[0067] The network 200 is a network such as a LAN (Local Area Network), a WAN (Wide Area Network), the Internet, etc. The network 200 connects the host 100 and the control server 300.

[0068] The control server 300 is a server that controls a cluster, and is, for example, a virtualization infrastructure control server.

[0069] [3. Cluster recovery process overview] An overview of one cluster recovery process will now be 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.

[0070] 8 shows an overview of one cluster recovery process according to the present disclosure, outline 70. Outline 70 compares the present technology with existing techniques (fencing: "restart" or "stop").

[0071] As explained above with reference to Figures 4 and 6, existing technologies contain problem cases. For "reboot", if the reboot is not completed, STONITH fails. For "stop", the state of the VM is different depending on the timing of the clustering function on the host side.

[0072] 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 problems (fifth, sixth, and seventh steps) described above with reference to FIG. 6. As a result, this technology can shorten the recovery time of a cluster system using STONITH.

[0073] [4. Host Configuration] Next, an example of the configuration of the host 100 will be described with reference to FIG.

[0074] 9 is a block diagram of an example 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 storage unit 130. The host 100 may also include an input unit (e.g., a keyboard, a mouse) that receives 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.

[0075] (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.

[0076] (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.

[0077] 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 acquire such data from the storage unit 130 as needed.

[0078] (Storage unit 130) The storage unit 130 is implemented by a semiconductor memory such as a RAM or 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.

[0079] As shown in FIG. 9, the control unit 120 includes a fencing unit 121, an identifying 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 identifying 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.

[0080] (Fencing Club 121) The fencing unit 121 performs fencing operations and can perform STONITH on the remote node.

[0081] (Specific Section 122) The identifying unit 122 identifies the state of the remote node. For example, the state of the remote node is the power state.

[0082] (Request part 123) The request unit 123 requests the control server 300 to power on the remote node.

[0083] (Verification section 124) The confirmation unit 124 confirms the normality of the remote node.

[0084] (Notification section 125) The notification unit 125 sends the notification to the maintenance person.

[0085] (Restoration Department 126) The recovery unit 126 recovers the cluster.

[0086] [5. Details of cluster recovery process] An overview of one cluster recovery process was explained above with reference to Figure 8. The details of the cluster recovery process are explained in this section using sequence diagrams.

[0087] A sequence diagram of an example of a cluster recovery process will be described with reference to Fig. 10. The example of the cluster recovery process includes a process for recovering a cluster in which a node has failed. The process for recovering a cluster in which a node has failed is performed by, for example, the host 100 in Fig. 7.

[0088] 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 a STONITH device and a new module in host 100a. The STONITH device corresponds to the fencing unit 121. The new module corresponds to the identifying unit 122, requesting unit 123, confirming unit 124, notifying unit 125, and recovering unit 126.

[0089] Process P100 is based on the assumption that the fencing action is "stop."

[0090] Host 100a (node ​​#1) corresponds to, for example, system #1 in Figures 3, 4, 5, and 6. In this case, host 100b (node ​​#0) corresponds to the backup 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.

[0091] The host 100a (for example, the fencing unit 121) performs STONITH on the host 100b via the control server 300 (step S101).

[0092] The new module receives a notification of STONITH completion from the STONITH device (step S102). A "trap" command can be used for the notification. The new module starts its operation upon receiving the notification.

[0093] The host 100a (for example, the identifying unit 122) sends an instruction to check the state of the VM to the control server 300 (step S103).

[0094] The control server 300 sends a request for the state of the VM to the host 100b (step S104).

[0095] The host 100b transmits the state of the VM to the control server 300 (step S105).

[0096] The control server 300 returns the state of the VM to the host 100a (step S106). After that, the host 100a checks the state of the opposing node (VM).

[0097] If the VM (opposing node) is in a power-off state, the host 100a (for example, the request unit 123) issues an instruction to the control server 300 to power on the opposing node (step S107).

[0098] The control server 300 powers on the remote node by sending a power-on request to the remote node (step S108).

[0099] The control server 300 sends a request for the state of the VM to the host 100b (step S109).

[0100] The host 100b transmits the state of the VM to the control server 300 (step S110).

[0101] The control server 300 returns the state of the VM to the host 100a (step S111).

[0102] In addition to the above steps, host 100a also performs the following steps to further reduce recovery time. These 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.

[0103] The host 100a (for example, the checking unit 124) sends an instruction to check the normality to the control server 300 (step S112). Thereafter, the host 100a checks the normality of the services and processes.

[0104] If a maintenance person needs to take action, the host 100a (for example, the notification unit 125) notifies the maintenance person. For example, the host 100a sends a notification regarding a maintenance request to the maintenance person (step S113). In this case, the host 100a does not recover the cluster.

[0105] If no maintenance personnel is required to take action, the host 100a (for example, the recovery unit 126) incorporates the remote node into the cluster, and then recovers the cluster (step S114).

[0106] It is safe for the cluster system to incorporate the peer node into the cluster after verifying its normality. Therefore, process P100 is based on the assumption that the peer node is configured not to be automatically incorporated into the cluster when the VM is started.

[0107] [6. Effects] This technology is based on the premise that the fencing action is "stop." Therefore, the reliability of STONITH is guaranteed.

[0108] After STONITH is completed, the state of the VMs on the peer node is powered on. The resulting power state of the peer node is the same as the node that performed STONITH. In addition, if no maintenance intervention is required, Host 100 automatically recovers the cluster and then restores the equipment. This reduces operational burden and shortens recovery time (the time from STONITH completion to service resumption).

[0109] [7. Hardware Configuration] 11 is a diagram showing an example of a computer hardware configuration, ie, a computer 1000. The systems and methods described in this specification are implemented by the computer 1000, for example.

[0110] A computer 1000 is an example of a computer that implements the host 100 by executing a program. The computer 1000 includes a memory 1010 and a CPU 1020. The computer 1000 also includes a hard disk drive interface 1030, a disk drive interface 1040, a serial port interface 1050, a video adapter 1060, and a network interface 1070. These components are connected by a bus 1080.

[0111] The memory 1010 includes a ROM (Read Only Memory) 1011 and a RAM 1012. The ROM 1011 stores, for example, 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 (for example, 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.

[0112] The hard disk drive 1090 stores an OS 1091, an application program 1092, a program module 1093, and program data 1094. The programs executed by the computer 1000 define multiple operations of the host 100. These programs may be implemented as program modules 1093 written in code executable by the computer 1000. The program modules 1093 are stored in, for example, the hard disk drive 1090. For example, the hard disk drive 1090 stores program modules 1093 for executing processes 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).

[0113] The hard disk drive 1090 can store a failure recovery acceleration program for cluster recovery processing. The 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 of the methods described above.

[0114] The setting data used in the various processes described above may be implemented as program data 1094. The setting data is stored in, for example, 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 needed. Then, the CPU 1020 performs the various processes described above.

[0115] The program module 1093 and the 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 the program data 1094 via the disk drive 1100 or the like. Alternatively, the program module 1093 and the program data 1094 may be stored in another computer connected to the computer 1000 via a network (such as a LAN or WAN). In this case, the CPU 1020 may load the program module 1093 and the program data 1094 via the network interface 1070.

[0116] 8. Summary of the embodiment As described above, host 100 includes fencing unit 121, identifying unit 122, and requesting unit 123. In at least one embodiment, fencing unit 121 instructs a server that controls 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 notification of the completion of the power operation. In at least one embodiment, requesting 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, requesting unit 123 instructs the server to power on the standby node.

[0117] In some embodiments, the power operation is a STONITH.

[0118] In some embodiments, the fencing action of STONITH is stop.

[0119] As described above, host 100 includes a checker 124. In at least one embodiment, checker 124 checks the health of a service or process of a standby node.

[0120] As described above, the host 100 includes a recovery unit 126. The recovery unit 126 incorporates a standby node into the cluster when the service or process is normal.

[0121] As described above, the host 100 includes a notification unit 125. The notification unit 125 notifies a maintenance person of a maintenance request for the standby node when a service or process is abnormal.

[0122] [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 implemented in various ways, including modifications and improvements based on the knowledge of those skilled in the art.

[0123] (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.

[0124] Various implementations of host 100 are described herein or illustrated in the drawings. Some implementations relate to information including various data, data processing procedures, specific names, or parameters. Such implementations may be arbitrarily modified unless otherwise specified. For example, the various data are not limited to the data illustrated in the drawings.

[0125] Components of the system are shown in the drawings. The illustrated components conceptually illustrate the functions 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 the illustrated form. All or part of the system may be functionally or physically integrated or distributed depending on various loads and usage conditions.

[0126] (Terms that represent components) The term "module," "section," "-er suffix," or "-or suffix" can be read as "unit," "means," "circuit," etc. For example, a communication module, a control module, and a storage module can be read as a communication unit, a control unit, and a storage unit, respectively.

[0127] (Configuration of control unit) The configuration of control unit 120 shown in Fig. 9 is illustrative, and data processing described with respect to a particular unit may not necessarily be performed by that particular unit. For example, identification unit 122 may perform the data processing described with respect to request unit 123. Furthermore, control unit 120 may include other units not shown in Fig. 9. The other units may perform the data processing described with respect to control unit 120.

[0128] (Data Processing Device) The data processing device described for the control unit 120 is not limited to the specific hardware described above, and may be, for example, various types of 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). [Explanation of symbols]

[0129] 1 Environment 100 hosts 110 Communications Department 120 control section 121 Fencing Club 122 Specific part 123 Request part 124 Verification Department 125 Notification Department 126 Restoration Department 130 Storage section 200 Network 300 Control Server

Claims

1. 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 completion of the power operation; a determination unit that determines whether the power state of the backup node is powered on or powered off; 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 power off; A system for accelerating failure recovery.

2. The power operation is STONITH (Shoot The Other Node In The Head). The system for accelerating failure recovery according to claim 1 .

3. The fencing action of the STONITH is stop The system for accelerating failure recovery according to claim 2 .

4. a confirmation unit for confirming the normality of a service or process of the standby node The system for accelerating failure recovery according to claim 1 .

5. The cluster system further includes an incorporating unit that incorporates the standby node into the cluster when the service or the process is normal.

5. The system for accelerating failure recovery according to claim 4.

6. The system further includes a notification unit that notifies a maintenance person of a maintenance request for the standby node when the service or the process is not normal.

5. The system for accelerating failure recovery according to claim 4.

7. 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 the 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; A method for speeding up failure recovery, including:

8. A failure recovery speed-up program for causing a computer to function as the failure recovery speed-up system according to any one of claims 1 to 6.

Images