JP2005135125A - Fail-over processing method - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To ensure that no old session information is referred to whenever a Web AP server may fail, and obtain a method for preventing a mismatch between two systems by a communication failure, only by software. <P>SOLUTION: The fail-over processing method uses a normal system server and a standby system server. The normal system server receives a first request, reads out first session information used in processing the first request, and copies and stores the first session information to a storage device of the standby system server. When receiving a second request, the normal system server invalidates the first session information stored in the storage device of the standby system server before starting to process the second request. <P>COPYRIGHT: (C)2005,JPO&NCIPI

Description

  The present invention relates to a failover processing method in which a standby server program takes over processing in the event of a failure of a normal server program due to a redundant configuration of server programs including a normal system and a standby system.

  Commercial Web sites such as online shopping sites that allow customers to shop on the Web are required to have high availability that can be operated 24 hours a day, 365 days a year so that services can always be provided to users.

  Such a commercial website generally has a web server, a web application server (Web AP server) that executes an application program in cooperation with the web server, and data that the application program refers to or results of processing. It consists of three layers of database management system (DBMS) that manages

  By accessing the web site from the web browser, the HTTP request arrives at the web server. The Web server refers to the destination URL of the arrived HTTP request, and determines whether to return an HTML file or an image file corresponding to the URL to the Web browser or to transfer the request to the Web AP server. When transferring a request to the Web AP server, the Web AP server executes an application program corresponding to the destination URL of the transferred request. Processing based on data input by the user, such as product selection / confirmation / settlement at an online shopping site, is performed by executing an application program on the Web AP server. This application program communicates with the DBMS as necessary to search and retrieve necessary data from the database, and store the processed data in the database.

  One way to increase the availability of a Web site that consists of a Web server, Web AP server, and DBMS is to start multiple redundant Web servers, Web AP servers, and DBMSs. If it happens, there is a method to take over the processing with an alternative server that has been activated redundantly. In this method, failure of some servers does not lead to the suspension of the entire website, and the website can continue processing. However, if the Web AP server fails, the entire Web site will not be stopped, but an error will be returned to the user for the following reasons.

  An application implemented on the Web is generally executed by sequentially calling a series of pages constituting the application by following links. In many cases, each page is configured to allow the user to input data step by step, and when the processing of the application is completed, the data input up to that point is collectively registered in a database. For example, in a shopping site, on the individual pages that make up the application, you first have to select a product to be purchased, then enter data such as an address and credit card number, and at the time of the final settlement, Store those data in the database.

  At this time, it is necessary to store the intermediate data input stepwise before being registered in the database in association with the client. A commercially available Web AP server provides a function for storing such data in memory in association with the client. Therefore, when a failure occurs in the Web AP server, the data on this memory is lost, and data such as purchased items and addresses that the user has entered so far are lost. Therefore, other Web AP servers that have been activated redundantly cannot take over user processing, and the application will return an error to the user.

  This intermediate data on the memory is called session information. The Web AP server issues an identifier called a session ID to the client in order to associate the client with the session information, and manages the session information in association with the identifier. When the Web AP server issues a session ID, the session ID includes an ID for identifying the Web AP server holding the session information of the client. In the Web server, based on the session ID included in the request, the request from the same client is transferred to the same Web AP server every time.

  In order to solve the above-mentioned problem that an individual user encounters an error due to a failure of the Web AP server, as an example of a method for preparing session failure in the Web AP server by duplicating the session information on the memory, Non-Patent Document 1 There is.

  In the conventional example of Non-Patent Document 1, a plurality of Web AP servers are started, and the session information used for request processing by a certain Web AP server is backed up on the memory of another Web AP server after request processing. , Session information is duplicated.

  In the above conventional example, it is not disclosed whether consideration is given to the following problems, but by simply duplicating the session information, depending on the timing when the Web AP server fails, old session information may be used. The request processing may be taken over. Specifically, after processing a request on a certain Web AP server, if a failure occurs in that Web AP server before backing up the session information updated by that request processing, the backup is performed on the Web AP server that is the backup destination. The new updated session information is not backed up and the previous old session information remains. In subsequent requests, there arises a problem that the alternative Web AP server performs processing using the old session information.

  Furthermore, when a failure occurs in communication for backup between Web AP servers, the Web AP server that performs request processing at the normal time continues processing without being able to back up the session information to the backup Web AP server. Then, the contents of the session information data held between the two Web AP servers differ. In this state, if a failure occurs in the Web AP server that is processing requests normally, the backup destination Web AP server performs processing using the old backup.

  As a conventional example for preventing inconsistency between two systems caused by such communication failure, there is a “duplex communication system” in Patent Document 1. In this conventional example, a normal host that performs request processing when normal and a standby host that performs request processing only when a failure occurs in the normal host by constantly monitoring the operating state of the normal host during normal operation are provided. The standby host periodically monitors the operation by communicating with the normal host, and does not take over the processing while determining that the normal host is operating. If it is determined by operation monitoring that the normal host has stopped, considering the case where a failure has occurred in the communication path with the normal host, Disconnect power using dedicated hardware. Thus, before inconsistency occurs between the two systems due to a communication failure, the operation of either one is surely stopped, and the processing is continued only by the other.

Scott Hawkins, “BEA WebLogic Server Administration Kit”, Prentice Hall Ptr, 2003, p.77

