JP5707355B2 - Hot-standby client-server system - Google Patents

Description

  Embodiments described herein relate to a technology for improving the reliability of an information system, and relate to a client server system having a hot standby configuration.

  As a conventional hot standby method in the client server system, the slave system (client terminal) outputs the same data to the master system (active server) and the standby system (standby server) respectively, and the active server is the client. A device that responds by attaching an index to data is known (for example, Patent Document 1). In this system, the standby server also writes data with the same index as the active server to the buffer, and when the active server goes down, it waits for subsequent data based on the index just before the down received from the client terminal It was a method to respond to the system server.

JP 2010-176511 A

  Provided is a hot standby type client server system which prevents double processing of business by each server and improves response response characteristics.

  One aspect of the embodiment includes a hot standby type client server that includes a master server and a slave server that can communicate with a client terminal via a network, and that causes another server to operate as the master slave server when a failure occurs in one system In the system, the primary server receives and processes the request of the client terminal, transmits the processing data to the slave server, and the slave server transfers the received processing data to the client terminal. The heartbeat monitoring unit that sends and receives heartbeats with other servers and detects the status of other systems, and the business heartbeat that sends and receives business heartbeats when business applications are running and detects the status of other business applications Based on the detection results of the monitoring unit, the heartbeat monitoring unit, and the business heartbeat monitoring unit , And a switching unit for switching to act as master-slave system server for transmitting the reception and processing of the request, processing the data to the client terminal.

It is a block diagram which shows the structure of the client / server type | system | group system provided with the hot standby function of 1st Embodiment. It is a figure explaining the operation | movement when a failure generate | occur | produces in the heartbeat transmission function of a server in the system of FIG. It is a figure explaining the case where a subordinate server switches to a main subordinate server. It is a figure explaining the case where a primary server switches to a master-slave server. It is a table | surface for demonstrating the process based on the combination of the status of a heartbeat message | telegram, and the state of a business heartbeat. It is a flowchart explaining the process regarding transmission of a heartbeat message | telegram. It is a flowchart regarding the process of the monitoring with respect to another system server, and the switch to a master-slave server. It is a setting table for demonstrating communication with the main server in the normal state, a subordinate server, and a client terminal. It is a figure which shows rewriting of the setting table in case a subordinate server switches to a main subordinate server. It is a figure which shows rewriting of the setting table in case the main server switches to a master-slave server. It is a flowchart explaining 2nd Embodiment.

  The outline of the hot standby type client server system of the embodiment will be described below.

  In the conventional hot standby method described above, since the master system and the standby system are asynchronous, there is no guarantee that the data and the index match between the master system (active server) and the standby system (standby server). there were.

  On the other hand, as another conventional hot standby method, a master / slave system is configured with two pairs of servers, and after the master server synchronizes the data received from the client terminal with the slave server, There is a system that guarantees master / slave data by sending a client response. In such a system, each server can send and receive heartbeats as a monitoring method for the master / slave. It was.

  However, in such a system, after the data received from the client terminal is synchronized with the slave, the client response is transmitted on the master, that is, the data flow is from the client terminal ⇒ master server ⇒ slave server ⇒ master. Since the system server ⇒ client terminal, there was a technical problem that response response was slow. In addition, in such a system, if a failure occurs in the heartbeat function, it is impossible to monitor the survival of the other system, and the primary task may be executed on both servers due to server switching processing that is essentially unnecessary. There was a technical problem that there was. In addition, in such a system, if a startup failure occurs on one server, the other server will operate as the master / slave system. There is also a technical problem that it is necessary to temporarily stop the server being used, and that the recovery work becomes complicated.

  In this application, in order to solve the above-described problem, the following configuration is adopted. That is, in a normal (normal) state, the master server receives and processes a request (request message) from the client terminal, transfers the processing data to the slave server, and then makes a client response from the slave server. As a result, the data flow (data path) is changed from client terminal ⇒ master server ⇒ slave server ⇒ client terminal, so that the response response can be improved. Here, by performing the client response on the slave server, the load on the primary server is reduced not only from the viewpoint of the data path but also from the viewpoint of load distribution, so that the responsiveness of the entire system is improved. From the viewpoint of load distribution, it is preferable that the storage server performs the storage process when the process data is stored in the database.

  In this application, in addition to the conventional heartbeat by the monitoring process, the business process itself outputs a heartbeat (hereinafter referred to as “business heartbeat” for distinction), thereby monitoring the business status of the other system. As a result, it is possible to determine the switching to the master-slave server after determining the business status of the other system, and it is possible to prevent double processing of the primary business.

  Furthermore, in this application, it is set as the structure which starts heartbeat monitoring by arbitrary means after server starting. As a result, when a failure (such as a startup failure) before heartbeat monitoring occurs, recovery work such as server restart can be performed without worrying about the operating status of the other server.

  Hereinafter, a more specific configuration of the hot standby type client-server system will be described with reference to the drawings.

