JP7707640B2 - Cluster system, monitoring system, monitoring method, and program - Google Patents

Description

This disclosure relates to a cluster system, a monitoring system, a monitoring method, and a program.

When a company or the like builds an internal network, a cluster system may be used to ensure scalability and availability. The cluster system manages the server devices and the like within the cluster system using predetermined policies or specific parameters. Furthermore, server devices for which availability is not ensured in the cluster system are not subject to management by the cluster system, and the policies applied to the cluster system are not applied. In this way, for server devices that are not subject to management by the cluster system, recovery operations are performed in the event of a failure using a procedure that is different from that used when a failure occurs in a server device or the like within the cluster system.

Patent document 1 discloses a configuration in which multiple computers connected via a network perform distributed processing. The computer disclosed in patent document 1 performs partial order distribution when determining the data output order, thereby ensuring the consistency of the data output from each computer and continuing processing even if a failure occurs in some of the computers.

Patent document 2 discloses a system configuration having two computers that perform distributed processing of multiple functions and a common auxiliary storage device. Patent document 1 discloses a backup operation mode in which, if a failure occurs in one computer, the other computer takes over and operates the functions that were being executed by the failed computer.

JP 2020-187526 A Japanese Patent Application Publication No. 09-244910

When an in-house network or the like includes multiple cluster systems, a server device that is not subject to management by the cluster system may be shared and managed by the multiple cluster systems. In this case, when a failure occurs in a server device, each cluster system executes a recovery operation for the server device, resulting in a problem that the recovery operations overlap or conflict, making it impossible to perform an appropriate recovery operation. When a failure occurs in the computer disclosed in Patent Document 2, the computer takes over the function according to a predetermined procedure, so multiple recovery operations are not performed for the computer where the failure occurred. Therefore, even if the recovery operation at the time of failure disclosed in Patent Document 2 is executed, it cannot solve the problem that an appropriate recovery operation is not performed when a failure occurs in a server device shared and managed by multiple cluster systems.

One of the objectives of the present disclosure is to provide a cluster system, a monitoring system, a monitoring method, and a program that can execute appropriate recovery operations on a server device when a failure occurs in the server device shared by multiple cluster systems.

The cluster system according to the first aspect of the present disclosure includes a management unit that manages the monitoring status of server devices in a plurality of cluster systems and an execution status indicating a first cluster system that executes a recovery operation on the server device when the server device is in an abnormal state; a monitoring unit that monitors whether the server device is in a normal state or an abnormal state, reflects the monitoring result in the monitoring status, and reflects the monitoring result of the server device received from the other cluster systems in the monitoring status; a determination unit that, when the monitoring result of at least one cluster system among the plurality of cluster systems indicates an abnormal state, determines the first cluster system that executes a recovery operation on the server device according to the same determination criterion as the determination criterion used by the other cluster systems that manage the monitoring status, and reflects the determination result in the execution status; and a control unit that determines whether or not to execute a recovery operation on the server device according to the managed execution status.

The monitoring system according to the second aspect of the present disclosure is a monitoring system including a plurality of cluster systems and a server device managed by the plurality of cluster systems, each of which manages the monitoring status of the server device in the plurality of cluster systems and the execution status indicating the first cluster system that executes a recovery operation for the server device when the server device is in an abnormal state, monitors whether the server device is in a normal state or an abnormal state, reflects the monitoring result in the monitoring status, and reflects the monitoring result of the server device received from the other cluster systems in the monitoring status, and when the monitoring result of at least one of the plurality of cluster systems indicates an abnormal state, determines the first cluster system that executes a recovery operation for the server device according to the same judgment criterion as the judgment criterion used by the other cluster systems that manage the monitoring status, reflects the determination result in the execution status, and determines whether to execute a recovery operation for the server device according to the managed execution status.

The monitoring method according to the third aspect of the present disclosure manages the monitoring status of a server device in a plurality of cluster systems and an execution status indicating a first cluster system that executes a recovery operation for the server device when the server device is in an abnormal state, monitors whether the server device is in a normal state or an abnormal state, reflects the monitoring result in the monitoring status, and reflects the monitoring result of the server device received from the other cluster systems in the monitoring status, and when the monitoring result of at least one of the plurality of cluster systems indicates an abnormal state, determines the first cluster system that executes a recovery operation for the server device according to the same judgment criterion as the judgment criterion used by the other cluster systems that manage the monitoring status, reflects the determination result in the execution status, and determines whether to execute a recovery operation for the server device according to the managed execution status.

The program according to the fourth aspect of the present disclosure causes a computer to manage the monitoring status of server devices in a plurality of cluster systems and the execution status indicating a first cluster system that executes a recovery operation for the server device when the server device is in an abnormal state, monitor whether the server device is in a normal state or an abnormal state, reflect the monitoring result in the monitoring status, and reflect the monitoring result of the server device received from the other cluster systems in the monitoring status, and when the monitoring result of at least one cluster system among the plurality of cluster systems indicates an abnormal state, determine the first cluster system that executes a recovery operation for the server device according to the same judgment criterion as the judgment criterion used by the other cluster system that manages the monitoring status, reflect the determination result in the execution status, and determine whether or not to execute a recovery operation for the server device according to the managed execution status.

The present disclosure provides a cluster system, a monitoring system, a monitoring method, and a program that can perform appropriate recovery operations on a server device when a failure occurs in the server device shared by multiple cluster systems.

