JP4520899B2 - Cluster control method, cluster control program, cluster system, and standby server - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To provide a cluster system in which standby computer cost is held down to the minimum even if business processing is transaction. <P>SOLUTION: An execution server monitoring thread in a standby server periodically monitors an operation state of an execution server (S400). Upon detecting time-out as a result of the monitoring (Y in S401), the thread resets the execution server (S420) and stops load balancing to an IP address of the execution server (S421). Then, the tread recovers transaction of the execution server (S442) and returns to monitoring of the operation state (S400). Then, if normality of the execution server is detected as the result of monitoring (N in S401) and an operation state in an execution server management table is "stop" (Y in S410), the thread starts the load balancing to the execution server (S412) and returns to the monitoring of the operation state (S400). In addition, transaction may be recovered using resource connection information. <P>COPYRIGHT: (C)2006,JPO&amp;NCIPI

Description

  The present invention relates to a cluster control technique for realizing high availability of a computer system.

As a technology for realizing high availability of a computer system, there is a cluster system in which a plurality of computers that operate independently are collectively handled as one computer. The cluster system can be broadly divided into: a scalable cluster system that normally operates using all computers, and that continues to operate when a failure occurs, and a standby cluster that has a standby computer that operates when a failure occurs. There is a system. Further, the standby type cluster system is classified into 1: 1 standby type, 1: 1 mutual standby type, N: 1 standby type, N: M standby type, and the like. The N: 1 standby type is a cluster system including N active computers and one standby computer. The N: 1 standby type can realize high availability of a computer system and scalability of business processing (scalability) while suppressing the cost of a standby computer. The N: M standby type is a cluster system including N active computers and M standby computers (normally, N> M). The N: M standby type inherits the advantages of the N: 1 standby type and can cope with M failures. An example of an N: 1 standby cluster system is disclosed in Patent Document 1.
US Pat. No. 5,852,724 (“FIG. 2” and its description)

However, in the conventional N: 1 standby type, when the business process is a transaction, it is difficult to cope with a double failure of the computer system in a short time. This is because when a failure occurs in one active computer, the standby computer recovers and takes over the interrupted transaction (business process), so the active computer where the failure occurred is normal. This is because the failure of another active computer that occurs next cannot be dealt with unless it becomes ready for operation. Here, a transaction is a unit of processing that cannot be divided even though business processing is composed of a plurality of processes.
On the other hand, the conventional N: M standby type can cope with M failures, but the operational complexity and the cost of the standby computer are problematic as compared with the N: 1 standby type. It was.

  Further, in the conventional N: 1 standby cluster system, the server configuration of the active system and the standby system (type of application program, database structure to be handled, etc.) needs to be uniform. This is because it is necessary for one standby computer to recover the transaction for a plurality of active computers and take over it including the subsequent processing. For this reason, when the server configurations are different in the N active systems, the active systems having the same server configuration must be grouped and one standby system must be prepared for each group, which increases the cost of the standby system. was there.

In other words, it is difficult for a conventional standby cluster system to cope with a double failure of a computer system in a short time while minimizing the cost of a standby computer when the business process is a transaction. There was a problem that there was.

  In view of the above problems, an object of the present invention is to provide means for minimizing the cost of a standby computer even in a cluster system, even when business processing is a transaction.