JP 2000-20336 A

  When the above-mentioned conventional technology is used to construct a commercial large-scale Web site that provides services without stopping for 24 hours 365 days, the following problems arise.

  Commercial Web sites require reliability in addition to availability. In addition, large-scale websites in recent years have been configured to be able to withstand high loads by purchasing a large number of inexpensive PCs and starting up the Web server or Web AP server on that PC to distribute the load. .

  The first problem is only the method disclosed in the conventional example of Non-Patent Document 1, and simply duplicating the session information in the memory refers to the old session information depending on the failure timing of the Web AP server. This is a problem of continuing processing.

  The second problem is that the conventional example of Patent Document 1 is not suitable for the configuration of a large-scale Web site in recent years. This is because it is not practical from the viewpoint of cost to install dedicated hardware for controlling the power supply in all of them even though a large number of inexpensive PCs are installed to reduce costs.

  The present invention aims to solve the following two problems in view of the problems of the prior art. First, it guarantees that old session information will not be referenced no matter what timing the Web AP server fails. Second, a method for preventing inconsistency between two systems due to communication failure is realized only by software.

  A failover processing method using a normal server and a standby server according to the present invention, wherein the normal server receives a first request and uses the first session information used in processing the first request. Is copied and stored in the storage device of the standby server, and when the normal server receives the second request, before starting the processing of the second request Further, the first session information stored in the storage device of the standby server is invalidated.

  In addition, in order to solve the above-mentioned problem, the present invention invalidates the data to be aged in advance when the session information duplicated on the memory of the normal Web AP server and the standby Web AP server is outdated. To do.

  Specifically, before starting the request processing on the normal Web AP server, request the standby Web AP server to invalidate the backup of the session information to be updated on the normal Web AP server, and wait accordingly The backup of session information is invalidated on the Web AP server. As a result, the session information is not duplicated between the start of request processing on the normal Web AP server and the session information is duplicated on the standby Web AP server after request processing. Session information with different contents does not exist between the server and the standby Web AP server. Thereby, the first problem is solved.

  In addition, when a failure occurs in communication between the normal Web AP server and the standby Web AP server, when both servers detect the failure, they perform exclusive access to a specific record in the database, The server that can access the server will continue to operate, and the server that accessed later will voluntarily stop. As a result, when a communication failure occurs, it is possible to ensure that only one of the servers continues to operate with only software, and the second problem is solved.

  According to the present invention, even if a failure occurs in the Web application server, it becomes possible for the Web application server that takes over the processing to continue the request processing without using old session information. Moreover, even if a failure occurs in communication between Web application servers for duplicating session information, request processing can be continued without using old session information.

  Hereinafter, an embodiment of the present invention will be described in detail with reference to the drawings. One object of the present invention is to provide a failover processing method in which the session information used for request processing is duplicated in the standby Web AP server to prepare for a failure each time the normal Web AP server performs request processing. Whatever timing the server failure occurs, the standby Web AP server ensures that the old session information is not referenced, and continues the user's processing as much as possible.

  Another object of the present invention is to prevent inconsistency between the normal Web AP server and the standby Web AP server when a failure occurs in communication between the normal Web AP server and the standby Web AP server. Therefore, to ensure that only one of the Web AP servers continues to operate, it is necessary to realize only with software.

  In the present invention, in order to achieve the first object, before the request processing is performed by the normal Web AP server, a session information invalidation request is transmitted to the standby Web AP server. Disable the backup of session information on the standby Web AP server corresponding to the session information used for request processing in advance. This prevents the standby Web AP server from referring to old session information, although the session information is not duplicated while the normal Web AP server performs request processing.

  In addition, in order to achieve the second purpose described above, the normal Web AP server and the standby Web AP server regularly communicate with each other to monitor that they are operating and become a pair. If communication from the Web AP server is interrupted, only one Web AP server that can access the relational database record prepared in advance will continue to operate, and the other Web AP server accessed later Decided to stop voluntarily. As a result, only one of the Web AP servers continues to operate with software alone.

  Below, the outline | summary of the system configuration | structure and operation | movement of a present Example for achieving the said objective using this invention first is demonstrated.

  2 and 3 show the system configuration of this embodiment. In this embodiment, as shown in FIG. 2, a terminal device operated by a homepage viewer 503 and a web site 500 are connected via a network 501. The terminal device 502 includes a general-purpose computer and a general-purpose HTTP client program (hereinafter referred to as a Web browser 504), and a homepage viewer 503 accesses the Web site 500 by operating the Web browser 504 on the terminal device 502. To do.

  FIG. 3 shows the configuration within the Web site 500. The Web site 500 includes a Web server computer 510, a normal Web AP server computer 511, a standby Web AP server computer 512, and a DBMS computer 513, which are connected via a network. All of the computers that make up these Web sites can be implemented with general-purpose computers. The Web site manager 505 transmits an HTTP server program (hereinafter referred to as Web server program 100) on the Web server computer 510, and a normal Web AP server program 200 on the standby Web AP server computer 511. The standby Web AP server program 300 is activated on the Web AP server computer 512 and the DBMS program 400 is activated on the DBMS computer 513.

  The normal Web AP server program 200 is a Web AP server program that duplicates request processing and session information to the standby Web AP server program 300 when normal. The standby Web AP server program 300 is a Web AP server program that does not perform request processing when normal, but takes over request processing when the normal Web AP server program 200 fails. The normal Web AP server program 200 and the standby Web AP server program 300 are started in pairs.

  Hereinafter, a pair of the normal Web AP server program 200 and the standby Web AP server program 300 is referred to as a Web AP server pair. On the secondary storage device 401 on the DBMS computer 513, a server pair status management table 402, which is a relational database table that can be accessed via the DBMS program 400, is provided. One server pair status is stored for each Web AP server pair.

  In this embodiment, only one Web AP server pair is activated. However, if the normal and standby Web AP server programs to be paired are activated on different computers, a plurality of servers are distributed for load balancing. You may activate a pair. In this embodiment, the Web server program 100 and the DBMS program 400 are not redundantly configured because they are not related to the present invention. However, in order to increase the availability of the entire Web site 500, the Web server program 100 and the DBMS program 400 are Multiple configurations may be activated to provide a redundant configuration.