(Basic block configuration)
FIG. 1 is a block diagram of a client server system based on a hot standby system according to the first embodiment. The client server system of the present embodiment includes a master server and a slave server that can communicate with the client terminal 40 via the network 100, and when one of the systems fails, a hot server that causes the other server to operate as the master slave system. FIG. 1 shows an example in which a master system and a slave system are configured by two servers, a server 1 and a server 2, for the sake of simplicity.

  The server 1 and the server 2 are connected to the client terminal 40 via the network 100. The connections between the servers 1 and 2 and the client terminal 40 can also be made via a router or the like (not shown). The network 100 can use the Internet network or various dedicated communication networks.

  The server 1 and the server 2 store (install) the same business application, and can perform the same function (business) based on the business application. However, at the time of start-up and normal (normal), one of the main servers that receives and processes the request from the client terminal 40, and the other transfers the processing result data of the main server to the client terminal 40 and stores it in the database 3 Functions as a secondary server.

  More specifically, the primary server receives a request message (hereinafter also referred to as “request message”) from the client terminal 40 that accesses the business application, and sends the request content to the local server (hereinafter also referred to as the local node). By processing the request message and processing result data to the slave server, the data is synchronized with the slave server, and the slave server sends the processing result data on the master server. A client response is made by transferring the data to the client terminal 40, and a data service is provided to the client terminal 40. Further, the slave server stores the series of processing results in the database 3.

  The data stored in the database 3 is used for data recovery when both servers are down, a trail of business contents, and reconciliation between the client terminal side and the server side.

  Also, in this system, when a failure occurs in the business of one server (that is, the primary or secondary server), a process for switching the other system (secondary or primary) server to operate as the primary and secondary server. I do. In other words, the master-slave server is a server of another system that performs business in the degraded mode when a failure occurs in one system, and receives the request from the client terminal 40 described above, processing of the request content in the business application, It is a server that performs a process of transferring the result to the client terminal 40 and a task of storing such a series of processing results in the database 3 (see FIGS. 3 and 4). In this embodiment, the other server without failure changes the setting of the business application of its own node (rewrites the setting table) to switch its own node (own server) to the master / slave server. Details will be described later.

  In the present embodiment, communication between the client terminal 40, the server 1 and the server 2 is performed by transmitting and receiving data using a publish / subscribe architecture. For this reason, the client terminal 40 can transmit data without being aware of the communication destination, and there is no need to perform processing for changing the communication destination by switching the server on the client terminal 40 side.

  The following describes a case where the server 1 is set to operate as a primary server and the server 2 is operated as a slave server in the initial setting unless otherwise specified. In the drawing, the heartbeat is abbreviated as “HB” and the application as “AP”.

  The server 1 includes a heartbeat monitoring unit 11, a business application control unit 12, a business application switching unit 13, and a storage unit 14. Here, the business application control unit 12 includes a monitoring unit 121 and a communication unit 122. Similarly, the server 2 includes a heartbeat monitoring unit 21, a business application control unit 22, a business application switching unit 23, and a storage unit 24. The business application control unit 22 includes a monitoring unit 221 and a communication unit 222. And have. The storage unit 14 and the storage unit 24 store a setting table related to the publish / subscribe architecture described above (see FIGS. 8 to 10), and details of the setting table will be described later.

  As can be seen from FIG. 1, since the functions of each unit are common between the server 1 and the server 2, the following description will mainly focus on the function of the server 1, and description of each unit of the server 2 will be omitted as appropriate.

  The heartbeat monitoring unit 11 transmits the heartbeat of its own node to the heartbeat monitoring unit 21 of the other server at predetermined intervals, and receives the heartbeat from the heartbeat monitoring unit 21 and receives the heartbeat. Is monitored every preset period. Furthermore, in this embodiment, status information related to the business application of the own node is included in the heartbeat, which will be described later. Heartbeat transmission / reception between the heartbeat monitoring unit 11 and the heartbeat monitoring unit 21 is performed using a network segment different from the network 100 connected to the client terminal 40.

  The business application control unit 12 performs various processes associated with the execution of the business application, and performs a different business (business process) depending on the system of the own node (that is, the master / slave / master-slave). The business application control unit 12 includes a monitoring unit 121 and a communication unit 122. Among these, the monitoring unit 121 transmits / receives a business heartbeat different from the above-described heartbeat to / from another server.

  More specifically, when the business application of the own node is started, the monitoring unit 121 sends a message (business heartbeat message) for notifying that the business application is active for each preset period to the other server. Are repeatedly transmitted to the monitoring unit 221. In addition, the monitoring unit 121 receives a business heartbeat message from the other-system monitoring unit 221 for each preset period, and monitors the life and death of the other-system business application. Here, when the business heartbeat message from the monitoring unit 221 of the other server is not received for a predetermined time, the monitoring unit 121 notifies the business application switching unit 13 that the other business heartbeat has been interrupted. The transmission / reception of the business heartbeat message between the monitoring unit 121 and the monitoring unit 221 is performed using a network segment different from the network 100 connected to the client terminal 40.

  As shown in FIG. 1, the business heartbeat and the heartbeat are transmitted and received separately from each other. That is, the business heartbeat is transmitted / received between the monitoring units 121 and 221 as the business heartbeat monitoring unit as part of the business process of the business application, and the heartbeat is transmitted / received between the heartbeat monitoring units 11 and 21 as a function of the monitoring process. Is done. For this reason, the transmission cycle, the transmission timing, and the like can be set separately for the business heartbeat and the heartbeat. This prevents malfunction due to erroneous detection.

  Furthermore, the monitoring unit 121 detects the state of the business application of the own node, and provides the detection result information to the heartbeat monitoring unit 11. In the present embodiment, the monitoring unit 121 provides detection information to that effect when a business application is active, when it is active, and when a business application is stopped due to a failure in its own business. It passes to the beat monitoring unit 11. In detecting the status of the business application, the monitoring unit 121 transmits an operation confirmation signal to the process of the business application corresponding to the business of the local system, and the fault of the local system depending on the presence or absence of a response signal from the business application. The presence or absence of is detected.

  The communication unit 122 communicates with the communication unit 222 of another system server and communicates with the client terminal 40 via the network 100. Further, data storage processing in the external storage device (database 3) is also performed via the communication unit 122. Here, communication between the communication units 122 and 222 is performed using a network segment different from the network 100 connected to the client terminal 40. The communication unit 122 performs different functions, that is, operations as follows, depending on the system of the own node (primary / secondary / primary-subordinate).

  That is, when the local node is a primary server, the communication unit 122 receives a request message from the client terminal 40 that accesses the business application via the network 100 and provides the request message to the local node business application. When processed by the business application, the processed data is transmitted to the slave server together with the request message.

  On the other hand, when the own node is a slave server, the communication unit 122 receives data processed by the business application of the primary server (server 2) from the communication unit 222, and receives the data via the network 100 as a client terminal. 40 to send a response to the request, and further, a process of storing such a series of processing results in the database 3 as synchronized data.

  Further, when the own node is a master-slave server, the communication unit 122 receives a request message from the client terminal 40 that accesses the business application via the network 100 and provides it to the business application of the own node. When processed by the business application, the processed data is transmitted to the client terminal 40 via the network 100 to respond to the request, and further, a process of storing a series of processing result data in the database 3 is performed ( 3 and 4).

  Next, the function of the heartbeat monitoring unit will be described in detail. When the heartbeat monitoring unit 11 acquires detection information about the business application described above from the monitoring unit 121 of the business application control unit 12, the heartbeat monitoring unit 11 sends a heartbeat to a message including status information corresponding to the detection information (hereinafter, “heartbeat”). In the form of “message”) and transmitted to the heartbeat monitoring unit 21 of another system at predetermined intervals.

  When the heartbeat monitoring unit 11 receives the heartbeat message from the heartbeat monitoring unit 21 of the other server, the heartbeat monitoring unit 11 notifies the business application switching unit 13 of the status information included in the message. Furthermore, when the heartbeat monitoring unit 11 does not receive the heartbeat message from the heartbeat monitoring unit 21 of the other system server for a predetermined time, the heartbeat monitoring unit 11 determines that the heartbeat of the other system has been interrupted and sends a heartbeat to the business application switching unit 13. Notify the beat disruption.

  In this system, the status information of the business application included in the heartbeat message includes any one of “STARTING” corresponding to activation, “READY” corresponding to operation, and “ShutDown” corresponding to suspension of the business application. (See FIG. 5).

  The business application switching unit 13 performs processing for switching the own node (own server) to the above-described master-slave server based on the detection results of the heartbeat monitoring unit 11 and the monitoring unit 121. That is, the business application switching unit 13 determines whether or not a failure has occurred in the business of another system (secondary or primary system) server, based on the combination of the detection result of the heartbeat monitoring unit 11 and the detection result of the monitoring unit 121. When it is determined that a failure has occurred, a process for switching the local node to operate as a master-slave server is performed. More specifically, when the heartbeat monitoring unit 11 detects a failure of another server, the business application switching unit 13 checks the detection result of the monitoring unit 121 and the reception of the business heartbeat message is interrupted. In this case, a process of switching the own node to the master / slave server is performed.