FIG. 1 is a configuration diagram of a cluster system according to a first embodiment. FIG. 11 is a configuration diagram of a monitoring system according to a second embodiment. FIG. 11 is a diagram showing a monitoring map according to the second embodiment; FIG. 11 is a diagram for explaining values that are set in the monitoring status of the monitoring map according to the second embodiment. FIG. 11 is a diagram for explaining values that are set in the execution state of a monitoring map according to the second embodiment. FIG. 11 is a diagram showing a flow of execution processing of a recovery operation according to the second embodiment; FIG. 11 is a diagram showing a flow of execution processing of a recovery operation according to the second embodiment; FIG. 11 is a diagram showing the transition of values set in a monitoring map according to the second embodiment; FIG. 11 is a diagram showing the transition of values set in a monitoring map according to the second embodiment; FIG. 11 is a diagram showing a flow of execution processing of a recovery operation according to the second embodiment; FIG. 11 is a diagram showing a flow of execution processing of a recovery operation according to the second embodiment; FIG. 11 is a diagram showing the transition of values set in a monitoring map according to the second embodiment; FIG. 2 is a configuration diagram of a cluster system according to each embodiment.

(Embodiment 1)
Hereinafter, an embodiment of the present disclosure will be described with reference to the drawings. A configuration example of a cluster system 10 according to the first embodiment will be described with reference to FIG. 1. The cluster system 10 is a system that realizes flexible scalability or high availability by operating one or more computer devices in cooperation with each other. The cluster system 10 may be a system that operates by multiple computer devices performing distributed processing. Alternatively, the cluster system 10 may be a system having one computer device that performs active operation and a computer device for backing up the computer device that performs active operation. The components of the cluster system 10 described below may be functions that are distributed and executed in multiple computer devices, or may be functions that are executed in one computer device that performs active operation.

A computer device is a device that operates by a processor executing a program stored in a memory. The computer device may be, for example, a server device.

The cluster system 10, which is a computer device or a collection of computer devices, has a management unit 11, a monitoring unit 12, a decision unit 13, and a control unit 14. The components of the cluster system 10, such as the management unit 11, the monitoring unit 12, the decision unit 13, and the control unit 14, may be software or modules that perform processing by a processor executing a program stored in a memory. Alternatively, the components of the cluster system 10 may be hardware, such as a circuit or a chip.

The management unit 11 manages the monitoring status of server devices in the multiple cluster systems and the execution status indicating a first cluster system that executes a recovery operation for the server device when the server device is in an abnormal state. Each cluster system included in the multiple cluster systems may achieve scalability or availability using a policy or system configuration that is different from the other cluster systems. The server device is a computer device that is not subject to the computer devices that are managed to ensure scalability or availability in each cluster system. The server device may be, for example, a DNS (Domain Name System) server device. The server device is managed by each cluster system. In other words, when a failure occurs in a server device, each cluster system detects the failure of the server device, and further, each cluster system executes a recovery operation for the server device.

The monitoring status indicates the monitoring results for each cluster system, and indicates, for example, whether a server device is in a normal or abnormal state. The abnormal state may be, for example, a state in which a fault or failure has occurred in the server device. The recovery action may be, for example, restarting some of the functions, services, or applications possessed by the server device, or may be restarting the server device itself. The execution state indicates, for example, which cluster system will perform a recovery action for a server device in which a fault has occurred.

The management unit 11 may, for example, manage the monitoring status and execution status for each cluster system. Specifically, the management unit 11 may use a database to manage flag information indicating the monitoring status and execution status for each cluster system.

The monitoring unit 12 monitors whether the server device is in a normal or abnormal state, reflects the monitoring results in the monitoring status, and also reflects the monitoring results of the server device received from other cluster systems in the monitoring status.

For example, the monitoring unit 12 may send a message to the server device and determine whether the server device is in a normal or abnormal state depending on whether a response message is received. Alternatively, if the server device is a DNS server device, the monitoring unit 12 may send a virtual host name to the DNS server device and determine whether the server device is in a normal or abnormal state depending on whether address information for the virtual host name is received.

The monitoring unit 12 reflects the monitoring results in the monitoring status of the server devices in the cluster system 10 managed by the management unit 11. Furthermore, the monitoring unit 12 receives monitoring results of the server devices from other cluster systems different from the cluster system 10. In other words, the other cluster systems also monitor the server devices in the same way as the monitoring unit 12. When the monitoring unit 12 receives the monitoring results, it reflects them in the monitoring status of the server devices in the other cluster systems managed by the management unit 11.

The determination unit 13 determines a cluster system that will execute a recovery operation on a server device when the monitoring result of at least one of the multiple cluster systems indicates an abnormal state. The determination unit 13 determines a cluster system that will execute a recovery operation on a server device in an abnormal state according to the same judgment criteria as those used by other cluster systems that manage the monitoring state. When the determination unit 13 determines a cluster system that will execute a recovery operation, it reflects the result of the determination in the execution state managed by the management unit 11.

Each cluster system may use a different method to monitor the server device. As a result, there may be cluster systems that are able to detect an abnormal state of the server device and cluster systems that are unable to detect an abnormal state of the server device.