Next, an outline of the operation procedure of this embodiment will be described.
The operation procedure will be described with reference to FIG. When the normal and standby Web AP server programs are started, when the Web AP server pair is operating normally, when the normal Web AP server program 200 failure occurs, when the standby Web AP server program 300 failure occurs, between the Web AP server pairs A description will be given of when a communication failure occurs, when normal and standby Web AP server programs are operating independently, and when normal and standby Web AP server programs are restarted.

  First, operation procedures when starting up the normal Web AP server program 200 and the standby Web AP server program 300 will be described. When the normal Web AP server program 200 and the standby Web AP server program 300 are started, the normal Web AP server program 200 performs normal system initialization processing 201, and the standby Web AP server program 300 performs standby system initialization processing 301. Execute. Since the normal Web AP server program 200 and the standby Web AP server program 300 function as a pair, each initialization process establishes a connection with the paired Web AP server program and confirms their operation. The initialization process is not finished until it is possible. In other words, after establishing a connection between the paired Web AP server programs and confirming their operation, the initialization process ends.

  In this embodiment, the normal Web AP server program 200 repeatedly establishes a connection with the standby Web AP server program 300 until a connection with the standby Web AP server program 300 is established in the normal system initialization process 201. Process to issue a request. The standby Web AP server program 300 performs a process of accepting a connection establishment request from the normal Web AP server program 200 in the standby system initialization process 301, and initializes until a connection is established with each other. Does not end. That is, the initialization process is terminated after the connection is established.

  When the connection is established, the normal Web AP server program 200 sends a server pair status update SQL921 to the DBMS program 400 during the normal initialization process 201 to manage the status of the Web AP server pair. The server pair status of the server pair status management table 402 to be used is set to normal operation, which is a character string indicating that the Web AP server pair is operating normally. The server pair status recorded in this server pair status must be referred to as necessary when the Web AP server program is running. Therefore, in order to reduce access to the DBMS program 400 as much as possible, the normal Web AP server program 200 and the standby Web AP server program 300 each have a cache for storing server pair status information in the memory. To do.

  This cache is called a server pair status cache 208. After updating the server pair status to normal operation, the normal Web AP server program 200 and the standby Web AP server program 300 set their own server pair status cache 208 to normal operation. Thereafter, using the connection established in this initialization process, communication for normal session information duplication (processing to copy the session information and store it in another server), and the normal Web AP server program 200 And communication for operation check between the server and the standby Web AP server program 300. After completing the above initialization process, the Web AP server pair starts operating normally.

  Next, the operation procedure of this embodiment at normal time will be described in the order of the Web server program 100, the normal Web AP server program 200, and the standby Web AP server program 300.

  The Web server program 100 selects a Web AP server pair to which the request should be transferred from the destination URL of the HTTP request 901 arriving from the Web browser 504 and the session ID included in the request, and among the selected pairs, the normal Web AP server Forward the request to program 200. First, when the home page viewer 503 operates the Web browser 504 to access the Web site 500, the HTTP request 901 arrives at the Web server program 100. When receiving the HTTP request 901, the Web server program 100 executes a request selection transfer process 101 to determine whether the HTTP request 901 should be processed by itself or transferred to the Web AP server pair.

  In the request selection transfer process 101, the transfer destination Web AP server pair group is obtained from the request destination URL, and the transfer destination Web AP is determined from the destination URL of the received HTTP request 901 using the transfer destination Web AP server pair group determination table 102. Determine the server pair group. The Web AP server pair group obtained here is one or a plurality of Web AP server pairs. In this embodiment, it is assumed that the Web AP server pair group determination table 102 managed by the Web server program that is the transfer destination of the HTTP request is given to the Web server program 100 by the Web site manager 504 at the time of activation. That is, the Web AP server pair group determination table 102 is stored by the administrator in the storage device of the computer on which the Web server program runs.

  When the transfer destination Web AP server pair group is not found, the Web server program 100 processes this request. When the transfer destination Web AP server pair group is obtained, it is next determined to which Web AP server pair the request is transferred from the obtained Web AP server pair group. In this case, if the HTTP request 901 includes a session ID, the Web AP server pair to be transferred is determined from the Web AP server pair ID included in the session ID. If the session ID is not included, The Web AP server pair is randomly determined from the Web AP server pair group.

  Then, after determining the Web AP server pair, using the Web AP server pair definition table 103 for obtaining the network address of the normal Web AP server program and the network address of the standby Web AP server program from the Web AP server pair name, The network address of the normal Web AP server program of the determined Web AP server pair is obtained, and the request is transferred there. In this embodiment, it is assumed that the Web AP server pair definition table 103 is given to the Web server program 100 by the Web site manager 504 at startup.

  Next, an operation procedure of the normal Web AP server program 200 that has received the HTTP request 901 from the Web server program 100 at the normal time will be described. When the normal Web AP server program 200 receives the HTTP request 901 from the Web server program 100, the normal Web AP server program 200 sequentially executes the session information invalidation request transmission process 202, the application execution process 203, and the session information duplex request transmission process 204. First, in the session information invalidation request transmission process 202, the session ID included in the HTTP request 901 is acquired, and it is confirmed whether or not the session information corresponding to the session ID exists in its own memory. If session information exists, the session ID is included in the session information invalidation request 912 and transmitted to the standby Web AP server program 300.

  If session information does not exist, the session ID is included in the session information acquisition request 917 and transmitted to the standby Web AP server program 300. The situation where the session information does not exist typically occurs when the normal Web AP server program 200 is temporarily stopped due to a failure and then restarted, and then again by the reconnection process described later, the standby Web AP server program 300 And immediately after establishing a connection and starting normal operation. At this time, since the restarted normal Web AP server program 200 does not hold session information in the memory, it is necessary to acquire session information necessary for request processing from the standby Web AP server program 300. The acquisition request for this is a session information acquisition request 917.

  When the session information invalidation response 913 or the reply is returned from the standby Web AP server program 300, the application execution process 203 is executed next. When a session information acquisition response 918 is returned from the standby Web AP server program 300, the application execution process 203 is executed after the session information included in the response is stored in the memory. In the application execution process 203, an application program corresponding to the URL of the HTTP request 901 is executed.

  By executing the application program, the session information in the memory of the normal Web AP server program 200 is updated, and an HTTP response 902 is returned to the Web browser 504. Since the application execution process 203 is a function provided in a general-purpose Web AP server program, detailed description thereof is omitted. Then, after executing the application execution process 203, the session information duplex request transmission process 204 is executed. In this process, in order to duplicate the session information updated by executing the application to the standby Web AP server program 300, the standby Web AP includes the session information and session ID used for request processing in the session information duplex request 914. Send to server program 300. The above is the processing of the normal Web AP server program 200 when receiving a request.

  In addition to the processing at the time of receiving the request, the normal Web AP server program 200 transmits / receives an operation confirmation message 916 to monitor the status of the standby Web AP server program 300. Is executed at regular intervals.

  Next, a normal operation procedure of the standby Web AP server program 300 will be described. When the normal standby Web AP server program 300 receives the session information invalidation request 912 or the session information acquisition request 917 from the normal Web AP server program 200, the normal standby Web AP server program 300 executes the session information invalidation processing 302. In the session information invalidation processing 302, session information having a session ID included in the session information invalidation request 912 or the session information acquisition request 917 is invalidated. However, when the session information acquisition request 917 is received, the session information is included in the session information acquisition response 918 and returned before being invalidated.

  Further, when the session information duplex request 914 is transmitted from the normal Web AP server program 200, the standby Web AP server program 300 backs up the session information transmitted in the request in the memory. The session information duplex process 304 is executed. Further, the standby Web AP server program 300 does not perform request processing when it is normal. Immediately after the normal Web AP server program 200 is restarted from the state where the standby Web AP server program 300 is operating alone due to a failure of the normal Web AP server program 200, the Web server program 100 An HTTP request 901 may be transferred to the standby Web AP server program 300 during normal operation. In that case, the takeover determination process 307 is first performed in order to check the operating status of the normal Web AP server program 200. Execute.

In this process, when an operational confirmation message 916 is sent to the normal Web AP server program 200 to check if there is a response and then the normal Web AP server program 200 is determined to be operating In this case, the request processing is not performed, and a processing decline notice 903 is transmitted to the Web server program 100 that has transferred the request. The Web server program 100 that has received the processing decline notification 903 re-transfers the HTTP request 901 to the normal Web AP server program 200. Similarly to the normal Web AP server program 200, the standby Web AP server program 300 executes the operating state monitoring process 205 at regular intervals in order to monitor the state of the normal Web AP server program 200.
The above is the processing procedure of the normal Web server program 100, normal Web AP server program 200, and standby Web AP server program 300.

  According to the above processing procedure, the request processing is always executed by the normal Web AP server program 200 at the normal time. In the normal Web AP server program 200 that executes the request, the session information invalidation request transmission process 202 is executed before the application execution process 203 to invalidate the session information in the standby Web AP server program 300. By doing so, it is possible to prevent inconsistency of session information data between the normal Web AP server program 200 and the standby Web AP server program 300 immediately after the execution of the application execution process 203. This is a feature of the present invention.

