JP4703681B2 - Cluster system and takeover node determination method - Google Patents

Description

  The present invention relates to a cluster system composed of a plurality of server computers (nodes). In particular, when an abnormality occurs in a server computer operating as an active system (active system node), The present invention relates to a cluster system and a takeover destination node determination method suitable for determining a node to take over processing (takeover destination node).

  Conventionally, a so-called cluster system is known in which a plurality of server computers (nodes) communicate with each other to cooperate with each other to behave as if they were one machine for a client. According to such a cluster system, distribution of processing and improvement of availability are realized.

  In a cluster system characterized by distributed processing, when the load on a server computer (active node) that processes (provides services) to clients in the system increases, another server computer (standby node) By performing (or sharing) the processing, the load on the active node can be reduced without reducing the processing capacity of the entire system.

  In a cluster system characterized by high availability, when a failure occurs in an active node in the system, the processing is taken over by the standby node. Thus, even if a failure occurs in the active node, the availability can be maintained in the entire system by taking over the processing by the standby node. Here, the failed node is disconnected from the system. For this reason, in the cluster system, it is possible to replace or repair the failed node without stopping the system.

  In the active node of the cluster system, the cluster management unit for managing the cluster configuration in the system includes the status of the active node and the applications operating on the active node (applications for providing services to clients). Monitor status. Based on this monitoring, the cluster management unit of the active node detects an increase in the load on the active node and a failure of the active node.

  When the cluster management unit of the active node detects an increase in the load on the active node or a failure of the active node (for example, an abnormality of an application operating on the active node), another node (standby in the cluster system) In cooperation with the cluster management unit of the system node), the process is taken over to the other node. The standby node that takes over processing from the active node, that is, the takeover destination node, takes over the application information, IP address, shared disk area, etc. that were used to provide services to the client. The processing (service) performed in step 1 is started. Therefore, the client can connect to the takeover destination node with the same IP address without being aware of such takeover.

  In order to reduce the system execution capacity and availability as much as possible, it is important to ensure that the service operates on the takeover destination node, in addition to the mechanism of abnormality detection and immediate takeover to the standby node. It is required to operate comfortably.

  Therefore, in the conventional technique, the takeover destination node is determined as follows.

(1) Take over if there is one standby node (2) If there are multiple standby nodes, determine by considering the following factors 2a) Preset node priority 2b) Application (service ) Dependency Relationships As shown in Patent Document 1, for example, when a plurality of applications are executed in parallel within the same node, the application dependency relationship indicates whether these applications work together. Say relationship. When an application to be taken over interacts with another application running on the standby node, the standby node is not determined as the takeover destination.
Japanese Patent Application Laid-Open No. 2004-133864

  As described above, in the conventional technique, only the static conditions set in advance for each node (server computer) such as the node priority set in advance and the application dependency are determined in determining the takeover destination node. Used. The application condition is only dependency.

  However, a node determined based on such conditions is not always optimal as a takeover destination node. That is, even if the node is determined as the takeover destination node, for example, when a large amount of resources is consumed by executing the inherited application, a shortage of resources occurs, and the execution capability becomes low. It may not work properly. Such a resource consumption state is grasped only when an application to be taken over is actually started on the takeover destination node.

  The present invention has been made in consideration of the above circumstances, and its purpose is that when a failure occurs in the active node, before the processing in the active node is actually taken over to the takeover destination node, the takeover destination node It is an object of the present invention to provide a cluster system and a takeover destination node determination method capable of determining an optimum takeover destination node by evaluating whether or not an application can be operated on a standby node that is a candidate for the above.

According to one aspect of the present invention, a plurality of server computers interconnected by communication paths that provide services to clients by operating a predetermined application when operating as an active node; In the cluster system comprising the storage means shared by the server computers, the plurality of server computers each have cluster management means for managing the cluster configuration of the plurality of server computers by cooperating via the communication path. The cluster management means is a hook means located between the application and the operating system, and when the server computer having the cluster management means is operating as an active node, App used by the running application By hooking the application program interface, the hook means acquires the application program interface information relating to the application program interface including an execution result of the hook application program interface, and stores the application program interface information the acquired in the storage means And an application program interface indicated by application program interface information stored in the storage means when a failure occurs in the active node while the server computer having the cluster management means is operating as a standby node The execution result included in the application program interface information indicates whether the execution result is correct. By determining, based on, and evaluate whether it is possible to run the application on the server computer having the cluster management device, based on the evaluation result, the server computer having the cluster management device, wherein Evaluation means for determining whether to take over the active node that has failed .

  According to the present invention, when an abnormality occurs in an active node where an application is operating, a standby that is a candidate for the takeover destination node before processing in the active node is actually taken over by the takeover destination node. It is evaluated whether the application can be operated on the system node, and the standby system node evaluated to be operable is determined as the takeover destination node. For this reason, according to the present invention, it is possible to reduce the occurrence of a failure due to an application execution failure.

Embodiments of the present invention will be described below with reference to the drawings.
[First Embodiment]
FIG. 1 is a block diagram showing a configuration of a cluster system according to the first embodiment of the present invention.

  The cluster system shown in FIG. 1 includes three or more server computers, for example, three server computers (hereinafter referred to as nodes) 10-1, 10-2 and 10-3. In the example of FIG. 1, it is assumed that the node 10-1 operates as an active node and the nodes 10-2 and 10-3 operate as standby nodes. The nodes 10-1 to 10-3 are interconnected by a communication path 20 such as a network.

  In the nodes 10-1 to 10-3, operating systems (OS) 11-1 to 11-3 operate, respectively. In the nodes 10-1 to 10-3, applications (application programs) 12-1 to 12-3 operate when the nodes 10-1 to 10-3 are active nodes. The applications 12-1 to 12-3 are executed in the nodes 10-1 to 10-3 in order for the nodes 10-1 to 10-3 to provide specific services to the clients. Therefore, in the example of FIG. 1, among the applications 12-1 to 12-3 on the nodes 10-1 to 10-3, only the application 12-1 on the active node 10-1 is operating, and the standby system Applications 12-2 and 12-3 on nodes 10-2 and 10-3 are stopped. The services (service types) provided by executing the applications 12-1 to 12-3 are the same.

  The nodes 10-1 to 10-3 include cluster management units 13-1 to 13-3 and application program interface information storage units (hereinafter referred to as API information storage units) 14-1 to 14-3, respectively. In the first embodiment, the cluster management units 13-1 to 13-3 manage the cluster configuration of the nodes 10-1 to 10-3 by cooperating with each other via the communication path 20. The cluster management unit 13-i of the node 10-i (i = 1, 2, 3) is a software called cluster software stored in a storage medium such as a disk by a CPU (not shown) in the node 10-i. It is assumed that the program is realized by, for example, reading the program into the main memory in the node 10-i and executing it.

  FIG. 2 is a block diagram showing the configuration of the node 10-i (i = 1, 2, 3) (particularly the configuration of the cluster management unit 13-i in the node 10-i). The cluster management unit 13-i includes a cluster control unit 131, an application control unit (hereinafter referred to as an application control unit) 132, a monitoring unit 133, an application program interface hook unit (hereinafter referred to as an API hook unit) 134, and an evaluation unit 135. including.

  The cluster control unit 131 controls the cluster configuration of the nodes 10-1 to 10-3 in the cluster system by controlling the application control unit 132, the monitoring unit 133, the API hook unit 134, and the evaluation unit 135. The cluster control unit 131 detects a failure of the other node by communicating with the cluster control unit 131 of the other node via the communication path 20. This communication for detecting a node failure between the cluster control units 131 is called heartbeat communication.