The judgment criteria are criteria that can uniquely determine the cluster system that will execute the recovery operation. For example, the judgment criteria may define the priority of each cluster system, and the determination unit 13 may determine that the cluster system with the highest priority is the cluster system that will execute the recovery operation. Multiple cluster systems have the same judgment criteria. In other words, multiple cluster systems share the same judgment criteria.

The control unit 14 determines whether or not to perform a recovery operation on the server device according to the execution state. If the execution state indicates that the cluster system 10 is to perform a recovery operation, the control unit 14 performs a recovery operation on the server device. Furthermore, if the execution state indicates that another cluster system is to perform a recovery operation, the control unit 14 does not perform a recovery operation on the server device.

As described above, cluster system 10 manages the monitoring status of server devices in all cluster systems including cluster system 10. As a result, even if cluster system 10 is unable to detect an abnormal state of a server device in cluster system 10, it can know that an abnormal state of a server device has been detected in another cluster system.

Furthermore, cluster system 10 determines the cluster system that will perform recovery operations for a server device in which an abnormal state has been detected, using the same judgment criteria as the other cluster systems. This allows multiple cluster systems, including cluster system 10, to uniquely determine the cluster system that will perform the recovery operations. As a result, it is possible to avoid recovery operations for a server device in an abnormal state being duplicated and performed by multiple cluster systems. In other words, each cluster system can appropriately determine the cluster system that will perform recovery operations for a server device in an abnormal state.

(Embodiment 2)
Next, a configuration example of a monitoring system according to the second embodiment will be described with reference to Fig. 2. The monitoring system in Fig. 2 includes a cluster system 10, a cluster system 20, a cluster system 30, and a shared server device 40. The cluster system 10, the cluster system 20, the cluster system 30, and the shared server device 40 may be included in, for example, a single in-house system.

Cluster system 10, cluster system 20, cluster system 30, and shared server device 40 are connected via a network. The network may be, for example, an IP network. Cluster system 20 and cluster system 30 have the same configuration as cluster system 10. Shared server device 40 is a server device that is not subject to the computer devices managed to ensure scalability or availability in cluster system 10, cluster system 20, and cluster system 30. Shared server device 40 is managed by cluster system 10, cluster system 20, and cluster system 30. Shared server device 40 may be, for example, a DNS server device.

For example, in order to access cluster system 20 or 30, cluster system 10 may obtain address information identifying cluster system 20 or 30 from shared server device 40 operating as a DNS server device. Accessing cluster system 20 may mean accessing any of the computer devices managed within cluster system 20. Alternatively, accessing cluster system 20 may mean accessing a computer device in cluster system 20 that has the function of communicating with other cluster systems.

Next, the monitoring maps managed by cluster system 10, cluster system 20, and cluster system 30 will be described using FIG. 3. In the following, the monitoring map managed by cluster system 10 will be mainly described, but the monitoring maps managed by cluster system 20 and cluster system 30 also have the same configuration as the monitoring map managed by cluster system 10.

Cluster system 10 manages a monitoring map in management unit 11. The monitoring map associates each cluster system with a monitoring state, execution state, and execution order. The numbers set in the cluster system column indicate the identification information of the cluster system, and indicate that cluster system 10, cluster system 20, and cluster system 30 shown in Figure 2 are managed in the monitoring map.

The numbers set in the execution order column indicate the order in which recovery operations are performed. A cluster system set to 1 is the cluster system that has the highest priority for performing recovery operations, and a cluster system set to 3 is the cluster system with the lowest priority.

The numerical value set for the monitoring status will be explained with reference to FIG. 4. The numerical value set for the monitoring status may be referred to as flag information. FIG. 4 shows that there are parameters for normal, paused, and abnormal as the monitoring status. FIG. 4 also shows that the flag indicating normal as the monitoring status is 0, the flag indicating paused is 1, and the flag indicating abnormal is 2. Normal indicates that the shared server device 40 is not in an abnormal state, that is, no fault or malfunction has occurred in the shared server device 40. Paused indicates that monitoring of the shared server device 40 has been temporarily stopped. Abnormal indicates that the shared server device 40 is not normal, that is, a fault or malfunction has occurred in the shared server device 40.

Next, the numerical value set in the execution state will be described with reference to FIG. 5. The numerical value set in the execution state may be referred to as flag information. FIG. 5 shows that there are parameters for the execution state: not executed, preparing to execute, executing, and executed. FIG. 5 also shows that the flag indicating not executed as the execution state is 0, the flag indicating preparing to execute is 1, the flag indicating executing is 2, and the flag indicating executed is 3. Not executed indicates that a recovery operation is not being performed on the shared server device 40, which is in an abnormal state. Preparing to execute indicates that preparations are being made to perform a recovery operation on the shared server device 40, which is in an abnormal state. Executing indicates that a recovery operation is being performed on the shared server device 40, which is in an abnormal state. Executed indicates that a recovery operation has been completed on the shared server device 40, which is in an abnormal state.

Next, the flow of the recovery operation execution process when only the cluster system 10 detects an abnormality in the shared server device 40 will be described using Figures 6 and 7. Furthermore, the transition of values set in the monitoring map will be described using Figure 8. Figure 8 shows that the execution order of the cluster system 10 is 1, the execution order of the cluster system 20 is 2, and the execution order of the cluster system 30 is 3. Furthermore, Figure 8 shows the steps in which the monitoring map is updated in Figures 6 and 7 in association with the flag information of the monitoring map.

