Question

A system administrator asks:

1. What load balancing technology does Pegasystems recommend for Process Commander multinode clusters?
2. What should we be aware of as we implement session replication across a WebLogic cluster (providing full failover resiliency)? 

Response

This guidance reflects Pegasystems experience as of January, 2006.

1. To date Pegasystems has recommended hardware routers, known as sticky routers, for load balancing. (Pegasystems has not specified one brand or model.) You do have the option, depending on the need for resiliency, to persist requestors only when they time out, or persist requestors at the end of every interaction. Though the latter approach is rather expensive, once the session state has been persisted your processing can actually resume on any node - so that if you lose the node, your processing can pick up on a separate node and that will continue working pretty much from the place you left off. The requestor persistence is a pegarules.xml setting.
2. The persisting of requestors is the technology used to share the information among multiple nodes.  You can use BEA WebLogic’s session failover facilities to carry the session information, but that’s just the requestor ID, essentially. There are two separate pieces to the task.  There’s the HTTP session, which is the data that you load into the servlet tier as your state.  All that Process Commander loads into the servlet tier as the state is the JSession ID.  Separately, if you choose to persist the requestor clipboard and all the rest of the structures to the database, Process Commander tags that with the JSession ID so that when you switch over to a different node the JSession ID gets carried over by WebLogic.  Then when you go to access your clipboard, if it’s not present on that node it can be found in the database if it has been persisted.

A success case study

Pegasystems has successfully configured a sticky connections approach using a Cisco Content Services Switch (CSS). Users are routed to one of three (two primary and one failover) Sun Solaris nodes each of which is running two WebLogic 8.1 Process Commander application servers. CSS supports a variety of load balancing algorithms— ranging from simple round-robin to intelligent server interrogation— to route the connection to the least utilized server. This configuration used round-robin routing.

Further, CSS supports a number of sticky connection configurations by routing existing user sessions to the same application server based on one of:

• a configured string in the HTTP cookie header
• a cookie in the HTTP header or
• a cookie in the URL.

In this case, the organization just used an HTTP header cookie holding the JSession ID.

The organization elected not to use requestor persistence to the PegaRULES database, in the interests of performance. They also considered WebLogic's own session persistence to be too expensive. They were willing to accept the risk of a user potentially losing their latest transaction data and having to re-login to an alternative application server (via the load balancer) in the event of an application server failure.

Finally, Pegasystems implemented a keep-alive solution: the CSS periodically submitted an HTTP request to run an unauthenticated activity on each Process Commander server node to check that not only the application server was available but that Process Commander itself was up and running.

If this request failed or timed out, then that WebLogic-managed server was removed from the CSS routing table and made unavailable to users until a subsequent similar request succeeded. The activity was configured to exercise all critical Process Commander application functions, including checking RDB and JMS connections.

Related Topics

Load balancing a multinode cluster