Therefore, it is ensured that the standby Web AP server program 300 does not use old data whenever a failure occurs in the normal Web AP server program 200.
Next, operation procedures of the Web server program 100 and the standby Web AP server program 300 when a failure occurs in the normal Web AP server program 200 will be described.

  When a failure occurs in the normal Web AP server program 200, the Web server program 100 detects the failure due to a communication error when communicating with the normal Web AP server program 200. When the Web server program 100 detects a failure in the normal Web AP server program 200, the Web server program 100 transfers the HTTP request 901 again to the standby Web AP server program 300 paired with the normal Web AP server program 200. Through the processing of the Web server program 100 described above, the HTTP request 901 is transferred to the standby Web AP server program 300 when the normal Web AP server program 200 fails.

  On the other hand, the standby Web AP server program 300 detects a failure of the normal Web AP server program 200 by the following two methods. One is an operation check to the normal Web AP server program 200 in the operation state monitoring processing 205 that is periodically executed at the normal time, and the other is an HTTP request 901 transferred from the Web server program 100. This is confirmation of the operation to the normal Web AP server program 200 in the takeover determination processing 307 executed at the time. In any of the above cases, the failure of the normal Web AP server program 200 is detected when the standby Web AP server program 300 becomes unable to communicate with the normal Web AP server program 200.

  In this detection method, it is impossible to determine whether it is a failure of the normal Web AP server program 200 or simply a communication failure. Therefore, only one of them can be processed reliably in consideration of the communication failure. The active server determination process 206 is executed to determine which one of the Web AP server programs to continue. In the active server determination process 206, the normal or standby Web AP server program refers to the server pair status in the server pair status management table 402 provided in the database, and can be referenced before the paired Web AP server program. In this case, the server pair status is updated and the operation is continued.

  If the root cause of the communication failure is the failure of the normal Web AP server program 200, the normal Web AP server program 200 cannot access the server pair status, so only the standby Web AP server program 300 is the database. And the standby Web AP server 300 continues to operate.

  At this time, the standby Web AP server program 300 is a character string that means that the server pair status in the server pair status management table 402 and its own server pair status cache 208 are processed only by the standby system. Update to standby system single operation, end takeover determination processing, and execute request processing.

  As described above, when a failure occurs in the normal Web AP server program 200, the standby Web AP server program 300 takes over the request processing after the server pair state management table 402 is set to stand alone operation. Since the session information invalidation request transmission processing 202 performed by the normal Web AP server program 200 during normal operation guarantees that no old session information remains in the standby Web AP server program 300, the old session information is used. Thus, the standby Web AP server program 300 can be prevented from taking over processing.

  Next, operation procedures of the Web server program 100 and the normal Web AP server program 200 when a failure occurs in the standby Web AP server program 300 will be described.

  As long as the normal Web AP server program 200 is running, the Web server program 100 has no opportunity to communicate with the standby Web AP server program 300. Absent.

  The normal system Web AP server program 200 is an operating state monitoring process 205 periodically executed at normal time, a session information invalidation request transmission process 202 executed at the time of request processing, or a standby system in the session information duplex request transmission process 204 When an error occurs in communication with the Web AP server program 300, a failure of the standby Web AP server program 300 is detected. When the normal Web AP server program 200 detects a failure in the standby Web AP server program 300, the normal Web AP server program 200 executes an active server determination process 206.

  Since the standby Web AP server program 300 cannot access the server pair status in the server pair status management table 402, the normal Web AP server program 200 stores the server pair status in the server pair status management table 402 and its own server pair status cache 208. The normal Web AP server program is updated to normal single operation, which is a character string that means that request processing is performed alone, and continues to operate independently. In subsequent requests, as long as the server pair status cache 208 is operating normally alone, the request processing is executed independently without communicating with the standby Web AP server program 300.

  As described above, when the standby Web AP server program 300 fails, the normal Web AP server program 200 performs the request processing independently.

  Next, when a failure occurs in communication between the normal Web AP server program 200 and the standby Web AP server program 300, the Web server program 100, the normal Web AP server program 200, and the standby Web AP server program 300 The operation procedure will be described.

  In the case of this failure, the Web server program 100 cannot detect the failure. Therefore, the request that arrived is transferred to the normal Web AP server program 200 in the same manner as in the normal state.

  The normal Web AP server program 200 detects a failure at the timing of communication with the standby Web AP server program 300 for the first time after a failure occurs, and executes an active server determination process 206.

  On the other hand, the standby Web AP server program 300 detects a failure due to a communication error when executing an operation status monitoring process 205 or a response to a request from the normal Web AP server program 200, and executes an active server determination process 206. To do. Then, of the normal Web AP server program 200 and the standby Web AP server program 300, the Web AP server program that can refer to the server pair status in the server pair status management table 402 first indicates the server pair status to the Web You can update the AP server to single operation and continue operation.

  On the other hand, the Web AP server program that refers to the server pair status later is the single operation of the Web AP server program whose server pair status is a pair, and in this case, stops spontaneously. If a request arrives from the Web server program 100 before it stops spontaneously, a processing decline notice 903 is returned to the Web server program 100.

  As described above, at the time of communication failure between systems, in the active server determination process 206, only one Web AP server program that has previously been able to refer to the server pair status first can continue to operate. As a result, in the event of a communication failure between systems, it is possible to reliably realize that only one Web AP server program is operated by software alone, thereby realizing the second object of the present invention.

  Next, the operation procedure of the normal Web AP server program 200 and the standby Web AP server program 300 that have become independent due to a Web AP server program failure or a communication failure between systems will be described.

  In the case where the normal Web AP server program 200 is operated independently, when the normal Web AP server program 200 receives the HTTP request 901 from the Web server program 100, it executes only the application execution process 203. The determination as to whether or not the server is operating independently is performed with reference to the server pair status cache 208 for each request processing. Further, as a process other than the time of receiving a request, a normal system reconnection process 207 for periodically transmitting a connection establishment request 911 is executed for the standby Web AP server program 300 that will be restarted.

  When the stand-by Web AP server program 300 is operated independently, when receiving a request from the Web server program 100, the stand-by Web AP server program 300 executes only the application execution process 203. The determination as to whether or not the server is operating independently is performed with reference to the server pair status cache 208 for each request processing. Further, as processing other than the time of receiving a request, standby reconnection processing for receiving the connection establishment request 911 transmitted from the normal Web AP server program 200 that will be restarted is periodically executed.

  In this way, when operating alone, the Web AP server program processes incoming requests without duplicating session information. Then, processing for re-establishing a connection with a pair that will be restarted is periodically performed.

  Finally, an operation procedure when the normal Web AP server program 200 or the standby Web AP server program 300 is restarted will be described.

  When the standby Web AP server program 300 is restarted from the normal operation state of the normal Web AP server program 200, the normal Web reconnection processing 207 that is performed when the normal Web AP server program 200 operates independently, and the standby Web AP The connection is established again by the standby system initialization process 301 of the server program. When the normal Web AP server program 200 establishes the connection, it updates the server pair status and the server pair status cache 208 of the server pair status management table 402 to normal operation during the normal system reconnection processing 207. Perform the operation. When the standby Web AP server program 300 establishes a connection with the normal Web AP server program 200, the standby Web AP server program 300 makes the server pair status cache 208 operate normally in the standby initialization process 301.

  At this point, the session information existing in the normal Web AP server program 200 is not duplicated in the memory of the standby Web AP server program 300, but every time request processing is performed in the normal Web AP server program 200, The session information used in the request processing is gradually duplicated in the standby Web AP server program 300. However, if a failure occurs in the normal Web AP server program 200 before the session information is completely duplicated, the session information that has not been duplicated at that time is lost.

  In preparation for such a situation, as a process at the time of reconnection, even if request processing is not performed, the session information existing only in the normal Web AP server program 200 is restarted, and the standby Web AP server program 300 that has been restarted. The session information duplex recovery processing 209 may be performed, which are transmitted collectively.

  In addition, when the normal Web AP server program 200 is restarted from the stand-alone Web AP server program 300 operating independently, the standby reconnect processing 308 that is performed when the standby Web AP server program 300 is operating independently. Then, the normal system initialization process 201 of the normal Web AP server program establishes the connection again. When the connection is established, the normal Web AP server program sets the server pair status and server pair status cache 208 of the server pair status management table 402 to normal operation during normal system initialization processing.

  In addition, when the connection is established, the standby Web AP server program sets the server pair status cache 208 to normal operation during the standby reconnection process. For requests that subsequently arrive at the standby Web AP server program, as a result of the takeover determination processing 307, the server pair status cache 208 is operating normally. The processing decline notice 903 is transmitted, and the request is transferred to the normal Web AP server program 200.

  Even in this case, the session information existing in the standby Web AP server program 200 is not duplicated on the memory of the normal Web AP server program 300 only by reconnection, but the normal Web AP server program 200 Each time request processing is performed, the session information used in request processing is gradually duplicated. However, if a failure occurs in the standby Web AP server program 300 before the session information is completely duplicated, the session information that has not been duplicated at that time is lost.

  In preparation for such a situation, as a process at the time of reconnection, even if request processing is not performed, session information that exists only in the standby Web AP server program 300 is restored to the normal Web AP server program 200 that has been restarted. The session information duplex recovery processing 209 may be performed, which are transmitted collectively.

  As described above, normal operation or standby system Web AP server program can be restored to normal operation again when the other pair of Web AP server programs is restarted.

  With the above operation procedure, the object of the present invention can be achieved, and the Web AP server can be restored to a normal state by restarting.