The present invention is a load distribution device that can communicate with a client and distributes a processing request received from the client;
Receiving the processing request load balancer is distributed, and the executing server to execute the process,
Upon detection of a failure of the execution server, the standby server to recover transactions that execution server, but the networked constructed by torque raster system,
The standby server, for each of the execution server, monitoring the operating state, as well as restore the transaction execution the failed server, a cluster control method for performing degeneration control of the execution server,
The standby server includes, for each execution server, a recovery order pointer that sets a pointer to an execution server that recovers NULL or the next transaction in order to control the recovery order of transactions when a failure occurs,
When the standby server performs processing for a predetermined execution server,
As an initialization process, the recovery sequence pointer of the execution server is set to NULL,
Monitoring the operating state of the execution server at predetermined time intervals;
When detecting a failure of the execution server as a result of the monitoring, resetting the execution server and degenerating;
If there is an execution server that is already recovering a transaction before recovering the transaction, when the recovery order pointer is traced from the recovery execution server, the execution server is first set to the recovery order pointer that is NULL. Setting a pointer to
Next, after the completion of the transaction recovery process is notified from the processing for the other execution server, the recovery of the transaction is started, the transaction of the execution server is recovered, the transaction is recovered, When the recovery sequence pointer of the execution server is not NULL, the completion of the recovery processing is notified to the processing for the execution server indicated by the recovery sequence pointer, NULL is set in the recovery sequence pointer, and the process returns to the monitoring of the operation state;
Detecting normality of the execution server as a result of the monitoring, and when the execution server is degenerated, canceling the degeneration of the execution server and returning to the monitoring of the operating state, Features.
As a result, the transactions of the execution server can be recovered according to the order in which the failure of the execution server occurs.

In this method, the standby server monitors the operating state of the execution server every predetermined time as the processing to be performed for each execution server, recovers the transaction of the execution server in which the failure has occurred, and then performs the processing of the execution server. The monitoring of the operating state of the execution server is continued again. As a result, the standby server recovers the failed execution server transaction from time to time, so that the recovery does not stagnate, so it is possible to avoid interruption of business processing of other execution servers due to incomplete transactions of the execution server. can do.

In this method, when the standby server degenerates the failed execution server, the standby server transmits a message instructing the load balancer to remove the execution server from the configuration list of the execution server. As a result, the standby server that is taking over the failed execution server and its IP address and recovering the transaction (during failover)
Unfair processing requests from the load balancer are eliminated. In addition, when the degeneration of the execution server that has recovered from the failure and can be operated is released, a message instructing to add the execution server to the configuration list of the execution server is transmitted to the load balancer. As a result, a processing request comes from the load balancer to the execution server that is ready to operate, and load balancing is achieved.

  Subsequently, in this method, the standby server acquires the resource connection information of the execution server in which the failure has occurred. Then, the resource is accessed using this resource connection information, and the transaction in progress is recovered. Even if the execution server configuration is not uniform, resource connection information is acquired when the execution server to be processed is switched. Can be recovered.

  The present invention includes a cluster system and a standby server. In addition, “processing” and “processing for an execution server” in “when processing is performed on a predetermined execution server” in the claims are “execution server monitoring of a standby server” in the best mode for carrying out the invention described later. Corresponds to “thread”. Further, the “execution server degeneration” state and “recovery order pointer” in the claims are managed by an “execution server management table” in the best mode for carrying out the invention described later.

  According to the present invention, after the standby server recovers the transaction, the standby server waits again without taking over the business process, so that the cost of the standby system can be suppressed.

Hereinafter, the best mode for carrying out the present invention (hereinafter referred to as “embodiment of the present invention”) will be described in detail with reference to the drawings.

<< First Embodiment >>
(Cluster system configuration and overview)
With reference to FIG. 1, the configuration of the standby cluster system according to the first embodiment will be described. In this standby type cluster system (referred to simply as “cluster system 10” in FIG. 1 and the following), the load distribution apparatus 100 distributes the business processing requests received from the clients 20 to a plurality of execution servers. The same business processing program is deployed on each execution server. The cluster system 10 includes one load distribution apparatus 100 connected to the network segment 110, N execution servers 160 to 162, one standby server 170, and two DB servers 180 connected to the network segment 120. , 181 and. The network segment 110 and the network segment 120 are connected by a network 115. The execution servers 160 to 162 and the standby server 170 are connected via KA (Keep Alive) paths 130 to 132, reset paths 140 to 142, and shared disk devices 150 to 152, respectively. Each of the DB servers 180 and 181 has business DBs 190 and 191 under the control of the execution servers 160 to 162 that are referred to and updated during business processing.