The application control unit 132 controls the start / stop of the application 12-i under the control of the cluster management unit 13-1.
The monitoring unit 133 detects an abnormality of the application 12-i by monitoring the state of the application 12-i. The monitoring unit 133 can be included in the cluster control unit 131.

  The API hook unit 134 is logically positioned between the application 12-i and the OS 11-i, for example. The API hook unit 134 is configured to hook an API used by the application 12-i when the node 10-i is an active node. In the first embodiment, the API is a function (system function) and is prepared in advance in the OS 11-i. The API hook unit 134 stores information related to the API hooked by itself (hereinafter referred to as API information) in the API information storage unit 14-1 in chronological order. The API information is passed to the function name (API) hooked by the API hook unit 134 and an argument (OS11-i) that is an input value to be passed to the function (that is, to be used for execution of the function). Argument) and a return value that is an output value (output value from the OS 11-i) as a result of execution of the function.

  API information stored in the API information storage unit 14-i, that is, when the node 10-i is an active node, API information (application 12-i acquired by the API hook unit 134 in the node 10-i). API information including the function name of the function used by the node 10-i is transferred by the cluster control unit 131 in the node 10-i to the cluster control units of all other nodes (that is, standby nodes) constituting the cluster system. . The transferred API information is stored in the API information storage unit of the standby node.

The evaluation unit 135 in the node 10-i indicates the API information stored in the API information storage unit 14-i when an abnormality of the active node is detected and the node 10-i is a standby node. By executing a function (API), it is configured to evaluate whether the node 10-i can be a takeover destination node. In the first embodiment, a node that can be a takeover destination node is a node capable of operating an application.

  The above-described evaluation mechanism by the evaluation unit 135 is as follows. The evaluation unit 135 executes the function indicated by the API information stored in the API information storage unit 14-i (that is, the function hooked by the API hook unit 134 of the active node) via the OS 11-i. The functions executed by the evaluation unit 135 in the first embodiment are not all the functions indicated by the API information stored in the API information storage unit 14-i, but, for example, a frequently used function or a large amount of resources It is assumed that the function is limited to a function (API) that has a large influence on the operation of the application 12-i, such as a function consumed by the application. Therefore, the API hook unit 134 may be configured to selectively hook only such a function. Examples of functions that consume a large amount of resources include a memory allocation function (for example, a malloc function, a realloc function) and a thread creation function (CreateThread function).

  The evaluation unit 135 evaluates whether or not the application 12-i can be operated on the node 10-i depending on whether the value (return value) returned from the OS 11-i by executing the function is correct. The evaluation result of the evaluation unit 135 is notified to the cluster control unit 131. The cluster control unit 131 of the standby node notifies the determination result of the evaluation unit 135 to each other. Thereby, the evaluation unit 135 in each standby node determines which standby node is optimal as the takeover destination node based on the evaluation result of the evaluation unit 135 in each standby node. Note that, unlike the first embodiment, when there is one standby node, if the application can operate on that single standby node, the node is determined as the takeover destination node.

  Next, with respect to the operation of the first embodiment, as in the example of FIG. 1, the node 10-1 operates as an active node and the nodes 10-2 and 10-3 operate as standby nodes. Will be described as an example.

<Operation of API hook in active node>
First, the operation of the API hook unit 134 in the active node 10-1 will be described with reference to the flowchart of FIG.

  The API hook unit 134 in the active node 10-1 is an API that is called (called) by the application 12-1 operating on the node 10-1 (here, an API managed by the API hook unit 134). Hook (catch) (steps S1, S2). As a result, the API call from the application 12-1 is prevented from being directly transmitted to the application 12-1. The API hook unit 134 acquires API information including a function name, an argument, and return value (that is, API) information of the function as information on the hooked API (function) (step S3).

  The API hook unit 134 stores the acquired API information in the API information storage unit 14-1 (step S4). The API hook unit 134 causes the cluster control unit 131 in the active node 10-1 to transfer the acquired API information to the standby nodes 10-2 and 10-3 (step S5).

  The API information transferred to the standby nodes 10-2 and 10-3 by the cluster controller 131 in the active node 10-1 is transferred by the cluster controller 131 in the standby nodes 10-2 and 10-3. They are stored in the API information storage units 14-2 and 14-3, respectively. Thus, the API information acquired by the API hook unit 134 in the active node 10-1 is shared by the active node 10-1 and the standby nodes 10-2 and 10-3. That is, the API information storage units 14-1 to 14-3 logically constitute a shared API information storage unit.

  In the first embodiment, the nodes 10-1 to 10-3 have API information storage units 14-1 to 14-3, respectively, for the convenience of drawing. However, instead of the nodes 10-1 to 10-3 having the API information storage units 14-1 to 14-3, the shared storage devices (storage areas) shared by the nodes 10-1 to 10-3 The API information storage unit (that is, the shared API information storage unit) may be ensured. In this case, the API hook unit 134 of the node 10-1 (active node 10-1) simply stores the API information in the API information storage unit of the shared storage device, and the nodes 10-1 to 10-3 can receive the API information. Can be shared.