First, the cluster system 10 detects that the shared server device 40 is in an abnormal state (S11). For example, the cluster system 10 determines that the shared server device 40 is in an abnormal state when it cannot obtain address information corresponding to the virtual host name from the shared server device 40.

Next, cluster system 10 sends a message to cluster system 20 and cluster system 30 indicating that an abnormal state of shared server device 40 has been detected (S12).

Next, cluster system 10, cluster system 20, and cluster system 30 update the monitoring status in the monitoring map (S13). For example, cluster system 10 updates the monitoring map when it sends a message indicating that an abnormal state has been detected. Cluster system 20 and cluster system 30 update the monitoring map when it receives a message indicating that an abnormal state has been detected. In FIG. 6, cluster system 10, cluster system 20, and cluster system 30 update the monitoring map at the same timing, but the monitoring map does not have to be updated at exactly the same timing. Similarly, in the following description, even if it is shown that the timing of the processes executed in cluster system 10, cluster system 20, and cluster system 30 is the same, the timing does not have to be exactly the same.

Specifically, cluster system 10, cluster system 20, and cluster system 30 set the monitoring status of cluster system 10 to 2, as shown in the step S12 column of the monitoring map in Figure 8.

In addition, in FIG. 6, the cluster system 10 updates the monitoring map after sending the message, but it may also detect an abnormal condition in step S11 and update the monitoring map before sending the message in step S12.

Next, cluster system 10, cluster system 20, and cluster system 30 execute a monitoring process for shared server device 40 (S14). In FIG. 6, an example is described in which only cluster system 10 detects an abnormal state of shared server device 40, so it is assumed that cluster system 20 and cluster system 30 did not detect an abnormal state in step S14.

Next, cluster system 20 transmits a message including the monitoring result to cluster system 10 and cluster system 30 (S15). Furthermore, cluster system 30 transmits a message indicating the monitoring result to cluster system 10 and cluster system 20 (S16). Cluster system 20 and cluster system 30 transmit a message indicating that shared server device 40 is normal. Also, while FIG. 6 shows an example in which cluster system 20 transmits a message in step S15, and then cluster system 30 transmits a message in step S16, the order of steps S15 and S16 may be reversed. Alternatively, steps S15 and S16 may be executed at substantially the same timing.

Next, cluster system 10, cluster system 20, and cluster system 20 update the monitoring status in the monitoring map (S17). Cluster system 10 reflects the monitoring results received from cluster system 20 and cluster system 30 in the monitoring status of the monitoring map. Cluster system 20 reflects the monitoring results in step S14 and the monitoring results received from cluster system 30 in the monitoring status of the monitoring map. Cluster system 30 reflects the monitoring results in step S14 and the monitoring results received from cluster system 20 in the monitoring status of the monitoring map.

Specifically, cluster system 10, cluster system 20, and cluster system 30 have monitoring maps in a state similar to the monitoring state in step S12, as shown in the step S17 column of the monitoring map in Figure 8.

Next, cluster system 10, cluster system 20, and cluster system 30 determine the cluster system that will execute the recovery operation and update the execution state of the monitoring map (S18). Cluster system 10, cluster system 20, and cluster system 30 determine the cluster system that will execute the recovery operation from among the cluster systems that detected the abnormal state. When multiple cluster systems detect an abnormal state of the shared server device 40, cluster system 10, cluster system 20, and cluster system 30 determine the cluster system that will execute the recovery operation according to the execution order. In FIG. 6, only cluster system 10 detected the abnormal state of the shared server device 40. Therefore, cluster system 10, cluster system 20, and cluster system 30 update the execution state of the monitoring map by specifying cluster system 10 as the cluster system that will execute the recovery operation.

Specifically, cluster system 10, cluster system 20, and cluster system 30 set the execution state of cluster system 10 to 1, as shown in the column for step S18 in the monitoring map of FIG. 8. In other words, cluster system 10, cluster system 20, and cluster system 30 consider that cluster system 10 is preparing to execute a recovery operation.

Next, the cluster system 20 transmits a message to the cluster systems 10 and 30 indicating that the monitoring of the shared server device 40 will be temporarily stopped since the recovery operation will not be performed (S19). The cluster system 30 also transmits a message to the cluster systems 10 and 20 indicating that the monitoring of the shared server device 40 will be temporarily stopped (S20). Steps S19 and S20 may be performed in the opposite order, or may be performed at substantially the same timing. When the recovery operation is performed, the shared server device 40 may be restarted. In this case, if a cluster system that does not perform a recovery operation is monitoring the shared server device 40, it may recognize that an abnormal state has occurred in the shared server device 40 and detect the abnormal state of the shared server device 40. Therefore, the cluster system that does not perform a recovery operation can avoid detecting an abnormal state regarding the shared server device 40 during the recovery operation by temporarily stopping monitoring.

Next, cluster system 10, cluster system 20, and cluster system 30 update the monitoring status of cluster system 20 and cluster system 30 in the monitoring map (S21). Specifically, cluster system 10, cluster system 20, and cluster system 30 set the monitoring status of cluster system 20 and cluster system 30 to 1, as shown in the column of step S21 in the monitoring map in FIG. 8.

Next, cluster system 10 sends a message to cluster system 20 and cluster system 30 indicating that recovery operations are to begin (S22).