The load balancer 100 receives a business process request from the client 20 connected via the network 30. And the configuration list (not shown) of the execution server held by itself
In FIG. 2, the business process request is distributed to the currently effective execution server. For the distribution, for example, a round robin method is used. The configuration list is updated by an instruction from the load balancer control unit 171 of the standby server 170. Execution server 160
˜162 are servers that execute business processing corresponding to business processing requests distributed from the load balancer 100, and are so-called active systems. When executing business processing, the business DB 190 is referred to and updated via the DB server 180, and the business DB 1 is transmitted via the DB server 181.
91 is referred to and updated. When the business process is a transaction, both business DBs 190 and 191 are updated. Note that numbers such as “Execution Server 1”, “Execution Server 2”, and “Execution Server N” are given numbers as the execution server identifier 501 shown in FIG.
This is to correspond to. The standby server 170 is a server that performs transaction recovery processing when the execution server stops, and is a so-called standby system (standby system). Standby server 1
70 includes a load balancer control unit 171, a failover order control unit 172, and a transaction recovery processing unit 173. The load balancer control unit 171 has a function of controlling the load balancer 100. In particular, the load balancer 100 instructs the load balancer 100 to add or delete an execution server from the configuration list in accordance with the operating state of the execution server. The failover order control means 172 has a function of controlling the transaction recovery order when a double failure occurs. The transaction recovery processing unit 173 has a function of recovering an in-process (incomplete) transaction of the execution server when the execution server is stopped.

The KA paths 130 to 132 are signal lines used by the standby server 170 to monitor the operating state of each execution server. The reset paths 140 to 142 are signal lines used by the standby server 170 to perform reset processing such as a network adapter stop or CPU (Central Processing Unit) reset of each execution server. The shared disk devices 150 to 152 sequentially store the transaction status in each execution server. The state of the stored transaction can be referred to and updated from each execution server and standby server 170.

  In the first embodiment, each business processing program deployed on the execution servers 160 to 162 executes a global transaction with respect to the DB servers 180 and 181, respectively, and the state of the transaction is changed to the shared disk devices 150 to 152, respectively. However, a local transaction may be executed for a single DB, and the shared disk devices 150 to 152 may be realized by the same shared disk device. Further, in the first embodiment, for convenience of explanation, redundant configurations such as a load balancer, a network, a network adapter, and a DB server are not employed, but these redundant configurations may be employed.

Here, an implementation form of each component will be described. Client 20 is a PC (Person
al Computer). Load balancer 1
00 is realized by a PC equipped with load balancing software, dedicated hardware, or the like. The execution servers 160 to 162, the standby server 170, and the DB servers 180 and 181 are realized by so-called server computers. Shared disk devices 150-152
The business DBs 190 and 191 are realized by a storage device such as a hard disk device. Further, the load balancer control unit 171, the failover order control unit 172, and the transaction recovery processing unit 173 are realized by a CPU built in the standby server 170 executing a program stored in a predetermined memory.