Next, the configuration and operation of this embodiment will be described in detail.
FIG. 4 shows a configuration of the transfer destination Web AP server pair group determination table 102 created on the memory by the Web server program 100. The transfer destination Web AP server pair group determination table 102 is a table for obtaining a transfer destination Web AP server pair group from the destination URL of the HTTP request 901 received by the Web server program 100. The URL pattern 110 and the transfer destination Web AP server A pair group 111 is included. In this table, it is possible to know one or a plurality of transfer destination Web AP server pair IDs corresponding to the URL of the request by checking whether the URL of the request matches the URL pattern 110 in the table entry. Since the method for checking the conformity between the URL of the request and the URL pattern 110 is not related to the present invention, the description is omitted. This table is typically given by the Web site manager 505 when the Web server program 100 is started.

  FIG. 5 shows the configuration of the Web AP server pair definition table 103 that the Web server program 100 creates on the memory. The Web AP server pair definition table 103 includes a Web AP server pair ID 120, a normal network address 121 that is a network address for communicating with a normal Web AP server, and a standby system that is a network address for communicating with a standby Web AP server. It has a network address 122 and an active server 123 indicating a Web AP server that has recently processed a request in the pair. The value taken by the active server 123 is either a normal character string or a standby character string. The value of the active server 123 is used by the Web server to determine whether to transfer the HTTP request first to the normal system or the standby system of the Web AP server pair.

  The active server 123 detects a failure when the Web server program 100 communicates with the Web AP server program or receives a processing decline notification from the Web AP server program. It is updated to the character string shown. This reduces the number of times that the Web server program 100 communicates with the Web AP server program that cannot perform request processing as much as possible. This table can obtain the normal network address 121, the standby network address 122, and the active server 123 from the Web AP server pair ID. The entry of this table is typically given by the Web site 505 administrator when the Web server program 100 is started.

  FIG. 6 shows the structure of the server pair status management table 402 created on the secondary storage 401 of the DBMS computer 513 via the DBMS program 400. The server pair status management table 402 is a relational database table managed by the DBMS program 400, and has a Web AP server pair ID 410 and a server pair status 411. The normal or standby Web AP server program sends the SQL that updates or references the server pair status 411 to the DBMS using the Web AP server pair ID 410 as a key, and as a result, the corresponding entry in this table is manipulated. The This table is created by the Web site manager 505 before starting the Web AP server pair. The value stored in the server pair status 411 is a character string indicating that only the normal Web AP server program 200 is operating, which is a character string indicating that the Web AP server pair is operating normally. Is either a normal system independent operation or a standby system single operation that is a character string indicating that only the standby Web AP server program 300 is operating.

  FIG. 16 shows a configuration of a session ID 930 issued to the Web browser 504 by the Web AP server program. The session ID 930 includes an ID for uniquely identifying session information within the Web AP server pair and a Web AP server pair ID for uniquely identifying the Web AP server pair. In the Web server program, the Web AP server pair ID is acquired from the session ID 930 included in the HTTP request, and the Web AP server pair to which the request is to be transferred is determined.

  FIG. 7 shows a PAD diagram of request selection transfer processing that is executed each time the Web server program 100 receives a request. In this process, it is determined whether or not to transfer the request based on the URL of the request, and when performing the transfer, the transfer destination Web AP server pair is determined, and the latest request process is determined from the determined pair. Transfer the request to the Web AP server program that was executed. Also, when an error occurs during request transfer or when a processing decline notification is received as a response from the Web AP server program, the request is transferred to the other pair of Web AP server programs.

  (Step 130) The Web server program 100 refers to the URL of the HTTP request 901 received from the Web browser 504, and the URL matches the URL pattern 110 of the entry registered in the transfer destination Web AP server pair group determination table 102. Check to see if. If there is an entry having a matching URL pattern 110, step 131 is executed. If there is no entry having the matching URL pattern 110, step 132 is executed.

  (Step 131) The Web server program 100 obtains the server pair ID of the Web AP server pair group of the entry having the URL pattern 110 matching the request URL from the transfer destination Web AP server pair group determination table 102, and executes Step 133. To do.

  (Step 132) Since the Web server program 100 cannot determine the transfer destination Web AP server pair group from the Web AP server pair group determination table 102, the Web server program 100 returns an HTML file or an image file corresponding to the URL to the Web browser. Since this process is a process provided in a general-purpose Web server, a description thereof will be omitted.

  (Step 133) The Web server program 100 determines whether or not the received HTTP request 901 includes a session ID 930. If session ID 930 is included, step 134 is executed. If session ID 930 is not included, step 136 is executed.

  (Step 134) The Web server program 100 determines whether one of the one or more Web AP server pair IDs obtained in Step 131 matches the Web AP server pair ID included in the session ID 930 obtained in Step 133. To do. If they match, step 135 is executed. If they do not match, step 136 is executed.

  (Step 135) The Web server program 100 sets the Web AP server pair having the Web AP server pair ID matched in Step 134 as the transfer destination Web AP server pair, and executes Step 137.

  (Step 136) The Web AP server program 100 randomly selects one or more Web AP server pair IDs obtained in Step 131 and selects the Web AP server pair having that ID as the transfer destination Web AP server. Set as a pair.

  (Step 137) The Web server program 100 determines whether the ID of the transfer destination Web AP server pair determined in Step 135 or 136 matches the Web AP server pair ID 120 of the entry registered in the Web server pair definition table 103 Investigate. If they match, step 138 is executed. If they do not match, step 139 is executed.

  (Step 138) The Web server program 100 obtains the active server 123 of the entry having the Web AP server pair ID 120 that matches the ID of the transfer destination Web AP server pair from the Web AP server pair definition table 103, and executes Step 140.

  (Step 139) Since there is no entry corresponding to the transfer destination Web AP server pair, the Web server program 100 ends the request processing with an error.

  (Step 140) The Web server program 100 repeats the processing from Step 141 to Step 147 until the request is transferred to both the normal Web AP server program 200 and the standby Web AP server program 300. However, if the request is successfully transferred during execution of this loop, the process exits from this loop and executes step 148.

  (Step 141) The Web server program 100 obtains the active server 123 of the entry having the Web AP server pair ID 120 that matches the ID of the transfer destination Web AP server pair. If the value of the active server is normal, the request is transferred to the normal network address of the matched entry. If the value of the active server is standby, the request is transferred to the standby network address of the matched entry. To do. Then, after transferring the request, step 142 is executed.

  (Step 142) If an error occurs during the transfer of the request, the Web server program 100 executes Step 143. If no error has occurred, step 144 is executed.

  (Step 143) If the active server of the entry obtained in Step 138 is a normal system, the Web server program 100 sets the active server of the entry as a standby system, and the active server of the entry obtained in Step 138 is the standby system. If so, the active server of the entry is set to the normal system and the process returns to the top of the loop.

  (Step 144) The Web server program 100 waits to receive a response from the Web AP server program that has transferred the request, and executes Step 145 if an error occurs at the time of reception. If a response from the Web AP server program is received, step 146 is executed.

  (Step 145) Since the request processing may have been performed by the Web AP server program to which the request has been transferred first, the Web server program 100 ends the request processing with an error in order to avoid double processing.

  (Step 146) If the response received from the Web AP server program is a processing decline notification, the Web server program 100 executes Step 143. If it is not a processing decline notification, step 147 is executed.

  (Step 147) The Web server program 100 returns the HTTP response 902 received from the Web AP server program to the Web browser 504, exits the loop of Step 140, and executes Step 148.

  (Step 148) If the Web server program 100 does not return an HTTP response 902 to the Web browser at this time, it executes Step 149. If the reply has been made, the request selection transfer process 101 ends.

  (Step 149) The Web server program 100 returns an error to the Web browser 504.

  FIG. 8 shows a PAD diagram of the normal system initialization process 201 executed when the normal Web AP server program 200 is started. In this process, until the connection with the standby Web AP server program 300 is established, transmission of the connection establishment request 911 to the standby Web AP server 300 is repeated, and once the connection is established, the server pair in the server pair status management table 402 The values of the status 411 and the server pair status cache 208 are updated to normal operation.

  (Steps 210 and 211) The normal Web AP server program 200 repeatedly transmits a connection establishment request 911 until a connection with the standby Web AP server program 300 is established. If the connection is established, step 212 is executed.

  (Step 212) When the normal Web AP server program 200 establishes the connection, it determines that it can operate normally, and updates the server pair status 411 for updating the server pair status 411 of the server pair status management table 402 to normal operation. SQL921 is transmitted to the DBMS program 400 and step 213 is executed.

  (Step 213) When an error occurs in communication with the DBMS program 400, the normal Web AP server program 200 executes Step 214. If no error occurs, step 215 is executed.

  (Step 214) Since the normal Web AP server program 200 could not update the server pair status 411 of the server pair status management table 402, the initialization processing fails and ends with an error.

  (Step 215) The normal Web AP server program 200 updates the value of the server pair status cache 208, which is the cache of the server pair status 411 in the server pair status management table 402, to normal operation, and performs normal system initialization processing 201. finish.