Details of the API hook unit 134 in the active node 10-1 will be described with reference to the operation explanatory diagram of FIG.
The application 12-i includes a function table 120 that is a list of function names of functions (API) to be called by the application 12-i. The function table 120 includes a function name of a first function (first API) that the application 12-i should call and a second function (second API) associated with the first function in advance. Holds a list of function name pairs.

  In the example of FIG. 4, the list held in the function table 120 includes a pair of a function name of the first function fun1 () and a function name of the second function fun1 ′ (), and a list of the first function fun2 (). A function name and a function name pair of the second function fun2 ′ () are included. In the OS 11-1, a first function set (first set) including functions fun1 () and fun2 () shown in this list is prepared in advance as an API set. On the other hand, in the API hook unit 134, a second function set including functions fun1 ′ () and fun2 ′ () is prepared in advance as a set of APIs. In the API hook unit 134, the function names of the functions fun1 ′ () and fun2 ′ () are managed in association with the function names of the functions fun1 () and fun2 ().

  Assume that the application 12-1 wants to call the first function fun1 (). In the first embodiment, when the second function (function name) is associated with the first function (function name) to be called by the application 12-1 by the function table 120, the application 12-1 12-i calls the second function. Thus, for example, if the function fun1 () needs to be called, the function fun1 '() is called. The argument used for calling the function fun1 () is used (inherited) as it is for calling the function fun1 '(). This argument is, for example, an integer (INT type) XX.

  As described above, the function fun1 ′ () is prepared in the API hook unit 134 in advance. Therefore, when the function fun1 ′ () associated with the function fun1 () is called by the application 12-1, the API hook unit 134, as shown by the arrow 41 in FIG. Hook the call. As a result, in the API hook unit 134, the function fun1 ′ () is called and executed.

  By executing the function fun1 ′ (), the API hook unit 134 executes a function name of the function fun1 () associated with the function fun1 ′ () and an argument inherited by the function fun1 ′ () (that is, the function fun1 Argument (XX)) which is an input value used to call () is acquired. Then, the API hook unit 134 calls the function fun1 () associated with the function fun1 ′ (), that is, the call of the function fun1 () that should be originally performed by the application 12-1 as indicated by an arrow 42 in FIG. In place of the application 12-1. By this call, the function fun1 () prepared in the OS 11-1 is called, and the acquired argument (XX) is passed to the function fun1 ().

  Then, in the OS 11-1, the called function fun1 () (that is, the function fun1 () called in response to the call from the API hook unit 134) is passed through the API hook unit 134. It is executed based on the argument (XX) from An output value (that is, a return value) from the OS 11-1 (function fun1 ()) indicating the execution result of the function fun1 () by the OS 11-1 is the function fun1 () as shown by an arrow 43 in FIG. Is returned to the API hook unit 134 which is a direct caller of the API. This return value is assumed to be YY of an integer type (INT type), for example.

  The API hook unit 134 obtains a return value (YY) that is returned from the OS 11-1 and is the execution result of the function fun1 () by the OS 11-1. The API hook unit 134 returns the acquired return value (YY) to the application 12-1 as indicated by the arrow 44 in FIG.

  For the application 12-1, the application 12-1 calls the function fun1 () from the application 12-1 to the OS 11-1 as shown by the arrow 45 in FIG. As shown, the return value (YY), which is the execution result of the function fun1 (), is equivalent to the application 12-1 receiving from the OS 11-1 (function fun1 ()).

  The API hook unit 134 acquires the function name of the function fun1 () associated with the fun1 ′ () and the function fun1 acquired when hooking the function fun1 ′ () call from the application 12-1. API information including an argument (XX) to be passed to () and a return value (YY) obtained from the OS 11-1 by calling the function fun1 () from the OS 11-1 is shown by an arrow 47 in FIG. Is stored in the API information storage unit 14-1.

  The API hook unit 134 acquires the function name, argument (XX), and return value (YY) of the function fun1 () by hooking the function fun1 () used by the application 12-1. The function name of the function fun1 (), the argument of the function fun1 () (input value related to the execution of the function fun1 ()), and the return value (YY) that is the execution result of the function fun1 () Is equivalent to

  The operation of the API hook unit 134 in the active node 10-1 described above is executed every time the second function associated with the first function is called from the application 12-1. As a result, the API information storage units 14-1 to 14-3 in the nodes 10-1 to 10-3 have the function names and input / output values for each of the first functions used by the application 12-1. API information including an argument and a return value is accumulated.

  Assume that a failure has occurred in the active node 10-1 in such a state. Here, it is assumed that an abnormality has occurred in the application 12-1 in the node 10-1 as a failure of the active node 10-1. When the monitoring unit 133 in the active node 10-1 detects an abnormality in the application 12-1, the monitoring unit 133 notifies the cluster control unit 131 in the node 10-1 to that effect.

  When the cluster control unit 131 in the active node 10-1 is notified of the abnormality of the application 12-1 from the monitoring unit 133, the cluster control unit 131 in the standby nodes 10-2 and 10-3 notifies the fact. To be notified. In response to this notification, the cluster control unit 131 in the standby nodes 10-2 and 10-3 sends the evaluation unit 135 in the nodes 10-2 and 10-3 to the nodes 10-2 and 10-3, respectively. It is requested to evaluate whether it can become a takeover destination node, that is, whether the applications 12-2 and 12-3 can be run.

  When a failure other than an abnormality of the application 12-1 occurs in the active node 10-1, for example, when a hardware failure occurs in the active node 10-1, the cluster control of the active node 10-1 is performed. The unit 131 cannot perform heartbeat communication with the cluster control unit 131 in the standby nodes 10-2 and 10-3. Therefore, the cluster control unit 131 in the standby nodes 10-2 and 10-3 has lost the heartbeat communication with the cluster control unit 131 in the active node 10-1, and the active node 10 -1 failure can be detected.

<Operation of the evaluation unit in the standby node>
When the evaluation unit 135 in the standby nodes 10-2 and 10-3 receives the evaluation request from the cluster control unit 131 in the standby nodes 10-2 and 10-3, the API information storage units 14-2 and 14 respectively. -3 (that is, the logical shared API information storage unit), based on the API information (that is, the API information acquired by the API hook unit 134 in the active node 10-1), By executing the function (API), the requested evaluation of the nodes 10-2 and 10-3 itself is performed.

  The functions executed by the evaluation unit 135 in the first embodiment are not all the functions indicated by the API information stored in the API information storage unit 14-i but, for example, functions that consume a large amount of resources. The function (API) has a great influence on the operation of the application 12-i. Therefore, the API hook unit 134 may be configured to selectively hook only such a function. As functions that consume a large amount of resources, as described above, a memory allocation function, a thread creation function, and the like are known.