(Cluster system processing)
With reference to FIG. 2, the flow of processing of the standby server according to the first embodiment will be described (see FIG. 1 as appropriate). The standby server 170 first initializes the execution server management table 500 shown in FIG. 5 (step S200). Here, the execution server management table 500 is a table that is stored in the standby server 170 and manages the state of the execution server. Details will be described later (see FIG. 5). Next, N execution server monitoring threads respectively corresponding to the execution servers to be monitored by the standby server 170 are executed (step S201). In the first embodiment, in order to monitor the execution server in the standby server 170, a plurality of threads (process division units) corresponding to each execution server are used, but a plurality of threads corresponding to each execution server are used. A process (task) may be used.

  With reference to FIG. 3, the flow of the initialization process of the execution server management table according to the first embodiment will be described. This corresponds to the process of step S200 in FIG. The standby server 170 first initializes all the operating states 504 (see FIG. 5) of the execution server management table 500 to “stop” (step S300). Next, all recovery order pointers 505 (see FIG. 5) in the execution server management table 500 are initialized to NULL (step S301). These initialization processes may be performed by an execution server monitoring thread described later.

  With reference to FIG. 4, the flow of processing of the execution server monitoring thread according to the first embodiment will be described (see FIG. 1 as appropriate). This corresponds to the process of step S201 in FIG. The execution server monitoring thread M corresponding to the execution server M (M = 1 to N) first uses the KA path connected to the execution server M to periodically change the operating state of the execution server M (at predetermined time intervals). To monitor) (step S400). The execution server monitoring thread M determines the operation state of the execution server M to be monitored depending on whether the monitoring of the operation state has timed out (step S401). Here, “the monitoring of the operating state has timed out” means that the execution server monitoring thread M has sent a response request to the execution server M via the KA path, whereas a predetermined timeout time has elapsed. Means that there is no response from the execution server M. In other words, it means that the execution server M is stopped due to a failure.

  If the operating state can be acquired within a predetermined timeout period (the response to the response request is received) (N in step S401), the operating state 504 of the execution server M in the execution server management table 500 shown in FIG. 5 is checked. (Step S410). When the operating state 504 of the execution server M is “stopped” (Y in step S410), the operating state 504 is changed from “stopped” to “operating” (step S411). Then, according to an instruction from the execution server monitoring thread M, the load distribution device control unit 171 starts load distribution to the execution server M (step S412). Specifically, first, the load balancer control unit 171 transmits a message instructing the load balancer 100 to add the execution server M to the configuration list. Next, the load balancer 100 receives the instruction message and adds the execution server M to the configuration list. As a result, the load distribution apparatus 100 distributes the business process to the execution server M, so that load distribution to the execution server M is started. Thereafter, the execution server monitoring thread M again monitors the operating state of the execution server M (step S400). When the operating state 504 of the execution server M is not “stopped”, that is, when it is “operating” (N in step S410), the operating state of the execution server M is monitored again (step S400).

If the execution server monitoring thread M cannot acquire the operation state within the timeout period (Y in step S401), it is determined whether or not the operation state 504 of the execution server M in the execution server management table 500 is “in operation”. Check (step S402). When the operating state 504 is not “operating”, that is, when it is “stopped” (N in step S402).
The operating state of the execution server M is again monitored (step S400). When the operation state 504 is “in operation” (Y in step S402), reset processing such as network adapter stop or CPU reset of the execution server M is performed using the reset path connected to the execution server M (step S402). S420). Next, according to an instruction from the execution server monitoring thread M, the load balancer control unit 171 stops load distribution for the IP address of the execution server M (step S421).

  Specifically, first, the load balancer control unit 171 transmits a message for instructing the load balancer 100 to delete the IP address of the execution server M from the configuration list. Next, the load balancer 100 receives the instruction message and deletes the IP address of the execution server M from the configuration list. As a result, the load distribution apparatus 100 does not distribute the business process to the IP address of the execution server M, so that the load distribution for the IP address of the execution server M is stopped. This is because when the transaction is separately recovered, the standby server 170 takes over (takes over) the IP address of the execution server M, so that the business process corresponding to the new business process request from the client 20 is This is to avoid being distributed from the distribution apparatus 100 to the standby server 170.

Subsequently, the execution server monitoring thread M indicates the operating state 50 of the execution server management table 500.
4 is searched to determine whether or not there is an execution server in the transaction “in recovery” state (
Step S422). When there is an execution server “in recovery” (Y in step S422)
The operating state 504 of the execution server M is changed from “operating” to “standby” (step S4).
30). Next, the recovery order pointer 505 of the execution server in the “recovering” state is sequentially traced, and a pointer to the execution server M is written in the place where NULL is first detected (step S431).
. Then, the execution server monitoring thread M stands by until a notification of completion of transaction recovery processing is received from another execution server monitoring thread (step S432).