(basic action)
Hereinafter, the basic operation of this system when the server 1 is operated as the primary system and the server 2 as the secondary system will be described with reference to flowcharts. Note that the flowcharts of FIGS. 6 and 7 show processes common to the primary and secondary servers.

  In this system, the master server and the slave server are each activated independently, and the business applications in the servers 1 and 2 are activated by powering on the individual servers. In the startup process when the power is turned on, the heartbeat monitoring unit 11 of each server 1 generates a heartbeat message including status information “STARTING” indicating the business state of the own node based on the detection information of the monitoring unit 121 at a predetermined cycle. It transmits to the server 2 of other system (step S1). In step S2, the heartbeat monitoring unit 11 checks whether the start processing of the business application is completed based on the detection information from the monitoring unit 121, and is running (that is, the start of all processes under its own node is completed). Is notified from the monitoring unit 121 (YES in step S2), the status information included in the heartbeat message is changed to “READY” (step S3).

  When the business application is activated on the server 1, the business application control unit 11 starts transmitting a business heartbeat message from the monitoring unit 121. Thereby, the business heartbeat message is repeatedly transmitted from the monitoring unit 121 to the monitoring unit 221 of the other server at a predetermined cycle. The above operation is performed in the same way in the secondary server 2.

  Thereafter, the main server 1 receives a request message from the client terminal 40 that accesses the business application via the network 100 by the communication unit 122, and receives the request content of the local node business application (business application control unit 12 ) To transfer the request message and the processing result data from the communication unit 122 to the slave server 2. When the communication application 222 receives the request message and the processing result data, the business application control unit 22 of the slave server 2 sends a request response from the communication unit 222 to the client terminal 40 via the network 100. As a result, the data service is provided to the client terminal 40. Further, the business application control unit 22 of the slave server 2 stores a series of processing result data including the request message in the database 3 via the communication unit 222. The above operation is performed every time a request message is transmitted from the client terminal 40.

  As described above, the system according to this embodiment does not have a configuration in which a request response is sent from the main server to the client terminal after returning a response to notify the data synchronization from the subordinate server to the main server as in the conventional system. Since the slave server that has received the data processed by the primary server directly sends a request response to the client terminal, it is possible to shorten the time from the reception of the request message to the response to the client terminal. Is improved.

