JP2004536406A - Method and apparatus for session replication and failover - Google Patents

Abstract

The system according to the present invention can utilize a primary server to respond to requests from network clients, such as web browsers. The primary server can be selected from a group of servers or a group of servers. Once the primary server has been selected, client requests can be served on that primary server. A secondary session server can then be selected, for example, by the primary server. When the primary server responds to the request, information about the session is sent from the primary server to the secondary session server.
Also, the system can utilize load balancing using either hardware or software. Attempts are made to fulfill the request on the primary server, and if the primary server cannot receive or respond to the request, the request can be fulfilled on the secondary application server. If the secondary server receives the request, that secondary server becomes the new primary server. To maintain redundancy, a new secondary server can be selected and session information can be sent from the new primary server.

Description

【Technical field】
[0001]
The present application relates generally to data replication, and in particular, to providing redundancy for client network sessions.
[0002]
(Priority claim)
This application is related to U.S. Provisional Patent Application No. 60 / 305,992, entitled "Method and Apparatus for Servlet Session Replication and Failover," filed July 16, 2001, which is incorporated herein by reference. U.S. Patent Application 10 / 000,708, filed October 31, 2001, entitled "Method and Apparatus for Session Duplication and Failover," filed on July 16, 2001, entitled "Hardware for Servlet Session Duplication. U.S. Provisional Patent Application No. 60 / 305,969 entitled "Apparatus for Balancing Hardware Load", filed on October 31, 2001, entitled "Apparatus for Balancing Hardware Load for Session Duplication". Claims priority based on US patent application Ser. No. 10 / 000,709.
[0003]
(Copyright notice)
Part of the disclosure of this patent document contains material subject to copyright protection. To the extent that this Patent Document or Patent Disclosure appears in the Patent and Trademark Office patent documents or records, the copyright holder will not object to its reproduction by any person, but All rights reserved.
[Background Art]
[0004]
When a client connects to a server over a network and initiates a session, there may be information specific to that client session stored on the server. For example, suppose a client user places an item in a virtual shopping basket. The selection of the items can be stored at least temporarily on the server. In this example, no other users or servers need to access this information. However, it is desirable that this data be highly available across a network or a group of servers so that if the server storing the session data fails, data on other servers can be retrieved. .
[0005]
One way to perform data recovery in such a situation is to store the information in a database during the session, but it may also be stored by other means, such as a data file. I may be able to do it. The latest information is written to the database whenever session data is changed so that any server that has access to the database can access the data. The data is stored in a permanent location and can be easily retrieved by other servers.
[0006]
However, there is a problem with this approach in that retrieving session information from the database for each request is quite costly. Since the throughput of the system can depend on the number of connections from the server to the database, multiple hits to the database can create failures and get stuck in a system down, which is essentially an inoperable point . These sessions can also include a form of information that users want to access immediately. With several applications, thousands of clients can run simultaneously, which results in thousands of parallel execution sessions. It is desirable for some servers to host many different applications, which further increases the number of sessions that may need to be hosted by those servers.
[0007]
It is desirable to increase the speed and efficiency of such a system so that these tens of thousands of users can use the system effectively. One way to avoid such failures is to assume that the server is up and running for 99.9% of the time and simply does not back up any information. This can be the solution to provide the fastest user experience, but even 0.1% downtime resulting in data loss is unacceptable to many users.
[0008]
(wrap up)
The system according to the present invention can utilize a primary server to respond to requests from network clients, such as web browsers. The primary server can be selected from a group of servers or a group of servers. Once the primary server has been selected, client requests can be served on that primary server. A secondary session server can then be selected, for example, by the primary server. When the primary server responds to the request, information about the session is sent from the primary server to the secondary session server. This may be the complete sequence of information in the first request on the session, or simply an update to existing information in the session in response to subsequent requests. Information identifying the primary and secondary servers can be stored on the client, for example, a "token" stored as a cookie, or at the top of a standard RMI in a manner similar to a transaction or security context. Can be passed. This identification or "token" can accompany each request.
[0009]
The system can utilize load balancing using either hardware or software. In a process that becomes useful with software balancing, a request can be received on a session where the primary and secondary session servers have already been selected. An attempt is made to fulfill the request on the primary server. If the primary server cannot receive or respond to the request, the request can be fulfilled on the secondary application server. If the secondary server receives the request, that secondary server becomes the new primary server. To maintain redundancy, a new secondary server can be selected and session information can be sent from the new primary server.
[0010]
In a process that is useful with a hardware load balancer, a primary and secondary session server receives a request on a selected session. Next, an attempt is made to respond to the request on the primary server. If the primary server cannot receive or respond to the request, instead of using a secondary session server, the hardware load balancer selects a new primary server and On the primary server. The session information can be sent from the secondary session server to the new primary server, for example, in response to a request from the new primary server. The new primary server can then respond to the request and send the updated session information to the secondary server, causing the server to synchronize for that session.
[0011]
(Detailed description of the invention)
The present invention overcomes many of the deficiencies of conventional replication systems. In one system according to an embodiment of the invention, a session is created when a client makes a request to a server on a network such as a LAN, Ethernet, or the Internet. The session server that receives the request may be from any server used to store information in the session and / or create a response to the session request, such as an application server, web server, object server, or servlet engine. Can be configured. The server that ultimately receives the request is the "primary" server, that is, the server to which the client sends subsequent requests. The system can then select a "secondary" server for the session, which will act as a source of redundancy.
[0012]
Each time an update is made during the session, the changes can be stored on the primary server as well as sent to the secondary server, for example, by a remote call. Not all of the session data need be sent to the secondary server each time a change is made, but only the changed data or information can be sent, for example, in information differences or packets. Sending the minimum required information as a difference can increase the efficiency of the entire system. The replica behaves like mirroring, except for the fact that it operates on session data. In one example, this mirroring can be performed for a web application using a servlet engine.
[0013]
When a client connects to a server, a session object associated with the client or user is created. The session object can be kept on the primary server for the duration of the session, or it can time out after a specified amount of time. Each session object can be given a unique identifier or identification number to identify the client and / or object to the server. The server selected to service the request can act as the primary server for the duration of the session. The primary server can select a secondary server for the session object, so that each time the object is updated, the updates are also stored on the secondary server. To increase the efficiency of the system, the secondary server can be optimized to receive only minimal information or perform bulk updates.
[0014]
One web-based system 100 according to one embodiment of the present invention is shown in FIG. In this system, a browser 102 or client makes a request that is received by a web server 104. Web server 104 acts as a proxy in that web server 104 views the request and determines which object server 110 should receive the request. The web server can have a plug-in or a plug-in API, which is aware of the request. Plug-ins are generally objects added to an application to provide additional functionality without having to launch any external applications. The plug-in makes a load balancing decision to select between the object servers 110 available to create and house sessions at the client 102. Web server 104, in turn, acts as a proxy to selected object server 110, which can be hosted on application server 106. A servlet engine 108 in the application server 106 can execute a servlet that calls an object on the object server 110 to respond to the request. To fully respond to the request, object server 110 may also need to retrieve information from database 112 or data storage. The object server 110 can create a session when receiving a request. As is well known and used by those skilled in the art, the application server 106 and database can be located across a firewall 114 to provide security.
[0015]
In this example, the object server then selects a secondary server for the session. In an alternative embodiment, a plug-in can be used to select a secondary server. The plug-in can also use load balancing for that determination.
[0016]
The object server passes the data to the secondary server and informs the secondary server that it will be backed up. The object server then creates a cookie that is sent and stored to the client. The cookie contains an identification of the primary and secondary servers used in the session.
[0017]
When a client sends subsequent requests on the same session, it does not matter which web server receives the request at all. The web server looks at the cookie to determine the primary server in the session and then delivers the request to that primary server.
[0018]
Assume an example, as shown in FIG. 3, having three servlet engines 306, 308, and 312 each capable of acting as a primary server. If the session is currently running on the primary server 306, but the primary server 306 is not functioning, the web server 304 checks which cookie information is sent with the request from the browser 302 to determine which server You can determine if you have been selected as a server. The web server can then attempt to send the request to the secondary server 308, which also includes the session state information 310. The web server can return a response to the browser 302, which will make another request that can be sent by the web server 304 to the secondary server 308. The secondary server 308 knows that if the primary server 306 fails to accept the request, it knows only that it will receive the request directly from the web server, so if the secondary server receives the request, Can automatically become the new primary server. At this point, the secondary server 308 becomes the primary server 308 and a new secondary server 312 can be selected. Alternatively, the plug-in to web server 304 may select a new secondary server 312. One potential location of communication loss is indicated by a first virtual boundary 314, which exists between the browser / client 302 and the web server 304. A second virtual boundary exists between the web server 304 and the servlet engines 306, 308, and 312.
[0019]
In some embodiments, a secondary or web server spontaneously monitors the primary server to determine the status of the primary server. This monitoring can be performed in any suitable manner, such as, for example, "pinging" the primary server continuously or periodically to determine if it is connected to the network. If it is determined that the primary server cannot accept the request, the secondary server can become the new primary server. Then a new secondary server can be selected. The advantage of such a design is that the downtime that dual server failure may result in loss of session state is reduced. In some embodiments, the gap can be defined by the rate of client requests, while this approach allows the gap to be defined by the rate of pinging the server.
[0020]
The new primary and secondary servers are also responsible for information about the session. The server that was previously the primary server can no longer have any responsibilities or information in the session, even though the server can still accept and process requests while the session is running. The secondary server can automatically change its state, resulting in a new primary server for the session, but does not specify a new secondary server until the new primary server receives the request You can do so.
[0021]
It would not be desirable to spontaneously create a new secondary server or back up session information on the secondary server because the new primary server does not know if it will receive other requests. Creating a new secondary server or backing up information that is not used can waste resources unnecessarily. Alternatively, the session may be short lived and not "live" long enough to receive a subsequent request. Each session typically has a timeout value, so if the session does not run for the specified time, it "times out" or "disappears", the session is terminated, and All data stored in the session can be erased for memory conservation. In such cases, the creation of a secondary server may not only waste resources, but also require unnecessary "cleaning" work to erase session information from the new secondary server. Can be.
[0022]
The primary and / or secondary server can be selected by an algorithm, for example, which can have any server in a specified server cluster as an option. Selecting primary and secondary servers for each session can be efficient for the algorithm, but in some cases administrator input may be desirable. For example, there could be multiple servers on one machine. If an algorithm, such as one based on load, selects a server, the algorithm can select two servers on the same machine. In the event of a machine failure, both servers may be unavailable and session data may be unavailable and / or lost. However, the administrator can specify primary and secondary servers that reside on different machines. This can provide for redundancy not only between servers but also between machines.
[0023]
Alternatively, the parameters could be constructed in the algorithm itself, which takes into account the machine where the server is located when performing the load balancing analysis. If the currently least loaded server is on the same machine as the primary server, the algorithm can be made to be the least loaded server on another machine. This approach can be extended to any level of separation, for example, servers in different rooms, different buildings, or different cities.
[0024]
Servers can be loosely coupled to allow servers in a cluster to function independently. To perform this loose coupling, each server in the cluster spontaneously or involuntarily senses the status of other cluster servers so that when one server leaves the cluster, it can receive its actions. It can be configured to: In some embodiments, the server can rely on the underlying OS to monitor the status of the cluster server. In other embodiments, the server may request that monitoring be performed. Since server resources are available to increase the overall system throughput, embodiments that do not require the cluster server to participate in cluster monitoring may be preferred.
[0025]
FIG. 2 shows a multilayer cluster architecture 200 according to the present invention. Each object in the system can be clustered by creating an instance of the object available on several servers. This architecture has been shown to include virtual boundaries. The term "virtual boundary" means a place where a network connection can be broken.
[0026]
In FIG. 2, a first virtual boundary 212 is shown between the browser 202 and the web server 204. A second barrier 214 is shown between the web server 204 and the servlet engine 206. A third barrier 216 is shown between the servlet engine 206 and the object server 208. Finally, a fourth barrier 218 is shown between the object server 208 and the database 210. Each barrier indicates a potential point of communication loss, which may also utilize load balancing.
[0027]
In the first virtual barrier, the browser may not be able to reach a particular web server. However, this will not be a problem in the system according to the invention, since the information about the primary and secondary servers can already be stored in the cookies of the browser. The browser can indicate to the web server, via a cookie, which server should receive the request, so that it can contact any web server on the network. This system can be the most efficient on a LAN, but a similar approach can be used on any possible network. For example, the browser could contact the second web server and / or end server, which may be located in a building separate from the first web server, over the Internet.
[0028]
Depending on the application, the primary and secondary servers can be of several different server types, such as a web server, a servlet engine, or an EnterpriseJavaBean ("ejb") engine. Each server in the cluster could be more independent and specialized, e.g., of different server types, but could still operate as primary and / or secondary servers. Would.
[0029]
If clustering is possible on the system according to the invention, it will be possible to add new servers transparently to the system to operate as additional primary and secondary servers. Clustering is a server management technique that generally allows a set of servers to be managed by providing an "administrative" server within the set of servers. This approach can simplify the placement and synchronization of potentially diverse components across servers in a cluster. Clustering can substantially increase the reliability and scalability of the system.
[0030]
At the time of clustering in the system according to the present invention, each server in the cluster detects that a new server has entered the cluster and designates the new server as a secondary server to any of the existing primary servers. Can be constructed as follows. This method used for load balancing can immediately designate a new server as a primary or secondary server.
[0031]
Alternatively, the system according to the invention may utilize a hardware load balancer to route incoming requests. For example, in an Internet environment, a hardware load balancer has an IP address and can be on a network. Incoming requests from a browser or client can be sent to that IP address. The hardware load balancer then assigns the other IP addresses, i.e., each IP address, and forwards those requests to other servers in the system but located "behind" the hardware load balancer. Can be transferred. Thus, although the browser always sees the request as going to the same IP address, it can in fact go to multiple servers behind that IP address. Instead of using other methods such as software clustering, the hardware load balancer can be behind itself in the network so that it can be the result of, for example, connecting the server directly to the hardware load balancer. You can be aware of all the servers that are located.
[0032]
There may be advantages to using a hardware load balancer. Hardware load balancers can utilize better algorithms for load balancing than other approaches. The hardware load balancer can detect node failures, so that those nodes will be pulled from the list of servers available in the algorithm. This node elimination prevents the algorithm from trying to reach an unreachable server, even though no requests may have been sent to those individual servers yet.
[0033]
Rather than using a hardware load balancer to map domain names to some IP addresses, i.e., forward requests sent to a web server to some object servers, the system according to the invention also uses DNSRoundRobin's Such a DNS protocol can be used. However, DNS typically does not determine or detect whether those IP addresses are actually "live".
[0034]
A hardware load balancer has a specific format for a particular server or server cluster depending on whether the request is for dynamic page creation or whether the request is for static pages. Can be used to proxy requests. In FIG. 4, a load balancer 414 is shown between a web browser 402 and web servers 404, 408, 412.
[0035]
While it may be desirable to optimize the hardware load balancer 414 for use with the present invention, it may not be desirable to seek physical changes to the load balancer itself. Also, the hardware load balancer reads the cookie and if the first primary server 404 does not work, it is necessary to forward the request to the secondary server 408 indicated in the cookie stored on the browser 402. It would not be desirable to have to understand something. However, it would be desirable to have the load balancer send requests where desired, and then verify that the system is properly recovering.
[0036]
In one such approach, the hardware load balancer 414 tends to send a request from the browser 402 or client to a server based on some arbitrary information stored in a cookie on a web browser. . For example, a cookie can have an initial string of information, followed by a session identifier used for replication, as well as portions of information relating to primary and secondary servers. Hardware load balancer 414 can be constructed to look at only this portion of the information. If this portion of the information does not change between successive cookies, the load balancer can continue forwarding the request back to the primary server 404. Such "session stickiness" may also be based on any other suitable scheme, for example, making use of the client's IP address.
[0037]
That part of the information in the cookie can remain the same as long as the request can return to the primary server. If the primary server does not work for any reason, the secondary server can designate itself as the new primary server. The new primary server can then insert new information about the new secondary server into the segment, which can be selected by the new primary server or load balancing mechanism. Alternatively, the hardware load balancer may select a new primary server and forward the request to the new primary server.
[0038]
The first request for a session received at the load balancer cannot be tightly coded to go to essentially one server. The decision to "stick" to one server can be defined after the first request has been made and it has returned from the object server or another end server. A hardware load balancer may be sufficiently sophisticated to do this "simple stickiness", that is, essentially return to the designated primary server to which the load balancer is connected. it can.
[0039]
If no cookies are present, the hardware load balancer can be constructed to use any of a number of load balancing methods, such as based on load or response time. The load balancer can then select a server, for example, in an appropriate cluster, and send a request to that server. When the primary server responds to the request, it can send a cookie to the browser containing a piece of information about the primary and secondary servers. Each subsequent request from the browser received by the hardware load balancer may have a cookie associated with it, so that the load balancer can associate the request with the primary server.
[0040]
The system will not yet be able to guarantee that the request will go to the primary server. As shown in FIG. 4, if the primary server 404 fails and other requests enter the load balancer 414, the load balancer simply makes a different load balancing decision. , And the request can be sent to another server 412. The request cannot go to the secondary server 408. This approach differs from that described above for the plug-in approach where requests can automatically go to the secondary server. Thus, hardware load balancers, like those described above, are not "intelligent" when compared to special proxy plug-ins.
[0041]
If the server 412 selected by the load balancer 414 is not a secondary server 408, the selected server 412 can recognize that the request is a request on a session not hosted by itself. In this case, the selected server 412 can look at the cookie to determine the secondary server 408.
[0042]
Once the selected server 412 locates the secondary server 408, it can request session state information 410 from the secondary server 408. Next, the selected server 412 can turn itself into a new primary server in the session. In this case, the secondary server 408 can remain the same. The cookie is updated so that the load balancer 414 continues to direct requests to the new primary server 412.
[0043]
If the load balancer 414 decides to direct the request to a new server that happens to be the secondary server 408, the secondary server can set itself as the new primary server and create a new secondary server. A next server can be selected.
[0044]
A system with a hardware load balancer with a servlet cluster behind it can provide a high-speed data path. If the web server does the routing, the request will need to come into the software where some code is running and then be sent back over the network. It can be very fast because the load balancer / servlet cluster system does everything at the low protocol layer.
[0045]
It may be advantageous to place the load balancing algorithm as far as possible. In the case of a hardware load balancer, it may only be necessary to verify that the software on the server is working properly, such as software that can be written in Java. In a system without a hardware load balancer, one would have to make sure that each of the special plug-ins for each web server in the system was working as well.
[0046]
It will also need to support plugins for different platforms. Hardware load balancers can work equally well in systems based on different platforms such as, for example, Netscape Application Server (NAS), WebLogic Server (WLS), Microsoft Internet Information Server (IIS), or Apache HTTP Server. By using a hardware load balancer, the system can reduce complexity by one step so that one of the dikes can be eliminated. This is shown in Figure 4, where the web server and the servlet engine are in the same process.
[0047]
Some of the systems described above can utilize servlets for web access. A similar mechanism can be used to access stateful session beans or some form of EnterpriseJavaBean ("ejb"). Servlets can be used to service requests from browser clients, while ejb servers can be used to support requests from Java clients.
[0048]
In a Java client, there can be one persistent connection for the duration of a session. At that time, there will be no need (or support) for cookies. Also, since there is a persistent connection, there will no longer be a need for a load balancer. A Java client can connect to one of the end servers using, for example, DNS or a load balancer. Next, the Java client can look for a "handle" to the stateful session. Handles in Java are similar to pointers and can be used to locate the appropriate session.
[0049]
Turning to the system 500 of FIG. 5, when the Java client 502 is connected to the handle, a stateful session bean 510 can be created. The stateful session bean 510 can be used to handle caching or storing information in the session. When a stateful session bean is created, the server containing the bean can be the primary server 508, whereas the Java client 502 can make a request. The primary server 506 can then select the secondary server 510. Secondary server 510 can also have a stateful session bean 512 to cache or store session information.
[0050]
The stateful session bean 508 can return this information to the Java client 502 using the RMI protocol, similar to sending a cookie. Similar to the way transaction status propagation works, additional information can be placed at the "top" of the standard RMI to make this cookie simulation work. The primary / secondary server identifier pair can be returned to the Java client 502 with each response. Each time the Java client 502 makes a call, it can make a call through the interface 504 into special RMI code adapted to continue making calls to the primary server 506 in the session. If the primary server is inoperable, the Java client 502 can see information about the location of the secondary server 510 and can instead make a request to the secondary server. If only the essential information about server identification is returned at the top of the RMI, that would be desirable for efficiency.
[0051]
The Java client 502 can always know which server is the secondary server 510. For example, if the primary server 506 is not available, the Java client will have much of the same logic that the proxy may have, as always knowing to go to the secondary server 510 be able to. Java clients can monitor the state of the server to ensure that requests are not sent to unavailable servers. If the secondary server 510 becomes the new primary server, a newer secondary server 504 can be selected. The logic for selecting a new primary and / or secondary server may be similar to that described above. Java clients can immediately update to new primary / secondary servers.
[0052]
From the above discussion, systems in accordance with the present invention generally can follow one of two bifurcated strategies, although various variants, including those described above, may be utilized. The intersection of such a strategy is shown in FIG. In process 600 of FIG. 6, a primary server is selected 602 from a group of servers. Once the primary server is selected, client requests are serviced 604 at that primary server. Next, a secondary server is selected 606, possibly by the primary server. Next, session information is sent 608 from the primary server to the secondary server. Information identifying the primary and secondary servers can be stored 610 on the client, for example, stored in a cookie or passed on top of a standard (or other) RMI.
[0053]
In this regard, processing is divided into policies that can be useful for software load balancing and processes that can be useful for hardware load balancing. FIG. 7 shows a process 700 useful for software load balancing. At step 700, a request is received on a session for which a primary and secondary server has already been selected, and an identification of the primary server is created 702 from information stored on the client. Next, an attempt is made 704 to respond to the request on the primary server. If the primary server cannot receive the request, the request is serviced 706 on the secondary server. When the secondary server receives the request, the secondary server becomes the new primary server 708. Next, a new secondary server is selected and session information is sent 710 from the new primary server.
[0054]
Another strategy that is useful for systems with hardware load balancers is shown in FIG. In the process 800 of FIG. 8, a request is received 802 on a session where the primary and secondary servers have already been selected, and primary server identification information is created 802 from information stored on the client. Next, an attempt is made 804 to respond to the request on the primary server. If the primary server cannot service the request, the hardware load balancer selects a new primary server and attempts 806 to service the request on the new primary server. The session information is then sent 808 from the secondary server to the new server, for example, in response to a request from the new primary server. Next, the new primary server can respond 810 to the request and send the updated session information to the secondary server.
[0055]
To maintain consistency in any embodiment of the present invention, changes in session data can be associated with a version number. The primary and secondary servers can each know which version of the session it has stored. The server can be instructed to modify the data only if it receives a request with a later or higher version number than the one it is currently storing. The primary and secondary servers can periodically check with each other to make sure they are on the same version number. Version numbers can be used as simple as incrementing to guarantee order. To maintain consistency in session information, it may be desirable for the primary and secondary servers to synchronize. When the version numbers are out of sync, the primary server can decide to send all session information to the secondary server to restore session synchronization. This synchronization also facilitates the server's ability to switch roles between primary and secondary if needed.
[0056]
If the primary server cannot update the information on the secondary server, for example, due to a bad connection, the primary server will keep updating and the secondary server will not recognize any updates There could be. Then it is possible that the primary server will be several versions ahead of the secondary server. Once the primary server is able to send information to the secondary server again, the differences between two consecutive versions cannot work. In such a case, the primary server can send the entire new series of session data to the secondary server to ensure consistency of the data session between the two servers. In this case, the secondary server either gets the differences between successive versions or gets all the data for the entire session. In other embodiments, it would be possible to create a difference between any versions in order to have the secondary server reach the current version.
[0057]
In simulating cookies to track the state of Java, a large random number can be used for server identification. The number can be large enough that the sum of the identification numbers of the two different pairs is unlikely to be the same. It is possible to just send these two numbers back to the Java client, and the pair of servers can be identified by adding the two numbers to get a new number. This allows two servers to be specified by passing only one number, which can increase efficiency. Because Java clients can connect to a particular server persistently, the client obtains the secondary server's identification number by subtracting the primary server's identification number from the total number passed. The next server can be specified.
[0058]
However, Java objects, such as session beans, can have stateless or transient states, as opposed to the persistent states discussed above. If the Java session bean is stateless, the bean will not be able to maintain session information between calls or between successive requests. If the session information is stored elsewhere, the stateless bean can temporarily load the session information to satisfy the request. Failover, i.e., leaving the session control to a new primary server with duplicated session information, means that, for example, the primary server never receives a request, and the request is procedural and aborted, i.e., one-time only. It can only occur where there is an obvious call failure, such as a request. On the other hand, if the session bean is temporary, the instance can be created by a stateless factory using stateless load balancing and failover. Beans in the transient state either cannot be backed up in memory, or can be backed up using primary / secondary replication as described above.
[0059]
Bulk changes can be used to increase the throughput of a system with increased gaps in failure. During batch processing or "box transport", several requests are sent together as one large request to increase efficiency and scalability. The batching of requests can be based on any of a number of criteria, such as time intervals or number of requests. For example, the system may send a batch of requests every 10 seconds or for every 100 individual session update messages. The system can also send a batch 10 seconds after the last batch or when 100 requests have been received, meeting both criteria, both of which are first. With batch processing, the system will no longer be as reliable as synchronous updates, but it can increase the scalability of the overall system.
[0060]
The criteria may also be configurable, for example, by a user or an administrator. A configurable criterion may be suitable for situations where the system faces heavy traffic at certain times, but little traffic at other times. For example, a configurable criterion makes it possible to batch process every 100 messages during peak hours and not process batches at all during idle times, so that each request is sent in a reasonable time It becomes.
[0061]
A system administrator can also pair two servers in a cluster as primary and secondary servers. Administrator input may be desired to increase the fault tolerance of the entire system. For example, multiple servers can be located on one physical machine, and an algorithm may decide to place both primary and secondary servers on the same machine. Then, if the machine fails, the session information may be lost altogether. To prevent loss of session information from a machine failure, the administrator may decide to designate each of the primary and secondary servers on a physically separate machine. The administrator can also select the primary server based on various load balancing schemes. Examples of possible schemes are based on server load, number of connections, and physical proximity.
[0062]
The foregoing description of a more preferred embodiment of the present invention has been provided for purposes of illustration and description. It is not intended to be exhaustive or to limit the invention to the precise form disclosed. Obviously, many modifications and variations will be apparent to practitioners skilled in this art. The present embodiments have been selected and described in order to best explain the principles of the invention and its practical application, and thus those skilled in the art will recognize that various implementations may be appropriate for the particular use intended. It is possible to understand the invention in form and with various modifications. It is intended that the technical scope of the present invention be defined by the following claims and their equivalents.
[Brief description of the drawings]
[0063]
FIG. 1 is a diagram of an application server system according to an embodiment of the present invention.
FIG. 2 is a diagram of a multi-tier architecture according to one embodiment of the present invention.
FIG. 3 is a diagram of a servlet engine system according to one embodiment of the present invention.
FIG. 4 is a diagram of a load balancer system according to one embodiment of the present invention.
FIG. 5 is a diagram of a Java system according to one embodiment of the present invention.
FIG. 6 is a flowchart of a process according to an embodiment of the present invention.
FIG. 7 is a flowchart of processing of a software load balancer according to an embodiment of the present invention.
FIG. 8 is a flowchart of a process of a hardware load balancer according to an embodiment of the present invention.