FIG. 9 shows a PAD diagram of the standby system initialization process 301 that is executed when the standby Web AP server program 300 is activated. In this process, until the connection with the normal Web AP server program 200 is established, reception of the connection establishment request 911 is awaited. When the connection is established, the value of the server pair status cache 208 is updated to normal operation.
Through the normal system initialization process 201 and the standby system initialization process 301 described above, a connection between the normal system Web AP server program 200 and the standby system Web AP server program 300 is established, and preparations for normal operation are made.

  FIG. 17 shows a PAD diagram of processing when the normal Web AP server program 200 receives the HTTP request 901. When the normal Web AP server program 200 receives the HTTP request 901 from the Web server program 100, it first executes the session information invalidation request transmission process 202, and then executes the application execution process 203 and the duplicate request transmission to the session information. Processing 204 is executed.

  FIG. 18 shows a PAD diagram of processing when the standby Web AP server program 300 receives the HTTP request 901. When the standby Web AP server program 300 receives the HTTP request 901 from the Web server program 100, the standby Web AP server program 300 first executes the takeover determination process 307 and then executes the application execution process 203.

  FIG. 10 shows a PAD diagram of the session information invalidation request transmission process 202 that is executed first after the normal Web AP server program 200 receives a request.

  (Step 260) The normal Web AP server program 200 refers to its own server pair status cache 208, and if the value is a normal single operation, executes the step 261. Otherwise, step 262 is executed.

  (Step 261) Since the normal Web AP server program 200 is in an independent operation state, there is no need to communicate with the standby system. Therefore, the session information invalidation request transmission process 202 ends normally.

  (Step 262) The normal Web AP server program 200 refers to its own server pair status cache 208, and if the value is a stand-alone independent operation, executes the step 263. Otherwise, step 264 is executed.

  (Step 263) Since the normal Web AP server program 200 is being stopped and cannot process the request, the normal Web AP server program 200 transmits a processing decline notice 903 to the Web server program 100 and interrupts the request processing.

  (Step 264) The normal Web AP server program 200 determines whether or not the received HTTP request 901 includes a session ID 930. If session ID 930 is included, step 265 is executed. If session ID 930 is not included, step 266 is executed.

  (Step 265) The normal Web AP server program 200 acquires the session ID 930 included in the HTTP request 901, and executes Step 267.

  (Step 266) Since the normal Web AP server program 200 does not include the session ID 930 in the HTTP request 901, it issues a new session ID 930, creates new session information, and executes the session information invalidation request transmission processing 202. finish.

  (Step 267) The normal Web AP server program 200 determines whether the session information corresponding to the session ID 930 acquired in Step 265 is on the memory of the normal Web AP server program. If it is on the memory, step 268 is executed, and if not, step 269 is executed.

  (Step 268) The normal Web AP server program 200 includes the session ID 930 acquired in Step 265 in the session information invalidation request 912, transmits the request to the standby Web AP server program 300, and executes Step 270. .

  (Step 269) The normal Web AP server program 200 includes the session ID 930 acquired in Step 265 in the session information acquisition request 917, transmits the request to the standby Web AP server program 300, and executes Step 270.

  (Step 270) When the normal Web AP server program 200 fails to transmit the session information invalidation request 912 or the session information acquisition request 917, the normal Web AP server program 200 executes the active server determination processing 206 and then executes Step 262. If the transmission is successful, step 271 is executed.

  (Step 271) The normal Web AP server program 200 receives a response from the standby Web AP server program 300. If an error occurs during reception, step 262 is executed after the active server determination process 206 is executed. If the reception is successful, the session information invalidation request transmission process 202 ends normally.

  (Step 272) The normal Web AP server program 200 determines whether the response received from the standby Web AP server program 300 is the session information acquisition response 918. If the response is the session information acquisition response 918, the normal Web AP server program 200 executes Step 273. If it is not the session information acquisition response 918, the session information invalidation request transmission process 202 is terminated.

  (Step 273) The normal Web AP server program 200 acquires the session included in the received session information acquisition response 918 and stores it in the memory. Then, the session information invalidation request transmission process 202 ends.

  FIG. 11 shows a PAD diagram of the session information invalidation processing 302 that is performed when the standby Web AP server program 300 receives the session information invalidation request 912 or the session information acquisition request 917 from the normal web AP server program 200. Show.

  (Step 320) The standby Web AP server program 300 determines whether the received request is a session information invalidation request 912 or a session information acquisition request 917. If it is a session information invalidation request 912, step 321 is executed, and if it is a session information acquisition request 917, step 325 is executed.

  (Step 321) The standby Web AP server program 300 acquires the session ID 930 included in the session information invalidation request 912 received from the normal Web AP server program 200, and executes Step 322.

  (Step 322) The standby Web AP server program 300 searches for session information having the acquired session ID 930, deletes the session information, and executes Step 323. If the session information is not found, step 323 is executed without doing anything.

  (Step 323) The standby Web AP server program 300 transmits a session information invalidation response 913 to the normal Web AP server program 200.

  (Step 324) If an error occurs during transmission of the session information invalidation response 913, the standby Web AP server program 300 executes the active server determination process 206.

  (Step 325) The standby Web AP server program 300 acquires the session ID 930 included in the session information acquisition request 917 received from the normal Web AP server program 200, and executes Step 326.

  (Step 326) The standby Web AP server program 300 searches for session information having the acquired session ID 930, acquires the session information, and executes Step 327.

  (Step 327) The standby Web AP server program 300 includes the session information acquired in Step 326 in the session information acquisition response 918, transmits it to the normal Web AP server program 200, and executes Step 328.

  (Step 328) If an error occurs during transmission of the session information acquisition response 918, the standby Web AP server program 300 executes the active server determination process 206 and executes Step 329. If no error has occurred, step 329 is executed.

  (Step 329) The standby Web AP server program 300 deletes the session information acquired in Step 326.

  After receiving the request, the normal Web AP server program 200 executes the session information invalidation request transmission process 202, and then executes the application execution process 203. Since this process is a process included in the general-purpose Web AP server program, details are omitted.

  FIG. 12 shows a PAD diagram of the session information duplex request transmission process 204 for the normal Web AP server program 200 to duplex the session information used by the application in the request process after the application execution process.

  (Step 230) The normal Web AP server program 200 includes the session information used for request processing and the session ID 930 in the session information duplex request 914 and transmits it to the standby Web AP server program 200, and executes Step 231. .

  (Step 231) If an error occurs in the transmission of the session information duplex request 914, the normal Web AP server program 200 executes step 232 after executing the active server determination process 206. If no error occurs, step 234 is executed.

  (Step 232) The normal Web AP server program 200 refers to its own server pair status cache 208, and if the value is a stand-alone independent operation, executes the step 233.

  (Step 233) Since the normal system Web AP server program 200 is being stopped and cannot process the request, the normal Web AP server program 200 transmits a processing decline notice 903 to the Web server program 100 and interrupts the request processing.

  (Step 234) The normal Web AP server program 200 receives the session information duplex response 915. If an error occurs while waiting for reception, an active server determination process 206 is executed. After receiving the session information duplexing response 915, the session information duplexing request transmission process 204 ends normally.

  FIG. 13 is a PAD diagram of the session information duplexing process 304 performed when the standby Web AP server program 300 receives the session information duplexing request 914 from the normal system Web AP server program 200.

  (Step 330) The standby Web AP server program 300 acquires the session information and the session ID 930 included in the session information duplex request 912 received from the normal Web AP server program 200, and executes Step 331.

  (Step 331) The standby Web AP server program 300 associates the session information acquired in Step 330 with the acquired session ID 930 and stores it in the memory.

  (Step 332) The standby Web AP server program 300 transmits a session information duplex response 913 to the normal Web AP server program 200.