(When a failure occurs in a business application)
During the normal processing described above, the business application control unit 12 and the heartbeat monitoring unit 11 monitor whether or not a failure has occurred in the business processing of the own node based on the detection result of the monitoring unit 121 of the own node (step S4). When the occurrence of a failure is detected from the monitoring unit 121, the business application control unit 12 performs a process of stopping each process of the business application of the own node (step S5). When such processing is completed, the monitoring unit 121 detects the stop of the business application and provides the detection information to the heartbeat monitoring unit 11. The heartbeat monitoring unit 11 that has acquired the detection information changes the status information included in the heartbeat message to “ShutDown” (step S6). Here, when each process of the business application is completely stopped, the business heartbeat message is not transmitted from the monitoring unit 121, and the reception of the business heartbeat message at the other system server is interrupted.

  The above processing is similarly performed in the server 2 which is another node. However, because the contents of the business process are different between the primary server 1 and the secondary server 2, the fault detection target between the monitoring units 121 and 221 when detecting the status of the business application of the own node is , They will be different from each other.

(Processing of the business application switching unit)
Next, processing performed by the business application switching unit will be described in detail with reference to FIG. Here, the business application switching unit 23 of the secondary server 2 will be mainly described.

  The business application switching unit 23 of the server 2 checks whether reception of the heartbeat message at the heartbeat monitoring unit 21 is interrupted (step S11) and whether the status information of the heartbeat message is “ShutDown” (step S12). To do. Here, if the status information in the heartbeat message is “READY”, the business application switching unit 23 repeats steps S11 and S12, and when the heartbeat monitoring unit 21 receives the “ShutDown” heartbeat message, or When the heartbeat monitoring unit 21 can no longer receive a heartbeat message, the process proceeds to step S13 to perform warning processing. This warning process is a process for displaying on the display screen of the own node that an abnormality has occurred in another node. Subsequently, the business application switching unit 23 determines whether the monitoring unit 221 has received a business heartbeat message (step S14) and then switches to the master / slave server after determining the business status of the other system. Judge whether or not.

  In other words, when the business application switching unit 23 is in a “disruption” state in which the business heartbeat message cannot be received from another server (YES in step S14), the business application of the other system (in this case, the primary server 1). In step S15, it is determined that there is a failure and the own node is switched to the master-slave server. On the other hand, when the business heartbeat message can be received by the monitoring unit 221 (NO in step S14), the business application switching unit 23 repeats the processes in steps S11 to S13.

  FIG. 5 shows a matrix table of contents determined by the business application switching unit 23 from the combination of the status information included in the heartbeat message and the reception state of the business heartbeat message. In this system, when both the heartbeat message and the business heartbeat message are in a suspended state, or when the status information included in the heartbeat message is “ShutDown” and the business heartbeat message is in a suspended state, It turns out that it switches to.

  Therefore, when the business heartbeat message is received even if the status information in the heartbeat message is “ShutDown”, the business application switching unit 23 regards the business application of the other node as having no failure, and performs step S13. To display a warning that there is an error in the status display of the heartbeat message. On the other hand, when the stop of the business heartbeat message transmission process at the other server is merely delayed (that is, when ShutDown precedes), the business application switching unit 23 If the determinations of S11 to S14 are continued, it is possible to determine the interruption of the business heartbeat reception. In such a case, the process proceeds to step S15.

  In this system, the business process itself (in other words, the business application itself) outputs the heartbeat repeatedly at a predetermined cycle separately from the heartbeat of the monitoring process as described above. It becomes possible to detect accurately by the other server, and it becomes possible to quickly switch to the master / slave server when the business application of the other node is stopped.

  Further, in this system, since the status of the business application is included as status information in the heartbeat message, the status application notifies the stop of the business application (step S12) or the heartbeat message itself is interrupted ( Only in step S11), the reception state of the business heartbeat message is checked (step S14). For this reason, even if the reception of the business heartbeat message is interrupted, the business application switching unit 23 determines that there is no failure in the business of the other node if the status information in the heartbeat message is “READY”. Accordingly, the switching process of step S15 is not performed, but a warning display process indicating that the business heartbeat message has not been received is performed (see FIG. 5). In this case, it is typically considered that an abnormality has occurred in the reception function of the business heartbeat message of the own node.

  In addition, the business application switching unit 23 similarly fails in the business itself of other nodes when the business heartbeat message is received even when the reception of the heartbeat message is interrupted (YES in step S11). The switching process in step S15 is not performed because it is considered that there is none, but a warning display process indicating that a heartbeat message has not been received is performed (see FIG. 5). In this case, it is typically considered that an abnormality has occurred in the heartbeat reception function of the own node or the heartbeat transmission function of another node (see FIG. 2).

  The processing described above is similarly performed in the business application switching unit 13 of the main server 1.

  In the following, a description will be given of a process of switching the slave server 2 so as to become the master slave server due to the failure of the master server 1.