Next, cluster system 10, cluster system 20, and cluster system 30 update the execution state of cluster system 10 in the monitoring map to running (S23). Specifically, cluster system 10, cluster system 20, and cluster system 30 set the execution state of cluster system 10 to 2, as shown in the column of step S23 of the monitoring map in FIG. 8. Cluster system 10 may also set the execution state of cluster system 10 to 2 before sending a message indicating the start of recovery operation in step S22.

Then, the cluster system 10 executes a recovery operation on the shared server device 40 (S24). For example, the cluster system 10 may restart some of the applications held by the shared server device 40, or may restart the shared server device 40. Next, the cluster system 10 completes the recovery operation on the shared server device 40 (S25).

Next, cluster system 10 sends a message to cluster system 20 and cluster system 30 indicating that the recovery operation for shared server device 40 has been completed (S26).

Next, cluster system 10, cluster system 20, and cluster system 30 update the execution status of cluster system 10 in the monitoring map to "executed" (S27). Specifically, cluster system 10, cluster system 20, and cluster system 30 set the execution status of cluster system 10 to 3, as shown in the column for step S27 in the monitoring map of FIG. 8. Cluster system 10 may also set the execution status of cluster system 10 to 3 before sending a message indicating that the recovery operation has been completed in step S27.

Next, cluster system 10, cluster system 20, and cluster system 30 update the execution status of cluster system 10, cluster system 20, and cluster system 30 in the monitoring map to "executed" (S27). Specifically, cluster system 10, cluster system 20, and cluster system 30 set the execution status of cluster system 10 to 3, as shown in the column for step S27 in the monitoring map of FIG. 8.

Next, cluster system 10, cluster system 20, and cluster system 30 execute monitoring of shared server device 40 (S28). When cluster system 10, cluster system 20, and cluster system 30 determine that shared server device 40 is operating normally, they reset the monitoring status and execution status of the monitoring map (S29). Specifically, cluster system 10, cluster system 20, and cluster system 30 set the monitoring status and execution status to 0, as shown in the column of step S29 of the monitoring map in FIG. 8.

Next, the flow of the recovery operation execution process when cluster system 10 and cluster system 20 detect an abnormal state of shared server device 40 will be described. For example, a case will be described in which cluster system 10 first detects an abnormal state of shared server device 40, and then cluster system 20 explains the abnormal state of shared server device 40.

The flow of recovery operation execution processing when cluster system 10 and cluster system 20 detect an abnormal state of shared server device 40 is the same as in Figures 6 and 7. Here, we will explain the difference in the transition of values set in the monitoring map when cluster system 10 and cluster system 20 detect an abnormal state of shared server device 40 compared to when cluster system 10 detects an abnormal state.

When cluster system 10 and cluster system 20 detect an abnormal state of shared server device 40, steps S1 to S13 in FIG. 6 are the same as when only cluster system 10 detects an abnormal state.

The cluster system 20 detects an abnormal state of the shared server device 40 in step S14 of FIG. 6. Furthermore, in step S15, the cluster system 20 transmits a message to the cluster system 10 and the cluster system 30 indicating that an abnormal state of the shared server device 40 has been detected.

In this case, cluster system 10, cluster system 20, and cluster system 30 set the monitoring status of cluster system 10 and cluster system 20 to 2, as shown in the column for step S17 in FIG. 9.

Next, in step S18, cluster system 10, cluster system 20, and cluster system 30 determine the cluster system that will perform recovery operations on shared server device 40. At the time of step S17, the cluster systems that have detected the abnormal state of shared server device 40 are cluster system 10 and cluster system 20. Also, because cluster system 10 has an execution order set to 1, its execution order priority is higher than that of cluster system 20. Therefore, cluster system 10, cluster system 20, and cluster system 30 update the execution status of the monitoring map for cluster system 10 as the cluster system that will perform recovery operations on shared server device 40.

Specifically, cluster system 10, cluster system 20, and cluster system 30 set the execution state of cluster system 10 to 1, as shown in the column for step S18 in the monitoring map of FIG. 9. In other words, cluster system 10, cluster system 20, and cluster system 30 consider that cluster system 10 is preparing to execute a recovery operation.

Steps S19 and onwards are the same as the processing from step S19 onwards when only the cluster system 10 detects an abnormal state, so detailed explanations will be omitted.

Next, the flow of the recovery operation execution process will be described when the cluster systems 10 and 20 detect an abnormal state of the shared server device 40 and the shared server device 40 does not transition to a normal state during the recovery operation. In this case, the process up to step S28 in Figures 6 and 7 is similar to the process when the cluster systems 10 and 20 detect an abnormal state of the shared server device 40, so a detailed description will be omitted. The process from step S28 onwards will be described below with reference to Figures 10 and 11.

Figure 10 shows the process after step S28 in Figure 7. When the cluster system 10 and the cluster system 20 execute monitoring of the shared server device 40 in step S28, they detect an abnormal state of the shared server device 40 (S31). In other words, the cluster system 10 executes a recovery operation on the shared server device 40, but the abnormal state of the shared server device 40 has not been recovered.

Next, cluster system 10 transmits a message to cluster system 20 and cluster system 30 indicating that it has detected that the shared server device 40 is in an abnormal state (S32). Furthermore, cluster system 20 also transmits a message to cluster system 10 and cluster system 30 indicating that it has detected that the shared server device 40 is in an abnormal state (S33). Furthermore, cluster system 30, which has not detected an abnormal state, may also transmit a monitoring result indicating that it has not detected an abnormal state to cluster system 10 and cluster system 20.