The execution server monitoring thread M determines that there is no “recovering” execution server (step S
422 N), or when the completion notification of the transaction recovery process is received (when the wait in step S432 is released), the operation state 504 of the execution server M in the execution server management table 500 is set to “in operation” or “ “Waiting” is changed to “Recovering” (step S440). Then, the IP address of the execution server M is taken over (takeover) (
Step S441). Specifically, a unique IP address is set in advance in the LAN adapter (not shown) of the standby server 170, but the IP address of the execution server M is set as an alias of the IP address. As a result, the standby server 170 can execute, on behalf of the execution server M, business processing requested from another execution server in order to recover the in-process transaction.

Next, the execution server monitoring thread M acquires the status of the transaction stored in the shared disk device from the shared disk device information 503 of the execution server M in the execution server management table 500 and instructs the transaction recovery processing unit 173. As a result, the in-process transaction of the execution server M is recovered (step S442). Specifically, the transaction recovery processing unit 173 recovers a transaction from the load balancer 100 and a transaction from another execution server according to the transaction state of the execution server M.

When recovering a transaction from the load balancer 100, the transaction is completed by committing, or returned to the state before the transaction by performing rollback. For example, it is assumed that the transaction performs process A in which the business DB 190 is updated, and then performs process B in which the business DB 191 is updated. In this case, when the processes A and B are normally completed as the transaction state, the business DB 190 is used to complete the transaction.
And commit to update 191. When the process A or the process B is abnormally terminated, the business DBs 190 and 19 are used to return to the state before the transaction.
Roll back to stop the update of 1 and restore it.

On the other hand, the execution server M may receive a transaction from another execution server instead of from the load distribution apparatus 100. For example, another execution server may branch a global transaction received from the load balancer 100 to the execution server M. If the execution server M stops abnormally while executing the branched transaction, the business process is interrupted. When recovering a branched transaction from such another execution server, the transaction recovery processing unit 173 of the standby server 170 first recovers the transaction to the other execution server related to the branched in-process transaction. Instruct to do. In response to this, the other execution server determines how to settle the branched transaction, and gives an instruction to settle the branched transaction to the standby server 1.
70. Then, the transaction recovery processing unit 173 of the standby server 170 finalizes the transaction according to the instruction received from the other execution server. At this time, the other execution server performs an exchange with the standby server 170 using the IP address of the execution server M taken over in step S441.

As described above, it is possible to avoid interruption of business processing in another execution server due to an in-process transaction of the execution server M. In particular, in the case of a global transaction, since a relatively long transaction timeout value is set, the effect of improving availability due to the recovery processing of an in-process transaction is great.

The execution server monitoring thread M updates the transaction state stored in the shared disk device, and then discards the IP address of the take-over execution server M (step S443). Specifically, the IP address of the execution server M set as an alias in step S441 is removed from the LAN adapter setting of the standby server 170. Next, the operating state 504 of the execution server M in the execution server management table 500 is changed from “being recovered” to “stopped”.
(Step S444). Then, the execution server monitoring thread M checks whether or not the recovery order pointer 505 of the execution server M in the execution server management table 500 is NULL (step S445). In the case of NULL (Y in step S445), the operating state of the execution server M is monitored again (steps S460 and S400). If it is not NULL (N in Step S445), the execution server monitoring thread corresponding to the execution server pointed to by the recovery order pointer 505 is notified of the completion of the transaction recovery processing, and the recovery order pointer 505 is reset to NULL (Step S450). . With this notification of completion of the transaction recovery processing, the notification waiting in step S432 in the execution server monitoring thread that is the notification destination is released. Then, the operating state of the execution server M is monitored again (step S46).
0, S400).

  In the first embodiment, since the same business processing program is deployed on a plurality of execution servers, the cluster system 10 is configured even when multiple failures occur in the execution servers 160 to 162 due to steps S442 to S444. Degenerate and continue business processing.

  The configuration of the execution server management table used by the execution server monitoring thread according to the first embodiment will be described with reference to FIG. The execution server management table 500 includes an execution server identifier 501 that uniquely identifies the execution server, an IP address 502 assigned to the LAN adapter of the execution server, and shared disk device information 503 that is information related to the shared disk device that stores the transaction status. This is a table composed of records composed of an operating state 504 of the execution server and a transaction recovery order pointer 505.