(When a business application failure occurs)
The server 1 performs the business process of its own node (in this case, any of reception of a request message from the client terminal, processing of the request, transmission of synchronous data to the slave server (server 2), transmission / reception of business heartbeat) If a failure occurs (YES in step S4), each process of the business application of the own node is stopped (step S5). Then, after all the processes of the business application are stopped, a heartbeat message with the status of the local node being “ShutDown” is transmitted (step S6).

(When other failures occur)
In the case of other failures, for example, when a hardware failure such as a power shutdown or disconnection occurs in the server 1, neither the heartbeat message nor the business heartbeat message can be transmitted from the server 1. Reception of these messages is in a “disruption” state. However, a failure may occur only in the heartbeat message transmission function. In this case, the business heartbeat message is transmitted from the server 1.

(Processing of server 2)
On the other hand, the server 2 that has detected the failure of the server 1 rewrites the setting table in the storage unit 24 in step S15 (see FIGS. 8 and 9). An initial setting state of the setting table stored in the storage unit 24 is shown in FIG. This setting table defines the business of the business application, that is, the processing subject of each function. The topic column in the figure indicates the function of the business application, where “/ HB” is the heartbeat message transmission / reception function, “/ WHB” is the business heartbeat message transmission / reception function, and “/ SYNC” is the synchronization data. A transmission / reception function, “/ ORD” indicates a function for receiving and processing a request message from the client terminal, “/ ACK” indicates a response function to the client terminal, and “/ DB” indicates a storage function in the database.

  Also, the right column corresponding to the topic column shows the main body that processes each function and the active state of each function, and FIG. 8 shows the initial setting state. Specifically, each of the above functions is “O”, that is, an active state, and the request message from the client terminal is received by “SI”, that is, the server 1, and the response to the client terminal (“Cl”) and the database Is stored in “SII”, that is, the server 2 is set. In the normal state, it is understood that the status information “READY” is included in the heartbeat message transmitted and received.

  When the server 2 receives the heartbeat message including “ShutDown” as the status information (YES in step S12) and detects the interruption of the business heartbeat message (YES in step S14), as shown in FIG. The active state of the business heartbeat message transmission function (/ WHB), the synchronization data transmission function (/ SYNC), and the request message reception function (/ ORD) from the client terminal in the server 1 business process (SI_WP) Each is set to inactive (denoted by “x” in the figure), and the reception and processing function (/ ORD) of the request message from the client terminal in the business process (SII_WP) of the own node is activated (in the figure “ Rewrite the setting table as shown by “○”. In this case, since the synchronization data transmission / reception function is not used, “/ SYNC” of the business process (SII_WP) of the local node is set to inactive (denoted by “−” in the figure).

  After such processing, based on the settings in the rewritten setting table, the slave server 2 performs processing as the primary slave server as shown in FIG. That is, the server 2 receives a request message from the client terminal 40 that accesses the business application via the network 100 by the communication unit 222 and processes the request content by the business application (business application control unit 22) of its own node. The processing result data is transmitted as a request response from the communication unit 222 to the client terminal 40 via the network 100, thereby providing a data service to the client terminal 40. Further, the business application control unit 22 of the server 2 stores a series of processing result data including the request message in the database 3 via the communication unit 222.

(Client terminal processing)
In addition, since the request message from the client terminal 40 is not received or processed until the above-described switching process is completed after the failure occurs, the request response to the request message is not received. Therefore, when the response to the request message is not made even after a predetermined time has elapsed, the client terminal 40 retransmits the request message that has become no response to the master-slave server.

(When the primary server is switched to the primary and secondary servers)
Next, a description will be given of a process of switching the server 1 which is the primary server to become the primary and secondary server due to the failure of the secondary server 2.

(Processing of server 2)
The server 2 has a failure in any of the business processing of its own node, in this case, reception of synchronous data from the server 1, response to the client terminal, storage in the database, transmission / reception of the business heartbeat (step S4). YES), each process of the business application of its own node is stopped (step S5). Then, after all the processes of the business application are stopped, a heartbeat message with the status of the local node being “ShutDown” is transmitted (step S6).