Next, cluster system 10, cluster system 20, and cluster system 30 update the monitoring status of cluster system 10 and cluster system 20 in the monitoring map (S34). Specifically, cluster system 10, cluster system 20, and cluster system 30 update the monitoring map status shown in the column of step S27 in FIG. 9 to the monitoring map status shown in the column of step S34 in FIG. 12. Specifically, cluster system 10, cluster system 20, and cluster system 30 update the monitoring status of cluster system 10 and cluster system 20 in FIG. 12 to 2.

Next, cluster system 10, cluster system 20, and cluster system 30 determine the cluster system that will execute the recovery operation, and update the execution status of the monitoring map (S35). In step S31, cluster system 10 and cluster system 20 detect an abnormal state of shared server device 40. In addition, in the execution status in the column of step S34 in FIG. 12, 3 is set for cluster system 10, indicating that the recovery operation in cluster system 10 has been executed. Therefore, in step S35, cluster system 10, cluster system 20, and cluster system 30 determine that cluster system 20, whose execution order is set to 2, is the cluster system that will execute the recovery operation.

Specifically, cluster system 10, cluster system 20, and cluster system 30 update the execution status of cluster system 20 to 1 in the column of step S35 in FIG. 12.

Next, cluster system 10 transmits a message to cluster system 20 and cluster system 30 indicating that it will temporarily stop monitoring shared server device 40 since it will not perform a recovery operation (S36). Cluster system 30 also transmits a message to cluster system 10 and cluster system 20 indicating that it will temporarily stop monitoring shared server device 40 (S37). Steps S36 and S37 may be performed in the opposite order, or may be performed at substantially the same time.

Next, cluster system 10, cluster system 20, and cluster system 30 update the monitoring status of cluster system 10 and cluster system 30 in the monitoring map (S38). Specifically, cluster system 10, cluster system 20, and cluster system 30 set the monitoring status of cluster system 10 and cluster system 30 to 1, as shown in the column of step S38 in the monitoring map of FIG. 12.

Next, cluster system 20 sends a message to cluster system 10 and cluster system 30 indicating that recovery operations are to begin (S39).

Next, cluster system 10, cluster system 20, and cluster system 30 update the execution state of cluster system 10 in the monitoring map to running (S40). Specifically, cluster system 10, cluster system 20, and cluster system 30 set the execution state of cluster system 20 to 2, as shown in the column of step S40 in the monitoring map of FIG. 12. Cluster system 20 may also set the execution state of cluster system 20 to 2 before sending a message indicating the start of recovery operation in step S39.

Next, the cluster system 20 executes recovery operations for the shared server device 40 (S41). Next, the cluster system 20 completes the recovery operations for the shared server device 40 (S42).

Next, cluster system 20 sends a message to cluster system 10 and cluster system 30 indicating that the recovery operation for shared server device 40 has been completed (S43).

Next, cluster system 10, cluster system 20, and cluster system 30 update the execution state of cluster system 20 in the monitoring map to "executed" (S44). Specifically, cluster system 10, cluster system 20, and cluster system 30 set the execution state of cluster system 20 to 3, as shown in the column of step S44 of the monitoring map in FIG. 12. Cluster system 20 may also set the execution state of cluster system 20 to 3 before sending a message indicating that the recovery operation has been completed in step S43.

Next, cluster system 10, cluster system 20, and cluster system 30 execute monitoring of shared server device 40 (S45). When cluster system 10, cluster system 20, and cluster system 30 determine that shared server device 40 is operating normally, they reset the monitoring status and execution status of the monitoring map (S46). Specifically, cluster system 10, cluster system 20, and cluster system 30 set the monitoring status and execution status to 0, as shown in the column of step S46 of the monitoring map in FIG. 12.

As described above, the monitoring map held by cluster system 10, cluster system 20, and cluster system 30 is the same. Furthermore, the monitoring map defines the order in which recovery operations are performed. Therefore, by using the monitoring map, cluster system 10, cluster system 20, and cluster system 30 can uniquely determine the cluster system that will perform the recovery operation. As a result, cluster system 10, cluster system 20, and cluster system 30 can appropriately perform recovery operations on shared server device 40 without performing duplicate recovery operations on shared server device 40.

Furthermore, a cluster system that does not perform a recovery operation temporarily stops monitoring the shared server device 40. This allows the cluster system that does not perform a recovery operation to avoid detecting a server device that is performing a recovery operation as being in an abnormal state.

In addition, in the monitoring system according to the second embodiment, since each cluster system has a monitoring map, there is no need for a host server device or a leader server device. This makes it possible to eliminate the sequence leading up to the leader determination that is executed in general distributed processing, and reduces the cost of installing a host server device, etc.

Fig. 13 is a block diagram showing an example of the configuration of a cluster system 10 that operates as a single computer device. Referring to Fig. 13, the cluster system 10 includes a network interface 1201, a processor 1202, and a memory 1203. The network interface 1201 may be used to communicate with a network node (e.g., eNB, MME, P-GW, etc.). The network interface 1201 may include, for example, a network interface card (NIC) that complies with the IEEE 802.3 series. Here, eNB stands for evolved Node B, MME stands for Mobility Management Entity, and P-GW stands for Packet Data Network Gateway. IEEE stands for Institute of Electrical and Electronics Engineers.