(Step 333) If an error occurs during transmission of the session information duplex response 913, the standby Web AP server program 300 executes the active server determination process 206.
FIG. 14 is a PAD diagram of the active server determination process 206 that is executed when the normal Web AP server program 200 and the standby Web AP server program 300 detect a communication error.

  (Step 240) The Web AP server program transmits a server pair status reference SQL 921 to the DBMS program 400 in order to acquire the server pair status 411.

  (Step 241) If an error occurs during transmission of the server pair status reference SQL 922, the Web AP server program executes Step 242. If no error has occurred, step 243 is executed.

  (Step 242) Since the Web AP server program cannot communicate with the DBMS program 400, the server operation is stopped as a single operation of the Web AP server program paired with its own server pair status cache 208.

(Step 243) The Web AP server program receives the server pair status 411.
(Step 244) If an error occurs when receiving the server pair status 411, the Web AP server program executes Step 242.

  (Step 245) The Web AP server program executes Step 246 if the Web AP server program in which the received server pair status 411 is paired is operating alone. Otherwise, execute step 247.

  (Step 246) The Web AP server program determines that the paired Web AP server program has previously accessed the server pair state 411, and sets its own server pair state cache 208 as a single operation of the paired Web AP server program. It stops operating.

  (Step 247) The Web AP server program sends a server pair update SQL 921 for setting the server pair state 411 to its own independent operation to the DBMS program 400.

  (Step 248) If an error occurs during transmission of the server pair status reference SQL 921, the Web AP server program executes Step 242.

  (Step 249) The Web AP server program updates its own server pair status cache 208 to its own operation.

  FIG. 15 is a PAD diagram of the handover determination process 307 that is executed first when a request is received in the standby system.

  (Step 340) The standby Web AP server program 300 refers to its own server pair status cache 208, and if the value is a stand-alone independent operation, executes Step 341. Otherwise, step 342 is executed.

  (Step 341) Since the standby Web AP server program 300 is already ready to execute the request processing, the takeover determination processing 307 is normally terminated.

  (Step 342) The standby Web AP server program 300 refers to its own server pair status cache 208, and if the value is normal normal operation, executes Step 343. Otherwise, step 344 is executed.

  (Step 343) Since the standby Web AP server program 300 is being stopped and cannot process the request, the standby Web AP server program 300 transmits a processing decline notice 903 to the Web server program 100 and interrupts the request processing.

  (Step 344) The standby Web AP server program 300 transmits an operation confirmation message 916 to the normal Web AP server program 200 and executes Step 345 in order to confirm the operation of the normal Web AP server program 200. To do.

  (Step 345) If an error occurs when the operation confirmation message 916 is transmitted, the standby Web AP server program 300 executes the operation server determination processing 206, and then executes Step 346. If no error occurs, step 347 is executed.

  (Step 346) The standby Web AP server program 300 refers to its own server pair status cache 208, and if the value is a stand-alone independent operation, executes Step 341. Otherwise, step 343 is executed.

  (Step 347) The standby Web AP server program 300 receives the operation confirmation message 916 transmitted from the normal Web AP server program 200, and executes Step 348.

  (Step 348) If an error occurs when receiving the operation confirmation message 916, the standby Web AP server program 300 executes the operation server determination processing 206, and then executes step 346. If no error occurs, step 349 is executed.

  (Step 349) Since the standby Web AP server program 300 has confirmed that the Web AP server pair is operating normally, it determines that it cannot execute the request processing by itself. Therefore, a processing decline notice 903 is transmitted to the Web server program 100, and the request processing is interrupted.

  The normal system reconnection process 207 can be realized by the same process as the normal system initialization process 201, and the standby system reconnection process 308 can be realized by the same process as the standby system initialization process 301.

  According to the embodiment described above, two problems to be solved by the present invention are solved. That is, regardless of the timing of the failure of the normal Web AP server, the user's processing can be continued as much as possible while guaranteeing that the standby Web AP server does not refer to old session information.

  If a failure occurs in communication between the normal Web AP server and the standby Web AP server, ensure that either one of the normal Web AP server and the standby Web AP server is not inconsistent. The method that only the Web AP server continues to operate can be realized by software alone.

  In the present embodiment, the failover processing method in which the standby server program takes over the processing in the event of a failure of the normal server program has been described with the redundant configuration of the server program including the normal system and the standby system. In particular, during normal operation, every time a normal server program request is processed, the data on the memory used in the request processing is duplicated on the memory of the standby server program, and if any server fails, It is possible to provide a failover processing method that takes over processing as much as possible while ensuring that old data is not referenced.

  In this embodiment, in order to solve the problem, when the session information duplicated on the memory of the normal Web AP server and the standby Web AP server becomes old, the old data is invalidated in advance. To do. When invalidating data, the data may be deleted, a flag or identifier indicating that the data is invalid may be added to the data, and access to the data may be restricted. Alternatively, other methods may be used.

  Specifically, before starting the request processing on the normal Web AP server, request the standby Web AP server to invalidate the backup of the session information to be updated on the normal Web AP server, and wait accordingly The backup of session information is invalidated on the Web AP server. As a result, the session information is not duplicated between the start of request processing on the normal Web AP server and the session information is duplicated on the standby Web AP server after request processing. Session information with different contents does not exist between the server and the standby Web AP server.

  In addition, when a failure occurs in communication between the normal Web AP server and the standby Web AP server, when both servers detect the failure, they perform exclusive access to a specific record in the database, The server that can access the server will continue to operate, and the server that accessed later will voluntarily stop. As a result, it is possible to ensure that only one of the servers can continue to operate with only software when a communication failure occurs.

  In this embodiment, the failover processing method uses a normal server and a standby server, and the normal server receives the first request and uses the first request to process the first request. Read the first session information, copy and store the first session information in the storage device of the standby server, and start the processing of the second request when the normal server receives the second request The first session information stored in the storage device of the standby server can be invalidated before.

  According to this embodiment, regardless of the timing at which a failure occurs in the Web application server, it becomes possible for the Web application server that takes over the processing to continue request processing without using old session information. Moreover, even if a failure occurs in communication between Web application servers for duplicating session information, request processing can be continued without using old session information.