Hereinafter, the procedure of the evaluation process by the evaluation unit 135 will be described with reference to the flowchart of FIG. 5 by taking the operation of the evaluation unit 135 in the standby node 10-2 as an example.
First, the evaluation unit 135 selects API information to be executed (specifically, API information including the function name and argument of the function to be executed) from the API information storage unit 14-2 (step S11). Using the function name and argument in the selected API information, the evaluation unit 135 calls the function (API) indicated by the function name (step S12).

  In response to the call by the evaluation unit 135, the OS 11-2 applies the argument used for calling the function to the called function to execute the function. Then, the OS 11-2 (the called function) returns a return value, which is a result of executing the called function, to the evaluation unit 135. As a result, the evaluation unit 135 acquires a return value that is a result of executing the function that it calls (step S13). That is, the evaluation unit 135 acquires a return value that is a result of the execution of the function by executing the function indicated by the function name in the selected API information.

  The evaluation unit 135 determines whether the acquired return value is correct (step S14). The determination in step S14 is performed as follows. First, the obtained return value is compared with the return value in the selected API information. If the two return values are the same, it is determined that the acquired return value is correct. On the other hand, if the two return values are different, it is determined that the acquired return value is incorrect.

  By the way, there are various types of return values. For example, when the return value type is an integer type and can be compared with the return value in the selected API information, the above-described determination method can be applied. However, there are some "type" return values that cannot be compared. Therefore, API information related to a function that returns a “type” return value that cannot be compared may be excluded from the selection target in step S11, for example. Also, in the case of a “type” return value that cannot be compared, it is determined whether the return value is correct depending on whether or not the obtained return value itself can be considered successful in executing the corresponding function. You may make it. For example, a registry operation function “RegOpenKeyEx” returns a handle of the registry. Therefore, in the case of executing the registry operation function, if “handle” is returned as a return value, it may be determined that the return value is correct.

  When the obtained return value is not correct, if it is determined in step S14, the evaluation unit 135 obtains an evaluation result indicating that the operation of the application 12-2 on the standby node 10-2 is not possible. The cluster control unit 131 in the node 10-2 is notified (step S15). Then, the cluster control unit 131 notifies the evaluation result by the evaluation unit 135 to the cluster control unit 131 of the node 10-3 that is another standby node. The cluster control unit 131 in the standby node 10-3 sends the evaluation result notified from the cluster control unit 131 in the standby node 10-2 to the evaluation unit 135 in the node 10-3.

  When executing step S15, the evaluation unit 135 cannot operate the application 12-2 on the standby node 10-2, and determines that the node 10-2 is not suitable as a takeover destination node (step S16). . The determination result of the evaluation unit 135 is notified to the cluster control unit 131 in the standby node 10-2 (step S20).

  On the other hand, when it is determined in step S14 that the acquired return value is correct, the evaluation unit 135 determines whether all API information to be executed has been executed (step S17). If there is API information (unselected API information) to be executed (step S17), the evaluation unit 135 selects the unselected API information (step S11), and performs the processing after step S12. .

  On the other hand, if there is no unselected API information to be executed (step S17), the evaluation unit 135 selects all the API information to be executed and is acquired by executing all the functions indicated by the API information. It is determined that all the return values are correct. In this case, the evaluation unit 135 sends an evaluation result indicating that the application (here, the application 12-2) on the standby node 10-2 can be operated to the cluster control unit 131 in the node 10-2. Notification is made (step S18). Then, the cluster control unit 131 in the standby node 10-2 notifies the evaluation result of the evaluation unit 135 to the cluster control unit 131 of the node 10-3 that is another standby node. The cluster control unit 131 in the standby node 10-3 sends the evaluation result notified from the cluster control unit 131 in the standby node 10-2 to the evaluation unit 135 in the node 10-3.

  In the standby node 10-3, processing similar to that in the standby node 10-2 is performed, and the evaluation result by the evaluation unit 135 in the node 10-3, that is, the application 12-3 is operated on the node 10-3. The cluster control unit 131 in the standby node 10-2 is notified of the evaluation result of whether it is possible. The cluster control unit 131 in the standby node 10-2 notifies the evaluation result of the standby node 10-3 to the evaluation unit 135 in the standby node 10-2.

  When the evaluation unit 135 in the standby node 10-2 executes step S18, based on the evaluation result of each standby node including the node 10-2 (here, the standby nodes 10-2 and 10-3), It is determined (determined) whether the node 10-2 is optimal as a takeover destination node (step S19). If the evaluation results of the standby nodes 10-2 and 10-3 indicate that the application can be operated, the evaluation unit 135 in the standby node 10-2 determines that the node 10-2 Whether the node 10-2 is optimal as a takeover destination node is determined depending on whether the predetermined priority is higher. On the other hand, in the evaluation results of the standby nodes 10-2 and 10-3, when only the evaluation result of the standby node 10-2 indicates that the application can be operated, The evaluation unit 135 determines that the node 10-2 is optimal as the takeover destination node.

  The evaluation unit 135 notifies the determination result in step S19 to the cluster control unit 131 in the standby node 10-2. The cluster control unit 131 in the standby node 10-2 performs control for taking over the processing in the active node 10-1 only when it is determined that the node 10-2 is optimal as the takeover destination node. .

  In the standby node 10-3, the same processing as that of the standby node 10-2 is performed, and the standby nodes including the node 10-3 (in this case, the standby nodes 10-2 and 10-3) are evaluated. Based on the result, it is determined whether the node 10-3 is optimal as the takeover destination node.

  As described above, in the first embodiment, when an abnormality occurs in the active node 10-1 on which the application 12-1 is operating, either the standby node 10-2 or 10-3 takes over. Before actually taking over the processing in the active node 10-1 as a node, evaluate whether the standby nodes 10-2 and 10-3 can operate the applications 12-2 and 12-3. A node evaluated as operable is determined as a takeover destination node. Therefore, according to the first embodiment, it is possible to reduce the occurrence of a failure due to an application execution failure.

  In the first embodiment, a function that consumes a large amount of resources is listed as a function that is executed by the evaluation unit 135, that is, a function that greatly affects the operation of the application 12-i. However, functions that are frequently used can also be cited as functions that have a large influence on the operation of the application 12-i. Such a function with high use frequency can be selected as a function with use frequency exceeding a predetermined threshold value from among the functions indicated by the API information stored in the API information storage unit 14-i, for example.

  In the first embodiment, the evaluation result of the standby node is notified to other standby nodes, and all the standby nodes thereby share the evaluation results. However, if a special storage area for storing the evaluation result of each standby node is secured in the shared storage device shared by the nodes 10-1 to 10-3, the standby node 10- The standby nodes 10-2 and 10-3 can share the respective evaluation results only by the evaluation unit 135 in 2 and 10-3 storing its own evaluation results in the storage area.

  In the first embodiment, a cluster system is assumed in which the active node is one node 10-1 and the standby nodes are two nodes 10-2 and 10-3. However, if N and M are integers larger than 0, a cluster system including N active nodes and M standby nodes may be used. Here, when M is 1, that is, when there is one standby node, as described above, the standby node is based only on its own evaluation result (evaluation result as to whether the application can be operated). What is necessary is just to determine whether it is optimal as a takeover destination node.

[Second Embodiment]
Next, a second embodiment of the present invention will be described with reference to the block diagram of FIG.

  FIG. 6 is a block diagram showing a configuration of the node 10-i (i = 1, 2, 3) applied in the second embodiment. In FIG. 6, the same reference numerals are given to the parts equivalent to those in FIG.

  The configuration of the node 10-i shown in FIG. 6 is that the information collection unit 136 is added to the cluster management unit 13-i in the node 10-i and the collected information storage unit 15 in the node 10-i. It differs from the node 10-i in the first embodiment (configuration of the node 10-i shown in FIG. 2) in that -i is added. Therefore, in the following description, in FIG. 1, it is assumed that the nodes 10-1 to 10-3 have the collection information storage units 15-1 to 15-3, respectively. Further, the function of the evaluation unit 135 in the node 10-i shown in FIG. 6 is partially different from that of the first embodiment.

  The information collection unit 136 in the node 10-i is configured to collect in advance information used when determining the takeover destination node. This information is time-series data of resource consumption when the node 10-i is an active node and the application 12-i is operating normally in the active node 10-i. The information collection unit 136 calculates a statistical value of the resource consumption based on the collected time series data of the resource consumption. Here, to simplify the explanation, it is assumed that the resource consumption is the memory consumption.

  The collection information storage unit 15-i in the node 10-i is used for storing information (resource consumption time-series data and resource consumption statistics) collected by the information collection unit 136 of the active node. It is done.

  In the second embodiment, the evaluation unit 135 in the node 10-i is stored in the API information storage unit 14-i when an abnormality of the active node is detected and the node 10-i is a standby node. The statistical value of the resource consumption collected in the collected information storage unit 15-i by executing the function indicated by the API information (that is, the API information acquired by the API hook unit 134 of the active node) It is determined whether the resource amount indicated by can be secured. Based on this determination result, the evaluation unit 135 in the node 10-i determines whether the node 10-i is a takeover destination node.

  Next, regarding the operation of the second embodiment, as in the first embodiment, the node 10-1 operates as an active node, and the nodes 10-2 and 10-3 operate as standby nodes. A case will be described as an example.