The processor 1202 reads and executes software (computer programs) from the memory 1203 to perform the processing of the cluster system 10 described using the flowcharts in the above-mentioned embodiment. The processor 1202 may be, for example, a microprocessor, an MPU, or a CPU. The processor 1202 may include multiple processors.

Memory 1203 is composed of a combination of volatile memory and non-volatile memory. Memory 1203 may include storage located away from processor 1202. In this case, processor 1202 may access memory 1203 via an I/O (Input/Output) interface not shown.

In the example of FIG. 13, the memory 1203 is used to store a group of software modules. The processor 1202 can perform the processing of the cluster system 10 described in the above embodiment by reading and executing the group of software modules from the memory 1203.

As explained using FIG. 13, each of the processors in the cluster system 10 in the above-described embodiment executes one or more programs that include a set of instructions for causing a computer to execute the algorithm explained using the drawing.

In the above examples, the program includes instructions (or software code) that, when loaded into a computer, cause the computer to perform one or more functions described in the embodiments. The program may be stored on a non-transitory computer-readable medium or a tangible storage medium. By way of example and not limitation, computer-readable media or tangible storage media include random-access memory (RAM), read-only memory (ROM), flash memory, solid-state drive (SSD) or other memory technology, CD-ROM, digital versatile disc (DVD), Blu-ray® disk or other optical disk storage, magnetic cassette, magnetic tape, magnetic disk storage or other magnetic storage device. The program may be transmitted on a transitory computer-readable medium or communication medium. By way of example and not limitation, the transitory computer-readable medium or communication medium includes electrical, optical, acoustic, or other forms of propagated signals.

Note that this disclosure is not limited to the above-described embodiment, and can be modified as appropriate without departing from the spirit and scope of the present disclosure.

A part or all of the above-described embodiments can be described as, but is not limited to, the following supplementary notes.
(Appendix 1)
a management unit for managing a monitoring state of a server device in a plurality of cluster systems and an execution state indicating a first cluster system that executes a recovery operation for the server device when the server device is in an abnormal state;
a monitoring unit that monitors whether the server device is in a normal state or an abnormal state, reflects the monitoring result in the monitoring state, and reflects the monitoring result of the server device received from another cluster system in the monitoring state;
a determination unit that, when a monitoring result in at least one cluster system among the plurality of cluster systems indicates an abnormal state, determines the first cluster system that will execute a recovery operation for the server device according to a determination criterion that is the same as a determination criterion used by the other cluster systems that manage the monitoring state, and reflects the determination result in the execution state;
a control unit that determines whether or not to execute a recovery operation for the server device according to the managed execution state.
(Appendix 2)
The monitoring unit is
2. The cluster system of claim 1, wherein the cluster system stops monitoring the server device when the execution state indicates that the other cluster system is to perform a recovery action on the server device.
(Appendix 3)
The monitoring unit is
3. The cluster system according to claim 2, further comprising: updating a monitoring status of at least one second cluster system that does not execute a recovery operation on the server device to information indicating that monitoring of the server device is stopped.
(Appendix 4)
The criteria are:
4. The cluster system according to claim 1, further comprising: a priority order for the first cluster system that executes the recovery operation.
(Appendix 5)
The determination unit is
A cluster system according to any one of appendices 1 to 4, further comprising: determining, from among at least one third cluster system among the plurality of cluster systems that detects that the server device is in an abnormal state, the first cluster system that will execute a recovery operation on the server device in accordance with the judgment criteria.
(Appendix 6)
The recovery operation includes:
6. The cluster system according to claim 1, wherein the restart is a restart of an application provided in the server device or a restart of the server device.
(Appendix 7)
The monitoring unit is
7. A cluster system according to any one of claims 1 to 6, wherein when the server device is a DNS server device, it is determined whether the DNS server device is in a normal state or an abnormal state depending on whether address resolution of a virtual host name is successful or not.
(Appendix 8)
A plurality of cluster systems;
a server device managed by the plurality of cluster systems,
Each of the cluster systems includes:
Manage a monitoring state of the server device in the plurality of cluster systems and an execution state indicating a first cluster system that executes a recovery operation for the server device when the server device is in an abnormal state;
monitoring whether the server device is in a normal state or an abnormal state, reflecting the monitoring result in the monitoring state, and reflecting the monitoring result of the server device received from another cluster system in the monitoring state;
When a monitoring result in at least one cluster system among the plurality of cluster systems indicates an abnormal state, determining the first cluster system which will execute a recovery operation for the server device according to a judgment criterion that is the same as a judgment criterion used by the other cluster systems which manage the monitoring state, and reflecting the determination result in the execution state;
A monitoring system that determines whether or not to execute a recovery action on the server device according to the managed execution state.
(Appendix 9)
Each of the cluster systems includes:
9. The monitoring system of claim 8, wherein the monitoring system stops monitoring the server device if the execution state indicates that the other cluster system will perform a recovery action on the server device.
(Appendix 10)
Manage a monitoring state of a server device in a plurality of cluster systems and an execution state indicating a first cluster system that executes a recovery operation on the server device when the server device is in an abnormal state;
monitor whether the server device is in a normal state or an abnormal state;
reflecting the monitoring result in the monitoring status, and reflecting the monitoring result of the server device received from another cluster system in the monitoring status;
determining the first cluster system to execute a recovery operation on the server device according to a criterion that is the same as a criterion used by the other cluster systems that manage the monitoring status when a monitoring result in at least one cluster system among the plurality of cluster systems indicates an abnormal state;
Reflecting the result of the decision in the execution state;
A monitoring method executed in a cluster system, the method determining whether or not to execute a recovery action for the server device according to the managed execution state.
(Appendix 11)
Manage a monitoring state of a server device in a plurality of cluster systems and an execution state indicating a first cluster system that executes a recovery operation on the server device when the server device is in an abnormal state;
monitor whether the server device is in a normal state or an abnormal state;
reflecting the monitoring result in the monitoring status, and reflecting the monitoring result of the server device received from another cluster system in the monitoring status;
determining the first cluster system to execute a recovery operation on the server device according to a criterion that is the same as a criterion used by the other cluster systems that manage the monitoring status when a monitoring result in at least one cluster system among the plurality of cluster systems indicates an abnormal state;
Reflecting the result of the decision in the execution state;
A program that causes a computer to execute the following: determining whether or not to execute a recovery operation for the server device according to the managed execution state.