It is an example of the detailed figure of the system configuration in the Web site 500 of a present Example. It is an example of the system block diagram of a present Example. It is an example of a schematic diagram of a system configuration in the website 500 of the present embodiment 5 is an example of a configuration diagram of a Web AP server pair group determination table 102. FIG. 5 is an example of a configuration diagram of a Web AP server pair definition table 103. FIG. 5 is an example of a configuration diagram of a server pair status management table 402. FIG. 10 is an example of a PAD diagram of request selection transfer processing 101. FIG. FIG. 11 is an example of a PAD diagram of normal system initialization processing 201. FIG. 10 is an example of a PAD diagram of standby system initialization processing 301; 10 is an example of a PAD diagram of session information invalidation request transmission processing 202. FIG. 10 is an example of a PAD diagram of session information invalidation processing 302. FIG. FIG. 10 is an example of a PAD diagram of session information duplex request transmission processing 204; FIG. 11 is an example of a PAD diagram of session information duplex processing 304; FIG. 11 is an example of a PAD diagram of an active server determination process 206. FIG. 10 is an example of a PAD diagram of takeover determination processing 307; It is an example of a block diagram of session ID930. It is an example of a PAD diagram of processing when a normal Web AP server program 200 receives a request. 6 is an example of a PAD diagram of processing when a request is received by the standby Web AP server program 300. FIG.

Explanation of symbols

100 ... Web server program, 101 ... Request selection transfer processing, 102 ... Transfer destination Web AP server pair group determination table, 103 ... Web AP server pair definition table, 200 ... Normal Web AP server program, 201 ... Normal initialization processing 202 ... Session information invalidation request transmission processing, 203 ... Application execution processing, 204 ... Session information duplication processing, 205 ... Operating state monitoring processing, 206 ... Active server determination processing, 207 ... Normal system reconnection processing, 208 ... Server pair State cache, 300 ... Standby Web AP server program, 301 ... Standby system initialization processing, 302 ... Session information invalidation processing, 304 ... Session information duplex processing, 307 ... Takeover determination processing, 308 ... Standby system reconnection processing, 400 ... DBMS program, 401 ... Secondary storage device, 402 ... Server pair status management table, 500 ... Web site, 501 ... Network, 502 ... Terminal device, 503 ... Homepage browsing 504 ... Web browser, 505 ... Web site administrator, 510 ... Web server computer, 511 ... Normal Web AP server computer, 512 ... Standby Web AP server computer, 513 ... DBMS computer

Claims (12)

A failover processing method using a normal server and a standby server,
The normal server receives the first request, reads the first session information used in the processing of the first request, and copies the first session information to the storage device of the standby server. Store and
When the normal server receives the second request, the first session information stored in the storage device of the standby server is invalidated before starting the processing of the second request. A failover processing method characterized by the above.   The online processing system consisting of a web server, web application server, and database is configured to operate at least one pair of normal web application server and standby web application server, and each request processing in the normal web application server. This is a failover processing method in which session information in the memory used for request processing is duplicated in the memory of the standby Web application server, and the standby Web application server takes over the processing when a normal Web application server fails. Before starting the request processing of the normal web application server, the session information in the memory of the standby web application server corresponding to the session information used in the request processing is invalidated. Eiruoba processing method.   3. The failover processing method according to claim 2, wherein the normal Web application server specifies a session ID of session information used in request processing before the request processing starts, and requests the standby Web application server to invalidate session information. Session information invalidation request transmission step for transmitting session information, and when the standby Web application server receives the session information invalidation request, the session information having the session ID specified in the session information invalidation request A session information invalidation step for invalidating the session information from the memory of the standby Web application server.   4. The failover processing method according to claim 3, wherein if there is no session information used for request processing before the request processing is started, the normal Web application server specifies a session ID required for request processing, and the standby Web application server. A session information acquisition request transmission step of transmitting a session information acquisition request to the application server, and when the standby Web application server receives the session information acquisition request, the session ID specified in the session information acquisition request A failover processing method comprising: a session information recovery step of invalidating from the memory of the standby Web application server after transmitting session information having a message to the normal Web application server.   5. The failover processing method according to claim 4, wherein the standby Web application server performs request processing when a request is transferred from the Web server even though the normal Web application server is operating. A failover processing method characterized by transmitting a processing decline notification to notify the web server to decline.   6. The failover processing method according to claim 5, wherein the Web server determines a pair of normal Web application server and standby Web application server to which the request should be transferred based on a destination of a request received from a client. When a request is transferred to one of the Web application servers of the pair determined in the pair determination step and the request transfer destination pair determination step, and the transfer fails or a processing decline notification is returned, the other A failover processing method comprising a transfer destination switching step of transferring a request to a Web application server.   7. The failover processing method according to claim 6, wherein when one of the normal system web application server and the standby system web application server is operating and then restarted, the other web application is restarted. Failover processing method characterized in that the normal system web application server and the standby system web application server have a session information duplex recovery step for transmitting all non-duplexed session information from the server to the restarted web application server .   The online processing system consisting of a web server, web application server, and database is configured to operate at least one pair of normal web application server and standby web application server, and each request processing in the normal web application server. This is a failover processing method in which the session information in the memory used for request processing is duplicated in the memory of the standby Web application server, and when the normal Web application server fails, the standby Web application server takes over the processing. When a failure occurs in communication for duplication of session information between the Web application server and the standby Web application server, the normal Web application server and the standby Web application server When a communication failure is detected, exclusive access is made to a specific record in the database, the web application server that can access the record first continues to run, and the web application server that accessed later stops running. A failover processing method characterized by executing an active server determination process.   9. The failover processing method according to claim 8, wherein when the normal Web application server and the standby Web application server are to be stopped in the active server determination process, the Web server and the standby Web application server are A failover processing method characterized by transmitting a processing decline notification notifying that a request processing is declined to the Web server without performing the request processing on the transferred request.   10. The failover processing method according to claim 9, wherein the standby Web application server performs request processing when a request is transferred from the Web server even though the normal Web application server is operating. A failover processing method characterized by transmitting a processing decline notification to notify the web server to decline.   11. The failover processing method according to claim 10, wherein the Web server determines a pair of a normal Web application server and a standby Web application server to which the request should be transferred based on a request destination received from a client. When the request is transferred to one of the Web application servers of the pair determined in the determination step and the request transfer destination pair determination step and the transfer fails or a processing decline notice is returned, the other Web A failover processing method comprising a transfer destination switching step of transferring a request to an application server. 12. The failover processing method according to claim 11, wherein when one of the normal system web application server and the standby system web application server is operating and then restarted, the other web application is restarted. Failover processing method characterized in that the normal system web application server and the standby system web application server have a session information duplex recovery step for transmitting all non-duplexed session information from the server to the restarted web application server .

Images