The operating state 504 includes “stopped”, “operating”, “recovering”, and “standby”. "
“Stopped” indicates that the execution server is not yet in a state of performing business processing after power-on or after recovery of a transaction for the occurrence of a failure. “In operation” indicates that the execution server is in a state of performing business processing. “Recovering” indicates standby server 170
Shows a state in which the failure of the execution server is detected and the transaction is recovered. "
“Waiting” indicates a state in which the standby server 170 is waiting for recovery of a transaction of the execution server because a transaction of another execution server is being recovered when a multiple failure of the execution server occurs.

The recovery order pointer 505 stores a pointer to the execution server that recovers the next transaction in order to form a list indicating the order in which transactions are recovered when multiple failures occur in the execution server. The top of the list is an execution server whose operating state 504 is being recovered, and the end of the list is the recovery order pointer 50 for the first time when the list is traced.
An execution server 5 is NULL. According to this, since the transactions are recovered in the order in which the failures occur, it is possible to guarantee the consistency of transaction recovery when a double failure occurs.

<< Second Embodiment >>
Next, the second embodiment will be described in comparison with the first embodiment. FIG. 6 is a diagram illustrating a configuration of a standby cluster system according to the second embodiment. When this configuration is compared with the system configuration of the first embodiment (see FIG. 1), the transaction recovery processing means 173 in FIG. 1 is replaced with the transaction recovery processing means 2 (174). The transaction recovery processing means 2 (174) has a function of recovering the in-process transaction of the execution server when the execution server is stopped, and further, information necessary for accessing the resource to recover the transaction. It also has a function to use.

  FIG. 7 is a diagram illustrating a configuration of an execution server management table according to the second embodiment. When this configuration is compared with the table configuration of the first embodiment (see FIG. 5), resource connection information 506 is added. The resource connection information 506 is information related to the resource to which the execution server is connected, and is information necessary for the standby server to access the resource. The resource is, for example, the DB server 180 or the DB server 181. In this case, the resource connection information 506 is, for example, the DB server IP address, user name, password, database name, and the like. In FIG. 7, one set of resource connection information 506 is expressed as RA and illustrated as RA1, RA2, and RA3. When an in-process transaction spans two or more DB servers or two or more DBs, the resource connection information 506 includes two or more RAs as shown in the records of the execution server 1 and the execution server N. . In addition to the DB server, the resource may be a TP monitor (Transaction Processing Monitor) that implements transaction processing.

  FIG. 8 is a flowchart showing a part of processing of the execution server monitoring thread according to the second embodiment. When this process is compared with the process of the first embodiment (see FIG. 4), step S442 in FIG. 4 is replaced with step S801 and step S802. The execution server monitoring thread M takes over the IP address of the execution server M (step S441), and then acquires the resource configuration information 506 of the execution server M from the execution server management table 510 (step S801). Then, the transaction of the acquired resource configuration information 506 is recovered (step S802).

  More specifically, the resource configuration information 506 and the transaction status acquired from the shared disk device by the shared disk device information 503 in the execution server management table 510 are instructed to the transaction recovery processing means 2 (174) to execute the transaction. The in-process transaction of the server M is recovered. At this time, the transaction recovery processing means 2 (174) accesses the DB server 180 or the DB server 181 according to the resource configuration information 506 instructed from the execution server monitoring thread M, and recovers the transaction from the state of the instructed transaction. . Thereafter, after the state of the recovered transaction is updated, the taken over IP address is discarded (step S443). The processes other than those described above are the same as in the first embodiment.

  According to the above, one standby server refers to the resource connection information of each execution server even if the server configuration such as the types of application programs and the structure of the database to be handled is not uniform for a plurality of execution servers. Thus, transaction recovery can be performed. Since the standby server does not take over the processing of the execution server, the server configuration does not have to be uniform. According to this, since the resource is accessed using the resource connection information, it is not necessary to provide a standby server for each configuration of the execution server, and the cost of the standby system can be suppressed.