REFERENCE SIGNS LIST 10 Cluster system 11 Management unit 12 Monitoring unit 13 Determination unit 14 Control unit 20 Cluster system 30 Cluster system 40 Shared server device

Claims (10)

a management unit for managing a monitoring state of a server device in a plurality of cluster systems and an execution state indicating a first cluster system that executes a recovery operation for the server device when the server device is in an abnormal state;
a monitoring unit that monitors whether the server device is in a normal state or an abnormal state, reflects the monitoring result in the monitoring state, and reflects the monitoring result of the server device received from another cluster system in the monitoring state;
a determination unit that, when a monitoring result in at least one cluster system among the plurality of cluster systems indicates an abnormal state, determines the first cluster system that will execute a recovery operation for the server device according to a determination criterion that is the same as a determination criterion used by the other cluster systems that manage the monitoring state, and reflects the determination result in the execution state;
a control unit that determines whether or not to execute a recovery operation for the server device according to the managed execution state. The monitoring unit is
2. The cluster system according to claim 1, wherein when the execution state indicates that the other cluster system is to execute a recovery action on the server device, the cluster system stops monitoring the server device. The monitoring unit is
3. The cluster system according to claim 2, wherein the monitoring status of at least one second cluster system that does not execute a recovery operation for said server device is updated to information indicating that monitoring of said server device is stopped. The criteria are:
4. The cluster system according to claim 1, further comprising: a priority order for the first cluster system for executing the recovery operation. The determination unit is
5. The cluster system according to claim 1 , further comprising: determining, from among at least one first cluster system among the plurality of cluster systems that detects that the server device is in an abnormal state, the first cluster system that will execute a recovery operation on the server device according to the judgment criterion. The recovery operation includes:
6. The cluster system according to claim 1, wherein the restart is a restart of an application provided in the server device, or a restart of the server device. The monitoring unit is
7. A cluster system according to claim 1, wherein when the server device is a DNS server device, it is determined whether the DNS server device is in a normal state or an abnormal state depending on whether address resolution of a virtual host name is successful. A plurality of cluster systems;
a server device managed by the plurality of cluster systems,
Each of the cluster systems includes:
Manage a monitoring state of the server device in the plurality of cluster systems and an execution state indicating a first cluster system that executes a recovery operation for the server device when the server device is in an abnormal state;
monitoring whether the server device is in a normal state or an abnormal state, reflecting the monitoring result in the monitoring state, and reflecting the monitoring result of the server device received from another cluster system in the monitoring state;
When a monitoring result in at least one cluster system among the plurality of cluster systems indicates an abnormal state, determining the first cluster system which will execute a recovery operation for the server device according to a judgment criterion that is the same as a judgment criterion used by the other cluster systems which manage the monitoring state, and reflecting the determination result in the execution state;
A monitoring system that determines whether or not to execute a recovery action on the server device according to the managed execution state. The cluster system
Manage a monitoring state of a server device in a plurality of cluster systems and an execution state indicating a first cluster system that executes a recovery operation on the server device when the server device is in an abnormal state;
monitor whether the server device is in a normal state or an abnormal state;
reflecting the monitoring result in the monitoring status, and reflecting the monitoring result of the server device received from another cluster system in the monitoring status;
determining the first cluster system to execute a recovery operation on the server device according to a criterion that is the same as a criterion used by the other cluster systems that manage the monitoring status when a monitoring result in at least one cluster system among the plurality of cluster systems indicates an abnormal state;
Reflecting the result of the decision in the execution state;
A monitoring method executed in a cluster system, the method determining whether or not to execute a recovery action for the server device according to the managed execution state. Manage a monitoring state of a server device in a plurality of cluster systems and an execution state indicating a first cluster system that executes a recovery operation on the server device when the server device is in an abnormal state;
monitor whether the server device is in a normal state or an abnormal state;
reflecting the monitoring result in the monitoring status, and reflecting the monitoring result of the server device received from another cluster system in the monitoring status;
determining the first cluster system to execute a recovery operation on the server device according to a criterion that is the same as a criterion used by the other cluster systems that manage the monitoring status when a monitoring result in at least one cluster system among the plurality of cluster systems indicates an abnormal state;
Reflecting the result of the decision in the execution state;
A program that causes a computer to execute the following: determining whether or not to execute a recovery operation for the server device according to the managed execution state.