(When other failures occur)
In the case of other failures, for example, when a hardware failure such as power interruption or disconnection occurs in the server 2, neither the heartbeat message nor the business heartbeat message can be transmitted from the server 2. Reception of these messages is in a “disruption” state. However, a failure may occur only in the heartbeat message transmission function. In this case, the business heartbeat message is transmitted from the server 2.

(Processing of server 1)
On the other hand, the server 1 that has detected the failure of the server 2 rewrites the setting table in the storage unit 24 as shown in FIG. 10 in step S15. Here, FIG. 10 shows an example of rewriting the setting table when the slave server 2 is down due to power shutdown.

  That is, the server 1 detects that the reception of the heartbeat message from the server 2 is interrupted (YES in step S11), and detects the interruption of the business heartbeat message in step S14, as shown in FIG. Heartbeat message transmission / reception function (/ HB), business heartbeat message transmission function (/ WHB), synchronous data reception function (/ SYNC), response function to client terminal (/) in the business process (SII_WP) of server 2 ACK) and the active state of the database storage function (/ DB) are canceled (indicated by “x” in the figure), and the request message received from the client terminal and processing function in the business process (SI_WP) of the own node ( / ORD) is activated (represented by “◯” in the figure), and the setting table is rewritten. In this case, since the synchronization data transmission / reception function is not used, “/ SYNC” of the business process (SII_WP) of the local node is deactivated (denoted by “−” in the figure).

  After such processing, based on the setting of the rewritten setting table, the server 2 that was the master performs processing as a master-slave server as shown in FIG. That is, the server 1 receives a request message from the client terminal 40 accessing the business application via the network 100 by the communication unit 122 and processes the request content by the business application (business application control unit 12) of its own node. By transmitting the processing result data from the communication unit 122 to the client terminal 40 via the network 100 as a request response, the data service is provided to the client terminal 40. Further, the business application control unit 12 of the server 1 stores a series of processing result data including the request message in the database 3 via the communication unit 122.

  As described above, in this system, in addition to the monitoring process based on the heartbeat message (see FIG. 6), a separate heartbeat (that is, a business heartbeat message) is transmitted and received by the business process by the business application. Even when the reception of the beat message is interrupted, it is possible to determine the business execution status of the other system, and it is possible to accurately and easily determine whether or not switching to the master / slave system is required. Specifically, according to the present system, when there is a failure only in the heartbeat message transmission / reception function, switching to the master / slave system is not performed (see FIG. 2), so avoiding unnecessary switching. In addition, it is possible to prevent double processing due to the switching between the primary and secondary servers to the primary and secondary servers.

  In addition, this system is configured so that the main server receives and processes requests from the client at normal times, and the slave server responds to the client and stores the database, so that the load on each server is distributed to the clients. Response is improved, and the entire system is processed faster. Furthermore, in this system, since a response is made directly from the slave to the client without replying from the slave to the master as in the conventional system, the response response to the client is improved. Furthermore, in this system, it is possible to prevent the occurrence of a telegram response to the client or the loss of data stored in the database when the primary server fails.

