Skip to main content


         This documentation site is for previous versions. Visit our new documentation site for current releases.      
 

This content has been archived and is no longer being updated.

Links may not function; however, this content may be relevant to outdated versions of the product.

Recommendations for load balancing and WebLogic session replication (4.2)

Updated on September 13, 2021

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

Tags

Pega Platform 7.1.1 - 8.3.1 System Architect System/Cloud Ops Administrator System Administration

Have a question? Get answers now.

Visit the Support Center to ask questions, engage in discussions, share ideas, and help others.

Did you find this content helpful?

Want to help us improve this content?

We'd prefer it if you saw us at our best.

Pega.com is not optimized for Internet Explorer. For the optimal experience, please use:

Close Deprecation Notice
Contact us