Although the embodiment of the present invention has been described above, the program executed by each of the load distribution apparatus and each server shown in FIG. 1 is recorded on a computer-readable recording medium, and the program recorded on this recording medium is recorded. It is assumed that the cluster system according to the embodiment of the present invention is realized by being read and executed by a computer system. Here, the computer system includes software such as an OS (Operating System) and hardware such as peripheral devices.

<< Other embodiments >>
An example of the preferred embodiment of the present invention has been described above, but the present invention is not limited to the above-described embodiment, and can be changed as appropriate without departing from the spirit of the present invention. For example, the following embodiments can be considered.
(1) In the above-described embodiment, the standby server 170 is described so as to use signal lines such as the KA path and the reset path in order to monitor and reset each execution server. It may be realized by a network. According to this, the standby server 17
Since it is not necessary to connect a signal line between 0 and each execution server, the construction cost of the cluster system can be reduced.
(2) In the above-described embodiment, the standby server 170 is described as being configured as a single unit, but a 1: 1 standby configuration may be applied to the standby server. In addition, a plurality of standby servers may be arranged within a cost range that does not cause a problem as a standby system compared to the costs of the active execution server and DB server. According to this, the availability of the standby server can be improved.

It is a figure which shows the structure of the standby type cluster system which concerns on 1st Embodiment. It is a flowchart which shows the flow of a process of the standby server which concerns on 1st Embodiment. It is a flowchart which shows the flow of the initialization process of the execution server management table which concerns on 1st Embodiment. It is a flowchart which shows the flow of a process of the execution server monitoring thread | sled which concerns on 1st Embodiment. It is a figure which shows the structure of the execution server management table which concerns on 1st Embodiment. It is a figure which shows the structure of the standby type cluster system which concerns on 2nd Embodiment. It is a figure which shows the structure of the execution server management table which concerns on 2nd Embodiment. It is a flowchart which shows a part of process of the execution server monitoring thread | sled which concerns on 2nd Embodiment.

Explanation of symbols

10 Cluster system 20 Client 30, 115 Network 100 Load balancer 110, 120 Network segment 130, 131, 132 KA path 140, 141, 142 Reset path 150, 151, 152 Shared disk device 160, 161, 162 Execution server 170 Standby server 171 Load balancer control means 172 Failover order control means 173 Transaction recovery processing means 180, 181 DB server 190, 191 Business DB
506 Resource connection information

Claims (6)