(Second Embodiment)
A second embodiment of this system will be described. FIG. 11 is a flowchart for explaining the second embodiment, and is the same as FIG. 7 except that step S10 for determining whether or not the heartbeat monitoring mode is entered before entering the routine of FIG. 5 described above. It is.

  That is, in the second embodiment of the present system, each server (1 and 2) is started in a heartbeat monitoring mode OFF state in which the heartbeat of other servers is not monitored when the power is turned on, and heartbeat monitoring is performed. The heartbeat monitoring mode OFF state is maintained until a start command for starting is received. In other words, in the second embodiment, until the monitoring start command is received, switching to the master-slave server is performed regardless of the detection results of the heartbeat monitoring units (11 and 21) and the monitoring units (121 and 221). It is forbidden.

  Here, the start command for starting heartbeat monitoring is a command for the entire system in this embodiment, and the system administrator operates one of the input means (such as a keyboard or mouse not shown) of the server 1 or 2. As a result, it is detected by the business application control unit (12 or 22). Hereinafter, the case where the start command is input from the server 1 will be described. The business application control unit 12 of the server 1 that has detected the start command controls the business application control of the other server 2 via the communication units 122 and 222. The information is transferred to the unit 22 and the business application switching unit 13 of the own node is notified that the start command has been received. The business application switching unit 13 performs the determination in step S10 when the server is activated, and determines that the heartbeat monitoring mode is turned on when notified that the start command has been received (YES in step S10). The processing after step S11 is started. On the other hand, the server 2 to which the start command is transferred from the server 1 notifies the business application switching unit 23 from the business application control unit 22 that the start command has been received. Similarly, the business application switching unit 23 performs the heartbeat monitoring mode. Is turned on (YES in step S10), and the processing from step S11 onward is started.

  As described above, in the second embodiment of the present system, the heartbeat monitoring mode OFF state is maintained until the start command is input, and monitoring of other servers is not performed. (Step S15) is also not executed. Therefore, in the second embodiment, when a so-called startup failure occurs and a failure occurs in one server, maintenance or restart of the server can be performed without limitation. In addition, according to the second embodiment, switching to a master / slave system that is originally unnecessary when the entire system is relatively unstable, such as when the power is turned on, is prevented, and each server is in a relatively stable state. Later, a start command can be input to start monitoring of another server. Therefore, according to the second embodiment, the burden on the system administrator is greatly reduced.