<Operation of information collection unit in active node>
First, the operation of the information collection unit 136 in the active node 10-1 will be described.
The API hook unit 134 in the active node 10-1 hooks an API (function) used by the application 12-1 as in the first embodiment. The information collecting unit 136 in the active node 10-1 is consumed by executing the function hooked by the API hook unit 134 as long as the application 12-1 is operating normally after the application 12-1 is started. Collect the amount of resources that are used. Here, the resource amount consumed by the execution of the function is explicitly shown when the application 12-1 calls the function. For example, a malloc function as a memory allocation function is expressed in the form of “malloc (size)” using an argument that specifies a size (size) to be allocated. From this argument size, it can be recognized that when “malloc (size)” is executed, a memory amount (resource) of size bytes is secured (reserved).

  For example, when the malloc function is hooked by the API hook unit 134, the information collection unit 136 consumes data indicating the memory size to be secured, that is, the argument size of the malloc function, that is, size bytes, from the API hook unit 134. It is acquired as data indicating the amount of memory (resource amount). Each time the information collection unit 136 collects data indicating the amount of memory (memory consumption) consumed by execution of the function hooked by the API hook unit 134, the information collection unit 136 collects the data in the collection information storage unit 15-1 in chronological order. Store.

  The information collecting unit 136 calculates a statistical value of the memory consumption, for example, periodically based on the time series data of the memory consumption collected in the collected information storage unit 15-1. Here, the statistical value of the memory consumption is, for example, the maximum value or the average value of the memory consumption. It is also possible to exclude spike values that exceed a predetermined threshold in the calculation of the average value. Furthermore, as the average value, an average value, a daily average value, or a weekly average value over the entire period from when the application 12-1 is started can be applied.

  When calculating the statistical value of the memory consumption (resource consumption), the information collection unit 136 stores the statistical value in the statistical value area in the collection information storage unit 15-1 as the latest statistical value of the memory consumption. As a result, the contents of the statistical value area are updated to the latest statistical value of memory consumption. At the same time, the information collection unit 136 uses the cluster control unit 131 to obtain the latest statistical value of memory consumption via the cluster control unit 131 of the standby node 10-2 and 10-3. The information is collected by the information collection unit 136 of 10-3.

  The statistics value of the latest transferred memory consumption is collected by the information collection unit 136 of the standby nodes 10-2 and 10-3, and the collected information storage unit 15-2 (i of the standby nodes 10-2 and 10-3). = 2) and 16-3 (i = 3). Thus, the statistical value of the memory consumption acquired by the information collecting unit 136 in the active node 10-1 is shared by the active node 10-1 and the standby nodes 10-2 and 10-3. That is, the collection information storage unit 15-i of each node 10-i (i = 1, 2, 3) logically configures a shared collection information storage unit. Instead of each node 10-i having the collection information storage unit 15-i, a configuration may be adopted in which the collection information storage unit is secured in the shared storage device (storage area thereof).

<Operation of the evaluation unit in the standby node>
Next, it is assumed that a failure has occurred in the active node 10-1 as in the first embodiment. In this case, the evaluation unit 135 in the standby node 10-2 evaluates whether the node 10-2 can operate the application 12-2. Similar evaluation is also performed by the evaluation unit 135 in the standby node 10-3.

Hereinafter, the procedure of the evaluation process performed by the evaluation unit 135 will be described with reference to the flowchart of FIG. 7 taking the operation of the evaluation unit 135 in the standby node 10-2 as an example.
First, the evaluation unit 135 reads a memory consumption statistic value from the collection information storage unit 15-i (i = 2), that is, the collection information storage unit 15-2 (step S21). Next, the evaluation unit 135 selects API information to be executed from the API information storage unit 14-2 (step S22). Here, it is assumed that API information to be executed is API information including a function name of a memory allocation function for allocating a memory area.

  The evaluation unit 135 uses the function name in the selected API information and uses the statistical value of the memory consumption read from the collection information storage unit 15-2 as the argument of the function specified by the function name. Then, the function (memory allocation function) is executed (step S23). Next, the evaluation unit 135 determines whether or not the memory amount having the size indicated by the statistical value (argument) of the memory consumption amount has been secured based on the execution result of the function (step S24).

  If the memory amount of the size indicated by the statistical value cannot be secured (step S24), the evaluation unit 135 performs the same processing as that when the return value is determined to be incorrect in the first embodiment (that is, step Processes similar to S15, S16, and S20) are executed (steps S25, S26, and S30).

On the other hand, if the memory size of the size indicated by the statistical value can be secured (step S24), the evaluation unit 135 executes the same process as when the return value is determined to be correct in the first embodiment. . That is, the evaluation unit 135 determines whether all API information to be executed has been executed (step S27). If there is API information to be executed (unselected API information), the unselected API information is displayed. After selecting (step S22), the processing after step S23 is performed. Note that the fact that the amount of memory of the size indicated by the statistical value can be secured means that the amount of memory necessary for calling and executing the function (API) using the size as an argument can also be secured. To
On the other hand, if there is no unselected API information to be executed (step S27), the evaluation unit 135 performs the same processing as when it is determined that there is no unselected API information to be executed in the first embodiment. (In other words, processing similar to steps S18 to S20) is executed (steps S28 to S30).

  The evaluation unit 135 in the standby node 10-3 performs the same operation as the evaluation unit 135 in the standby node 10-2.

  As a result, when it is determined that only one of the standby nodes 10-2 and 10-3 can secure the memory size of the size indicated by the statistical value, that is, the standby nodes 10-2 and 10-3. If it is determined that the application can be operated only in one of the nodes, that one node is determined as the takeover destination node. If it is determined that both of the standby nodes 10-2 and 10-3 have secured the memory amount of the size indicated by the statistical value, the standby nodes 10-2 and 10-3 are: The node having a higher priority is determined as the takeover destination node.