Claims (74)

A system for replicating information during a client session,
b. A primary server for receiving a request during a client session, responding to the request, and further storing session information for the client session;
c. A secondary server for receiving a request during a client session, responding to the request, and further storing session information for the client session;
d. A web server that receives a request from a client including the identification information of the primary and secondary servers, processes the identification information, and responds to the process request on the primary server;
Wherein the web server further responds to the request on the secondary server if the primary server cannot process the request,
A system characterized in that: Further comprising a database in communication with the primary and secondary servers, the database storing information useful for processing requests;
The system according to claim 1. The primary server further updates the session information stored in the secondary session server each time a request is received in the client session.
The system according to claim 1. The web server further selects the primary server from a plurality of servers when an initial request is received in the client session and no identity is present on the client.
The system according to claim 1. Further comprising a cookie stored on the client, wherein the cookie includes identification of the primary and secondary servers;
The system according to claim 1. The primary server further creates the cookie on the client;
The system according to claim 5. The web server further comprising a plug-in including an algorithm used to select the primary server;
The system according to claim 1. The web server further comprising a plug-in that includes an algorithm used to send requests to the primary and secondary servers;
The system according to claim 1. The algorithm is a load balancing algorithm,
The system according to claim 7. The primary server is adapted to select the secondary server,
The system according to claim 1. Starting the client session when the primary server receives an initial request from a client;
The system according to claim 1. The secondary server further becomes a new primary server when receiving a request that the primary server could not process;
The system according to claim 1. The secondary server further selects a new secondary server and sends session information to the new secondary server;
13. The system according to claim 12. The web server selects a new secondary server,
13. The system according to claim 12. The secondary server further monitors the primary server to determine whether the primary server can receive the request;
The system according to claim 1. The secondary server further becomes a new primary server if the primary server cannot receive the request;
The system according to claim 1. One of the primary and secondary servers is selected from the group consisting of a web server, a servlet engine, and an enterprise Java bean engine;
The system according to claim 1. A system for replicating information during a Java client session,
a. A primary server that receives a request from a Java client during a client session, responds to the request, and further stores session information in the client session;
b. A secondary server that receives a request in a client session, responds to the request, and further stores session information in the client session;
c. A stateful session bean on the primary server, which retains information in the client session and is used to send identification of the primary and secondary servers back to a client;
A system comprising: Further comprising a load balancer for receiving a request from a client and selecting the primary server;
19. The system according to claim 18. The primary server further maintains a persistent connection with a Java client during the client session;
19. The system according to claim 18. The web server further sends a batch request to the primary server,
The system according to claim 1. A method for providing redundancy during a client session, comprising:
a. Making a load balancing decision on an initial request from a client during a client session to select a primary server from a plurality of session servers;
b. Responding to the request on the primary server;
c. Selecting a secondary server;
d. Sending session information in the client session from the primary server to the secondary server;
e. Updating session information on the primary and secondary servers each time a request is received in the client session;
A method comprising: Further comprising storing the information in a cookie on the client.
23. The method according to claim 22. Further comprising, if the primary server cannot process the request, responding to the request on the secondary server;
23. The method according to claim 22. Further comprising selecting a new secondary server,
25. The method according to claim 24. The method further includes a step of collectively responding to a request to the primary server,
23. The method according to claim 22. The method further includes a step of collectively sending session information in the client session from the primary server to the secondary server,
23. The method according to claim 22. Further comprising maintaining session information in a stateful session bean;
23. The method according to claim 22. Associating a version number with each update to the session information as requested.
23. The method according to claim 22. Sending session information in the client session from the primary server to the secondary server includes sending a difference in information including a change in the session information.
23. The method according to claim 22. Assigning an identification number to each of the primary and secondary servers,
23. The method according to claim 22. Adding the identification numbers of the primary and secondary servers to obtain one number representing both the primary and secondary servers,
The method of claim 31. A system for replicating information during a client session,
a. Multiple session servers,
b. Receiving the request during a client session, responding to the request, and further creating a cookie containing session information for the client session and including information about the primary server, sending the cookie to a session client. A primary server in the session server,
c. Receiving the session information from the primary server, storing the session information, further receiving a request during a client session, and responding to the request, selected by the primary server, a secondary in the plurality of session servers. Server and
d. A web server that receives a request from a client that includes the identification information of the primary and secondary servers, processes the identification information, and responds to the process request on the primary server;
Wherein the web server further responds to the request on the secondary server if the primary server cannot process the request.
A system characterized in that: A method for providing redundancy during a client session, comprising:
a. Making a load balancing decision for an initial request from a client during a client session to select a primary server from the plurality of session servers;
b. Responding to the request on the primary server;
c. Sending session information in the client session from the primary server to a secondary server selected by the primary server;
d. Storing a cookie on the session client containing information identifying the primary and secondary servers;
e. Updating session information on the primary and secondary servers each time a request is received in the client session;
A method comprising: Reading the identification information in the request received in the client session and responding to the request on the primary server.
35. The method according to claim 34. A system for replicating information during a client session,
a. Multiple session servers,
b. Receiving a request during a client session and adapting to respond to the request, further storing session information in the client session, and creating a cookie containing information about the primary server, and sending the cookie to the session client. Sending, a primary server in the plurality of session servers;
c. Receiving the session information from the primary server, storing the session information, further receiving a request during a client session, and responding to the request, selected by the primary server, a secondary in the plurality of session servers. Server and
d. Receiving an initial request from a client, sending the request to the primary server, further receiving a subsequent request from the client including identification information of the primary and secondary servers, and processing the identification information, A web server including load balancing logic for selecting the primary server responsive to the process request on a server;
Wherein the web server further responds to the request on the secondary server if the primary server cannot process the request.
A system characterized in that: A method for providing redundancy during a client session, comprising:
a. Making a load balancing decision for an initial request from a client during a client session to select a primary server from the plurality of session servers;
b. Responding to the request on the primary server;
c. Sending session information in the client session from the primary server to a secondary server selected by the primary server;
d. Storing a cookie on the session client, the cookie including information identifying the primary and secondary servers;
e. Reading the identification information received with any subsequent request during the client session and responding to the subsequent request on the primary server;
f. Updating session information on the primary and secondary servers each time a subsequent request is served on the primary server in the client session;
A method comprising: A method for providing redundancy during a client session, comprising:
a. Selecting a primary server from a plurality of session servers in response to an initial request from a client;
b. Responding to the request on the primary server to initiate a client session;
c. Selecting a secondary server;
d. Sending session information in the client session from the primary server to the secondary server;
e. Updating session information on the primary and secondary servers each time a request is received in the client session;
A method comprising: Further comprising storing the information in a cookie on the client.
39. The method of claim 38. Further comprising, if the primary server cannot process the request, responding to the request on the secondary server;
39. The method of claim 38. Further comprising selecting a new secondary server,
41. The method of claim 40. The method further includes a step of collectively responding to a request to the primary server,
39. The method of claim 38. The method further includes a step of collectively sending session information in the client session from the primary server to the secondary server,
39. The method of claim 38. A system for replicating information during a client session,
a. Multiple servers,
b. A primary server in the plurality of servers for receiving a request during a client session, responding to the request, and further storing session information for the client session;
c. A secondary server in the plurality of servers that receives a request during a client session, responds to the request, and further stores session information in the client session;
d. A hardware load balancer for receiving a request from a client including the identification information of the primary and secondary servers and examining a corresponding part of the request including the identification information;
The hardware load balancer further comprises: responding to the process request on the primary server if the portion has not been modified since a previous request; and Select a new primary server from multiple servers,
A system characterized in that: Further comprising a cookie stored on a client, wherein the cookie includes identification of the primary and secondary servers;
The system of claim 44. The cookie includes a number for the primary server, and a number for the secondary server,
46. The system of claim 45. The cookie includes a number that is the sum of a number for the primary server and a number for the secondary server;
46. The system of claim 45. The hardware load balancer further selects a new primary server from the plurality of servers if the primary server cannot process the request;
The system of claim 44. When the primary server receives a request on a client session that is not hosted by itself, it requests session information in the client session from the secondary server, and the information in the client session stored on the secondary server Request,
The system of claim 44. The primary server further reads a cookie associated with a request received in a client session, and determines whether the primary server is hosting the client session.
The system of claim 44. The hardware load balancer further sends a request to the primary server in a lump;
The system of claim 44. A method for providing redundancy during a client session, comprising:
a. Making an algorithm in a hardware load balancer to make a load balancing decision for an initial request from a client during a client session to select a primary server from the plurality of servers;
b. Responding to the request on the primary server;
c. Selecting a secondary server using the primary server;
d. Sending session information in the client session from the primary server to the secondary server;
e. Updating session information on the primary and secondary servers each time a request is received in the client session;
A method comprising: Further comprising storing the information in a cookie on the client.
53. The method of claim 52. Further comprising selecting a new primary server using the hardware load balancer if the primary server cannot process the request;
53. The method of claim 52. Further comprising the step of responding to a request on said new primary server.
55. The method of claim 54. Further comprising selecting a new secondary server,
55. The method of claim 54. The method further includes a step of collectively responding to a request to the primary server,
53. The method of claim 52. The method further includes a step of collectively sending session information in the client session from the primary server to the secondary server,
53. The method of claim 52. Associating a version number with each update to the session information as requested.
53. The method of claim 52. Sending session information in the client session from the primary server to the secondary server includes sending a difference in information including a change in the session information.
53. The method of claim 52. Assigning an identification number to each of the primary and secondary servers,
53. The method of claim 52. Adding an identification number for the primary server and an identification number for the secondary server to obtain a single number representing both the primary and secondary servers;
53. The method of claim 52. A system for replicating information during a client session,
a. Multiple servers,
b. Receiving the request during a client session, responding to the request, and further creating a cookie containing session information for the client session and including information about the primary server, and sending the cookie to a session client. A primary server in the server,
c. A secondary server in the plurality of servers, receiving the session information from the primary server, storing the session information, further receiving a request during a client session, and responding to the request, selected by the primary server. When,
d. A hardware load balancer receiving a request from a client including the identification information of the primary and secondary servers, and a web server processing the identification information and responding to the process request on the primary server;
Wherein the hardware load balancer responds to the request on a new primary server if the primary server cannot handle the request.
A system characterized in that: A method for providing redundancy during a client session, comprising:
a. Making an algorithm in a hardware load balancer to make a load balancing decision for an initial request from a client during a client session to select a primary server from the plurality of servers;
b. Responding to the request on the primary server;
c. Sending session information in the client session from the primary server to a secondary server selected by the primary server;
d. Storing a cookie on the session client containing information identifying the primary and secondary servers;
e. Updating session information on the primary and secondary servers each time a request is received in the client session;
A method comprising: Processing a portion of a cookie that includes identification information for a request received during the client session, and responding to the request on the primary server.
65. The method of claim 64. A system for replicating information during a client session,
a. Multiple servers,
b. Receiving the request during a client session, responding to the request, and further creating a cookie containing session information for the client session and including information about the primary server, and sending the cookie to a session client. A primary server in the server,
c. A secondary server in the plurality of servers, receiving the session information from the primary server, storing the session information, further receiving a request during a client session and responding to the request, selected by the primary server. When,
d. Receiving an initial request from a client, sending the request to the primary server, further receiving a subsequent request from the client including the identification information of the primary and secondary servers, and processing the identification information; A hardware load balancer responsive to the process request on the primary server, the load balancer including load balancing logic for selecting the primary server;
The hardware load balancer further selects a new primary server if the primary server cannot process the request and responds to the request on the new primary server.
A system characterized in that: A method for providing redundancy during a client session, comprising:
a. Making an algorithm in a hardware load balancer to make a load balancing decision for an initial request from a client during a client session to select a primary server from the plurality of servers;
b. Responding to the request on the primary server;
c. Sending information in the client session from the primary server to a secondary server selected by the primary server;
d. Storing a cookie on the session client containing information for identifying the primary and secondary servers;
e. Reading the identification information received with any subsequent request during the client session and responding to the subsequent request on the primary server;
f. Updating session information on the primary and secondary servers each time a subsequent request is served on the primary server in the client session;
A method comprising: A method for providing redundancy during a client session, comprising:
a. Selecting a primary server from the plurality of servers in response to an initial request from a client using load balancing logic in a hardware load balancer;
b. Responding to the request on the primary server to initiate a client session;
c. Selecting a secondary server;
d. Sending session information in the client session from the primary server to the secondary server;
e. Updating session information on the primary and secondary servers each time a request is received in the client session;
A method comprising: Further comprising storing the information in a cookie on the client.
70. The method of claim 68. Further comprising responding to the request on the new primary server if the primary server cannot process the request;
70. The method of claim 68. Selecting a new primary server using load balancing logic in the hardware load balancer.
70. The method of claim 68. Further comprising selecting a new secondary server,
70. The method of claim 68. The method further includes a step of collectively responding to a request to the primary server,
70. The method of claim 68. The method further includes a step of collectively sending session information in the client session from the primary server to the secondary server,
70. The method of claim 68.

Images