A load balancer that is communicable with a client and distributes processing requests received from the client;
An execution server that receives the processing request distributed by the load balancer and executes the processing;
When a failure of the execution server is detected, a standby server that recovers the transaction of the execution server, and a cluster system configured by network connection,
The standby server is a cluster control method for monitoring the operating state of each execution server, recovering a transaction of the execution server in which a failure has occurred, and performing degeneration control of the execution server,
The standby server includes, for each execution server, a recovery order pointer that sets a pointer to an execution server that recovers NULL or the next transaction in order to control the recovery order of transactions when a failure occurs,
When the standby server performs processing for a predetermined execution server,
As an initialization process, the recovery sequence pointer of the execution server is set to NULL,
Monitoring the operating state of the execution server at predetermined time intervals;
When detecting a failure of the execution server as a result of the monitoring, resetting the execution server and degenerating;
If there is an execution server that is already recovering a transaction before recovering the transaction, when the recovery order pointer is traced from the recovery execution server, the execution server is first set to the recovery order pointer that is NULL. Setting a pointer to
Next, after the completion of the transaction recovery process is notified from the processing for the other execution server, the recovery of the transaction is started, the transaction of the execution server is recovered, the transaction is recovered, When the recovery sequence pointer of the execution server is not NULL, the completion of the recovery processing is notified to the processing for the execution server indicated by the recovery sequence pointer, NULL is set in the recovery sequence pointer, and the process returns to the monitoring of the operation state;
Detecting normality of the execution server as a result of the monitoring, and when the execution server is degenerated, canceling the degeneration of the execution server and returning to the monitoring of the operating state, A featured cluster control method. The load balancer is:
A configuration list of execution servers that distribute the processing requests;
When the standby server performs processing for a predetermined execution server,
When degenerating the execution server, send a message instructing the load balancer to remove the execution server from the configuration list;
The cluster control method according to claim 1, wherein when releasing the degeneration of the execution server, a message instructing the load distribution apparatus to add the execution server to the configuration list is transmitted. The standby server is
Each execution server comprises resource connection information necessary to access a resource to recover a transaction;
When processing for a given execution server,
Obtaining resource connection information of a resource to which the execution server is connected;
Recovering the transaction using the obtained resource connection information;
Furthermore cluster control method according to claim 1 or claim 2, characterized in that to perform. A cluster control program for causing a server computer to execute the cluster control method according to any one of claims 1 to 3 . A load balancer that is communicable with a client and distributes processing requests received from the client;
An execution server that receives the processing request distributed by the load balancer and executes the processing;
A standby server that recovers a transaction of the execution server when a failure of the execution server is detected;
Is a cluster system configured by network connection,
The standby server includes, for each execution server, a recovery order pointer that sets a pointer to an execution server that recovers NULL or the next transaction in order to control the recovery order of transactions when a failure occurs,
When the standby server performs processing for a predetermined execution server,
As an initialization process, the execution order pointer of the execution server is set to NULL,
Monitor the operating state of the execution server at predetermined time intervals,
When a failure of the execution server is detected as a result of the monitoring, the execution server is reset, degenerated,
If there is an execution server that is already recovering a transaction before recovering the transaction, when the recovery order pointer is traced from the recovery execution server, the execution server is first set to the recovery order pointer that is NULL. Set a pointer to
Next, after the completion of the transaction recovery process is notified from the processing for the other execution server, the recovery of the transaction is started, the transaction of the execution server is recovered, the transaction is recovered, When the recovery order pointer of the execution server is not NULL, the processing for the execution server indicated by the recovery order pointer is notified of the completion of the recovery process, the recovery order pointer is set to NULL, and the operation status monitoring is returned to.
A cluster system, wherein normality of the execution server is detected as a result of the monitoring, and when the execution server is degenerated, degeneration of the execution server is canceled and the operation state monitoring is resumed. It is a standby server that receives a processing request received and distributed from a client by a load balancer, is connected to an execution server that executes the processing, and recovers a transaction of the execution server when a failure of the execution server is detected. And
For each execution server, in order to control the recovery order of transactions when a failure occurs, a recovery order pointer that sets a pointer to the execution server that recovers NULL or the next transaction is provided,
When processing for a given execution server,
As an initialization process, the execution order pointer of the execution server is set to NULL,
Monitor the operating state of the execution server at predetermined time intervals,
When a failure of the execution server is detected as a result of the monitoring, the execution server is reset, degenerated,
If there is an execution server that is already recovering a transaction before recovering the transaction, when the recovery order pointer is traced from the recovery execution server, the execution server is first set to the recovery order pointer that is NULL. Set a pointer to
Next, after the completion of the transaction recovery process is notified from the processing for the other execution server, the recovery of the transaction is started, the transaction of the execution server is recovered, the transaction is recovered, When the recovery order pointer of the execution server is not NULL, the processing for the execution server indicated by the recovery order pointer is notified of the completion of the recovery process, the recovery order pointer is set to NULL, and the operation status monitoring is returned to.
A standby server which detects normality of the execution server as a result of the monitoring and releases the degeneration of the execution server and returns to the monitoring of the operating state when the execution server is degenerated.

Images