[Third Embodiment]
Next, a third embodiment of the present invention will be described with reference to the block diagram of FIG.
FIG. 8 is a block diagram showing the configuration of the node 10-i (i = 1, 2, 3) applied in the third embodiment. 8, parts equivalent to those in FIG. 6 are denoted by the same reference numerals.

  The configuration of the node 10-i shown in FIG. 8 is that the cluster management unit 13-i in the node 10-i is not provided with the API hook unit 134 and the information collection unit 136, and the node 10-i The node in the second embodiment is that the information collecting unit 16-i corresponding to the information collecting unit 136 is provided and the API information storage unit 14-i is not provided in the node 10-i. 10-i (the configuration of the node 10-i shown in FIG. 6). Therefore, in the following description, in FIG. 1, while the nodes 10-1 to 10-3 have the collected information storage units 15-1 to 15-3 and the information collection units 16-1 to 16-3, respectively, The parts 14-1 to 14-3 are not included. Further, the function of the evaluation unit 135 in the node 10-i shown in FIG. 8 is partially different from that of the second embodiment.

  In the third embodiment, the information collection unit 16-i in the node 10-i receives time-series data of the resource amount consumed by the application 12-i when the node 10-i is an active node. The information is collected as information used when determining the takeover destination. The information collection unit 16-i calculates a statistical value of the resource consumption amount based on the collected time series data of the resource amount (resource consumption amount) consumed by the application 12-i.

  The collected information storage unit 15-i in the node 10-i is information collected by the information collecting unit of the active node (time series data of the resource amount consumed by the application 12-i and the statistical value of the resource consumption amount). Used to store

  The evaluation unit 135 in the node 10-i detects the resource consumption collected in the collection information storage unit 15-i when an abnormality of the active node is detected and the node 10-i is a standby node. Based on the resource amount indicated by the statistical value and the current free resource amount of the node 10-i, it is evaluated whether the resource amount indicated by the statistical value can be secured. The evaluation unit 135 in the node 10-i determines whether the node 10-i is a takeover destination node based on the evaluation result.

  Next, regarding the operation of the third embodiment, as in the second embodiment, the node 10-1 operates as an active node, and the nodes 10-2 and 10-3 operate as standby nodes. A case will be described as an example.

<Operation of information collection unit in active node>
First, the operation of the information collection unit 16-i (i = 1) in the active node 10-1, that is, the operation of the information collection unit 16-1 will be described.
The information collecting unit 16-1 collects time series data of the amount of resources consumed by the application 12-1 by observing (monitoring) from outside the application 12-i. Such a mechanism for observing the amount of resources consumed by the application 12-i has been conventionally known, and is realized by using a dedicated command or tool.

  The resource amount (first resource amount) consumed by the application 12-1 includes the resource amount (second resource amount) necessary for calling and executing an API (for example, a memory allocation function) by the application 12-1, This is the sum of the resource amount (third resource amount) secured by executing the API (function).

  As described above, in the second embodiment, only data indicating the third resource amount is collected, whereas in the third embodiment, the second resource is added to the data indicating the third resource amount. Data indicating the quantity is also collected. The second resource amount is a stack for holding function arguments, a resource amount consumed by API internal processing, or the like.

  Each time the information collection unit 16-1 collects data indicating the first resource amount, the information collection unit 16-1 stores the data in the collection information storage unit 15-1 in chronological order. Similar to the information collection unit 136 in the second embodiment, the information collection unit 16-1 uses the first resource amount based on the time-series data of the first resource amount collected in the collection information storage unit 15-1. A statistical value of the amount (resource amount consumed by the application 12-1) is calculated periodically, for example.

  When the information collection unit 16-1 calculates the statistical value of the first resource amount, the statistical value in the collection information storage unit 15-1 is used as the latest statistical value of the first resource amount (resource consumption amount). Store in the value area. As a result, the contents of the statistical value area are updated to the latest statistical value of the first resource amount. At the same time, the information collecting unit 16-1 uses the cluster control unit 131 to obtain the latest statistical value of the first resource amount via the cluster control unit 131 of the standby node 10-2 and 10-3. The information collection units 16-2 (i = 2) and 16-3 (i = 3) of 10-2 and 10-3 are transferred. The latest statistics value of the first resource amount transferred is stored in the standby nodes 10-2 and 10-3 by the information collecting units 16-2 and 16-3 of the standby nodes 10-2 and 10-3. The collected information storage units 15-2 (i = 2) and 16-3 (i = 3) are stored. In the following description, it is assumed that the resource amount is the memory amount.

<Operation of the evaluation unit in the standby node>
Next, it is assumed that a failure has occurred in the active node 10-1 as in the second embodiment. In this case, the evaluation unit 135 in the standby node 10-2 evaluates whether the node 10-2 can operate the application 12-2. Similar evaluation is also performed by the evaluation unit 135 in the standby node 10-3.

Hereinafter, the procedure of the evaluation process by the evaluation unit 135 will be described with reference to the flowchart of FIG. 9 taking the operation of the evaluation unit 135 in the standby node 10-2 as an example.
First, the evaluation unit 135 reads the statistical value of the first memory amount (first resource amount) (that is, the statistical value of the memory amount consumed by the application) from the collected information storage unit 15-2 (i = 2). (Step S31). Next, the evaluation unit 135 compares the memory amount (resource amount) indicated by the read statistical value with the current free memory amount (resource amount) of the standby node 10-2 (step S32). Here, as is well known, data indicating the current free memory amount of the standby node 10-2 can be acquired from the OS 11-2 by inquiring of the OS 11-2 (i = 2).

  Based on the result of the comparison, the evaluation unit 135 determines whether the memory amount indicated by the read statistical value can be secured in the standby node 10-2 (step S33).

  The statistical value of the first memory amount collected in the collected information storage unit 15-2 (i = 2) is the latest statistical value. Therefore, the amount of memory indicated by the statistical value is that the standby node 10-2 operates as the takeover destination node and executes the application 12-2 at the present time (that is, when a failure occurs in the active node 10-1). It can be considered that this is the amount of memory required. Therefore, if the evaluation unit 135 in the standby node 10-2 can determine that the amount of memory indicated by the statistical value can be secured in the node 10-2 based on the result of the comparison, It can be determined that the application 12-2 can be operated on the node 10-2.

  Therefore, if it is determined that the memory amount indicated by the statistical value cannot be secured in the standby node 10-2 (step S33), the evaluation unit 135 can secure the memory amount indicated by the argument in the second embodiment. The same processing as that in the case where there is not (that is, processing similar to steps S25, S26, S30) is executed (steps S34, S35, S38).

  On the other hand, if it is determined that the memory amount indicated by the statistical value can be secured in the standby node 10-2 (step S33), the evaluation unit 135 determines the memory amount indicated by the argument in the second embodiment. Can be secured, and the same processing as when it is determined that there is no unselected API information to be executed (that is, processing similar to steps S28 to S30) is executed (steps S36 to S38).

  The evaluation unit 135 in the standby node 10-3 performs the same operation as the evaluation unit 135 in the standby node 10-2.

  As a result, when it is determined that only one of the standby nodes 10-2 and 10-3 can secure a memory amount of the size indicated by the statistical value, that is, the standby nodes 10-2 and 10-3. When it is determined that the application can be operated only in any one of -3, that one node is determined as the takeover destination node. If it is determined that both of the standby nodes 10-2 and 10-3 can secure the memory size indicated by the statistical value, the standby nodes 10-2 and 10-3 Of these, the node with the higher priority is determined as the takeover destination node. In the third embodiment, the optimum takeover destination node can be determined from the standby nodes without hooking the API call from the application.