(Applied technology field)
The system of each embodiment described above can be suitably applied to a redundant system. In addition, this system can realize a hot standby system with low cost, reliability, and high responsiveness without introducing cluster software.

  In addition, although embodiment of this invention was described, the said embodiment is shown as an example and is not intending limiting the range of invention. The novel embodiment can be implemented in various other forms, and various omissions, replacements, and changes can be made without departing from the scope of the invention. These embodiments and modifications thereof are included in the scope and gist of the invention, and are included in the invention described in the claims and the equivalents thereof.

1, 2 Server 11, 21 Heartbeat (HB) monitoring unit 12, 22 Business application (AP) control unit 121, 221 Monitoring unit 122, 222 Communication unit 13, 23 Business application (AP) switching unit 14, 24 Storage unit 3 Database 40 Client terminal 100 Network

Claims (7)

A hot standby type client server system that includes a master server and a slave server that can communicate with a client terminal, and causes a server of another system to operate as a master / slave server when a failure occurs in one system,
The master server receives and processes a request from a client terminal, transmits the processing data to the slave server, and the slave server transfers the received processing data to the client terminal,
Each server
A heartbeat monitoring unit that transmits and receives heartbeats with other servers and detects the status of other systems;
A business heartbeat monitoring unit that transmits and receives business heartbeats when business applications are running and detects the status of other business applications;
Based on the detection results of the heartbeat monitoring unit and the business heartbeat monitoring unit, the local server operates as a master / slave server that receives and processes the request and transmits the processing data to the client terminal. A switching unit for switching,
A client server system comprising:   2. The client according to claim 1, wherein the switching unit is prohibited from switching to the master-slave server regardless of the detection results of the heartbeat monitoring unit and the business heartbeat monitoring unit until a monitoring start command is received. Server system. The slave server transfers the received processing data to the client terminal and stores it in a database;
3. The client server system according to claim 1, wherein the switching unit further causes the server to operate so as to store the processing result data in a database. The switching unit, the reception of both the heartbeat and the business heartbeat is disrupted, client-server system according to any one of claims 1 to 3 to switch the local server to the master-slave system server. The heartbeat includes the status information of its own server,
When the business application of its own server stops, the heartbeat monitoring unit transmits a heartbeat including status information indicating the stop,
The switching unit checks whether or not the business heartbeat is received when the heartbeat of the status information indicating the stop is received, and when the reception of the business heartbeat is interrupted, The client server system according to claim 4 to be switched. A switching control method in a hot standby type client server system that includes a master server and a slave server that can communicate with a client terminal, and switches a server of another system to a master-slave server when a failure occurs in one system,
The master server receives and processes a request from a client terminal, transmits the processing data to the slave server, and the slave server transfers the received processing data to the client terminal,
Each server
A heartbeat monitoring step for detecting a state of the other system by transmitting and receiving a heartbeat with the other server;
A business heartbeat monitoring step that detects the status of other business applications by sending and receiving business heartbeats when the business applications are running;
Based on the detection results in the heartbeat monitoring step and the business heartbeat monitoring step, the local server operates as a master / slave server that receives and processes the request, and transmits the processing data to the client terminal. A switching step to switch to
Switching control method to carry out. A control program in a hot standby type client server system that includes a master server and a slave server that can communicate with a client terminal, and switches a server of another system to a master-slave server when a failure occurs in one system,
The master server receives and processes the request of the client terminal, transmits the processing data to the slave server, causes the slave server to transfer the received processing data to the client terminal,
For each server,
A heartbeat monitoring step for detecting a state of the other system by transmitting and receiving a heartbeat with the other server;
A business heartbeat monitoring step that detects the status of other business applications by sending and receiving business heartbeats when the business applications are running;
Based on the detection results in the heartbeat monitoring step and the business heartbeat monitoring step, the local server operates as a master / slave server that receives and processes the request, and transmits the processing data to the client terminal. A switching step to switch to
A control program for carrying out

Images