[Fourth Embodiment]
Next, a fourth embodiment of the present invention will be described with reference to the block diagram of FIG.
FIG. 10 is a block diagram showing the configuration of the node 10-i (i = 1, 2, 3) applied in the fourth embodiment. 10, parts equivalent to those in FIG. 2 are denoted by the same reference numerals.

  The configuration of the node 10-i shown in FIG. 10 is that the cluster management unit 13-i in the node 10-i is provided with an API hook / I / O isolation unit 137 instead of the API hook unit 134. This is different from the node 10-i (configuration of the node 10-i shown in FIG. 2) in the first embodiment. Further, the function of the evaluation unit 135 in the node 10-i shown in FIG. 10 is partially different from that of the first embodiment.

  In the fourth embodiment, the API hook / I / O isolation unit 137 provided in the cluster management unit 13-i in the node 10-i has the same function (API hook) as the API hook unit 134 shown in FIG. In addition to the function), a function (API) called from the application 12-i for evaluation by the evaluation unit 135 is virtually executed on behalf of the evaluation unit 135, so that the application 12-i is normally used. And an input / output (I / O) exchanged between the OS 11-i and the OS 11-i (I / O isolation function). The API hook / I / O isolation unit 137 passes the function called from the application 12-i and the return value to the evaluation unit 135.

  In the fourth embodiment, the evaluation unit 135 calls the function by operating the application 12-i instead of calling (executing) the function stored in the API information storage unit 14-i. (Execute) is executed by the application 12-i itself. That is, the evaluation unit 135 implements calling (execution) of a function stored in the API information storage unit 14-i by operating the application 12-i.

  The evaluation unit 135 associates whether the return value acquired by the API hook / I / O isolation unit 137 in accordance with the function call (execution) by the application 12-1 is correct with the function name of the function. By determining based on the return value stored in the storage unit 14-i, it is evaluated whether the application 12-i can be operated on the node 10-i.

  Next, regarding the operation of the fourth embodiment, as in the example of FIG. 1, the node 10-1 operates as an active node and the nodes 10-2 and 10-3 operate as standby nodes. Will be described as an example.

<Operation of API hook / I / O isolation unit in active node>
The API hook / I / O isolation unit 137 in the active node 10-1 operates according to the procedure shown in the flowchart of FIG. 3 in the same manner as the API hook unit 134 in the first embodiment. That is, the API hook / I / O isolation unit 137 hooks an API (function) called by the application 12-1. However, in the fourth embodiment, the evaluation unit 135 in the standby nodes 10-2 and 10-3 does not directly execute the API hooked by the API hook / I / O isolation unit 137. Therefore, the API hook / I / O isolation unit 137 does not need to acquire an argument. In other words, in the fourth embodiment, the API hook / I / O isolation unit 137 acquires the function name and return value of the function called by the application 12-1. The acquired API information including the function name and the return value is stored in chronological order in the API information storage units 14-1 to 14-3 (that is, the shared API information storage unit) of the nodes 10-1 to 10-3. .

<Operation of Evaluation Unit and API Hook / I / O Isolation Unit in Standby Node>
Next, it is assumed that the evaluation unit 135 in the standby nodes 10-2 and 10-3 is activated as a result of the failure in the active node 10-1. Thus, the evaluation unit 135 in the standby nodes 10-2 and 10-3 evaluates whether the applications 12-2 and 12-3 can be operated in the nodes 10-2 and 10-3, respectively. .

  The operations of the evaluation unit 135 and the API hook / I / O isolation unit 137 will be described below with reference to the operations of the evaluation unit 135 and the API hook / I / O isolation unit 137 in the standby node 10-2 as an example. This will be described with reference to an explanatory diagram.

  The evaluation unit 135 in the standby node 10-2 notifies the API hook / I / O isolation unit 137 of the evaluation mode as indicated by an arrow 111 in FIG. The application 12-2 is actually activated. Then, the application 12-2 operates in the same manner as in the active node, and calls an API (function) as necessary.

  The API hook / I / O isolation unit 137 displays an API called (called) by the application 12-2 in the same manner as the API hook unit 134 operating in the active node in the first embodiment in FIG. Hook as shown by arrow 113. In the evaluation mode, the API hook / I / O isolation unit 137 sets the hooked API (function) as follows so that the I / O exchanged between the application 12-2 and the OS 11-2 is isolated. Run virtually as described. Then, the API hook / I / O isolation unit 137 returns a return value as a function execution result to the application 12-2 as indicated by an arrow 114 in FIG.

  The API information related to the API hooked by the API hook / I / O isolation unit 137 (the API hook / I / O isolation unit 137 in the standby node 10-2) is the API in the active node 10-1. When hooked by the hook / I / O isolation unit 137, it is stored in the API information storage units 14-1 to 14-3. Accordingly, the API information storage unit 14-2 stores that the API hook / I / O isolation unit 137 in the standby node 10-2 receiving the notification of the evaluation mode from the evaluation unit 135 executes the hooked API. This is equivalent to the evaluation unit 135 executing the API indicated by the API information being executed using the API hook / I / O isolation unit 137.

  The function hooked by the API hook / I / O isolation unit 137 in the standby node 10-2 may be a special function that involves data transmission to the disk write or network. Therefore, the API hook / I / O isolation unit 137 is configured not to actually execute the function using the OS 11-2 when the function hooked by itself is a special function as described above. Yes. As a result, I / O that is normally exchanged between the application 12-2 and the OS 11-2 is isolated, and data is transmitted to a disk write or network due to execution of the special function as described above. Can be prevented.

  Therefore, the API hook / I / O isolation unit 137 virtually executes a function hooked by itself, and generates a return value as an execution result of the function. The API hook / I / O isolation unit 137 returns the generated return value to the application 12-2 as described above. As a result, the API hook / I / O isolation unit 137 can make the application 12-2 perform the following process by making it appear as if the function (API) called from the application 12-2 has been executed. If the function hooked by the API hook / I / O isolation unit 137 is not the special function, the function may be executed using the OS 11-2.

  When returning a return value to the application 12-2, the API hook / I / O isolation unit 137 indicates the return value and the function name of the executed function as shown by an arrow 115 in FIG. Pass to 135. If the operation of the application 12-2 is normal, the API hook / I / O isolation unit 137 is at least from the start of the application 12-2 until the start of the application 12-2 is completed. The order of the functions hooked by is coincident with the order of the functions indicated by the API information stored in the API information storage unit 14-2 in chronological order. Therefore, if the operation of the application 12-2 is normal, the evaluation unit 135 determines the function number of the function name passed from the API hook / I / O isolation unit 137 by the API hook / I / O isolation unit 137. The return value included in the API information including the function name can be acquired by referring to the API information storage unit 14-1 as indicated by the arrow 116 in FIG. it can.

  Note that the API hook unit 134 in the first embodiment operates only when the node 10-i (i = 1, 2, 3) is an active node instead of the API hook / I / O isolation unit 137. And an API hook / I / O isolation unit that operates only in the case of a standby node.

  The evaluation unit 135 determines whether the return value passed from the API hook / I / O isolation unit 137 is correct by comparing it with the return value acquired from the API information storage unit 14-1.

  The evaluation unit 135 continues the evaluation mode until a predetermined timing comes from the activation of the application 12-2. This timing is, for example, the timing when the activation of the application 12-2 is completed. When this timing arrives, the evaluation unit 135 cancels the evaluation mode. As a result, the API hook / I / O isolation unit 137 stops the hook operation and the execution of the hooked function.

  If all the return values as a result of the execution of the function hooked by the API hook / I / O isolation unit 137 are correct during the evaluation mode, the evaluation unit 135 is the same as step S18 in the first embodiment. Then, the evaluation result indicating that the operation of the application 12-2 on the standby node 10-2 is possible is notified to the cluster control unit 131 in the node 10-2. The evaluation result is notified to the other standby node 10-3 by the cluster control unit 131 in the node 10-2. The evaluation result of the evaluation unit 135 in the standby node 10-3 is also notified to the standby node 10-2.

The evaluation unit 135 in the standby node 10-2 evaluates each standby node including the node 10-2 (here, the standby nodes 10-2 and 10-3), as in the first embodiment. Based on the result, it is determined whether the node 10-2 is optimal as the takeover destination node.
In the standby node 10-3, the same processing as that of the standby node 10-2 is performed, and the standby nodes including the node 10-3 (in this case, the standby nodes 10-2 and 10-3) are evaluated. Based on the result, it is determined whether the node 10-3 is optimal as the takeover destination node.

  As described above, in the fourth embodiment, in the standby nodes 10-2 and 10-3, the applications 12-2 and 12-3 are made to operate normally by actually operating the applications 12-2 and 12-3, respectively. Therefore, it is possible to determine the takeover destination node more accurately than in the first embodiment.

  Note that the present invention is not limited to the first to fourth embodiments as they are, and can be embodied by modifying the components without departing from the scope of the invention in the implementation stage. Various inventions can be formed by appropriately combining a plurality of constituent elements disclosed in the first to fourth embodiments. For example, some components may be deleted from all the components shown in the first to fourth embodiments.

1 is a block diagram showing a configuration of a cluster system according to a first embodiment of the present invention. The block diagram which shows the structure of the node shown by FIG. The flowchart which shows the operation | movement procedure of the API hook part in the active system node in the said 1st Embodiment. The figure for demonstrating operation | movement of the API hook part in the active node in the said 1st Embodiment. The flowchart which shows the operation | movement procedure of the evaluation part in the standby node in the said 1st Embodiment. The block diagram which shows the structure of the node applied in the 2nd Embodiment of this invention. The flowchart which shows the operation | movement procedure of the evaluation part in the standby node in the said 2nd Embodiment. The block diagram which shows the structure of the node applied in the 3rd Embodiment of this invention. The flowchart which shows the operation | movement procedure of the evaluation part in the standby node in the said 3rd Embodiment. The block diagram which shows the structure of the node applied in the 4th Embodiment of this invention. The figure for demonstrating operation | movement of the evaluation part and API hook part in the standby node in the said 4th Embodiment.

Explanation of symbols

  10-1 to 10-3, 10-i ... nodes (server computers), 11-1 to 11-3, 11-i ... OS (operating system), 12-1 to 12-3, 12-i ... applications, 13-1 to 13-3, 13-i ... cluster management unit, 14-1 to 14-3, 14-i ... API (application program interface) information storage unit (storage means), 15-i ... collection information storage unit (Storage means), 16-i, 136 ... information collection unit, 131 ... cluster control unit, 134 ... API hook unit, 135 ... evaluation unit, 137 ... API hook / I / O isolation unit.

Claims (7)

A plurality of server computers interconnected by a communication path for providing a service to a client by operating a predetermined application when operating as an active node, and storage means shared by the plurality of server computers; In a cluster system with
Each of the plurality of server computers has cluster management means for managing the cluster configuration of the plurality of server computers by cooperating via the communication path,
The cluster management means includes
A hook means located between the application and the operating system, and when the server computer having the cluster management means is operating as an active node, the application operating on the active node is used. Hook means for hooking an application program interface, obtaining application program interface information related to the application program interface including an execution result of the hooked application program interface, and storing the obtained application program interface information in the storage means When,
When a failure occurs in the active node while the server computer having the cluster management unit is operating as a standby node, the application program interface indicated by the application program interface information stored in the storage unit is executed. Whether the application can be run on the server computer having the cluster management unit by determining whether the execution result is correct based on the execution result included in the application program interface information. A cluster system comprising: evaluation means for evaluating whether a server computer having the cluster management means is to be a takeover node of the failed active node based on the evaluation result . The evaluation means sets the server computer having the cluster management means as a takeover node of the active node in which the failure has occurred when the application can be operated on the server computer having the cluster management means.
The cluster system according to claim 1. The evaluation unit operates the application for execution of the application program interface indicated by the application program interface information stored in the storage unit,
The hook means hooks an application program interface used by the application operated by the evaluation means and executes the application program interface, thereby performing input / output exchanged between the application and the operating system. Isolating and returning the execution result of the application program interface to the application and passing first application program interface information related to the application program interface including the execution result of the hooked application program interface to the evaluation unit;
The evaluation means stores in the storage means whether the execution result included in the first application program interface information passed from the hook means is the execution result of the evaluation means, and whether the execution result is correct. 2. The cluster system according to claim 1, wherein the determination is based on an execution result included in second application program interface information corresponding to the first application program interface information among the existing application program interface information. The cluster management means collects data indicating the amount of resources consumed by the execution of the application program interface hooked by the hook means when the server computer having the cluster management means is operating as an active node. , Further comprising collection means for storing data indicating the collected resource amount in the storage means,
The evaluation means determines whether the execution result of the application program interface indicated by the application program interface information stored in the storage means is correct, corresponding to the execution result included in the application program interface information. The cluster system according to claim 1, wherein the determination is based on whether or not the resource amount indicated by the collected data stored in the network can be secured. The number of standby nodes exceeds 1,
The evaluation means is another computer operating as the standby node among server computers different from the evaluation result of the evaluation means itself and the first server computer that is the server computer having the evaluation means. 2. The method according to claim 1 , wherein the first server computer is determined to be a takeover node of the active node in which the failure has occurred , based on an evaluation result of an evaluation unit included in the second server computer . The cluster system according to 3 or 4 . The evaluation unit includes an evaluation unit that determines, based on a predetermined priority, whether the server computer having the cluster management unit is a takeover node of the active node in which the failure has occurred.
The cluster system according to claim 4 . A plurality of server computers interconnected by a communication path for providing a service to a client by operating a predetermined application when operating as an active node, and storage means shared by the plurality of server computers; A takeover node determination method for determining a takeover destination node when a failure occurs in the active node,
An active node of the plurality of server computers hooks an application program interface used by the application operating on the active node;
Obtaining application program interface information related to the application program interface including the execution result of the hooked application program interface, and storing the obtained application program interface information in the storage unit by the active node;
When a failure occurs in the active node, the standby node of the plurality of server computers executes an application program interface indicated by the application program interface information stored in the storage unit;
The standby node determines whether the execution result of the application program interface indicated by the application program interface information is correct based on the execution result included in the application program interface information. Evaluating whether it is possible to operate the application, and determining, based on the evaluation result, whether the standby node itself is a takeover node of the active node that has failed. A method for determining a takeover node, characterized in that:

Images