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.

Clustered deployment

Updated on April 5, 2022

Use multiple nodes to provide high system availability and fault-tolerance, because if one node fails or goes offline, users can connect to another node to continue working.

When a server node is running, the server appears as an instance of the Data-Admin-Nodes class.

You do not need to define instances of this class. The system creates an instance each time that Pega Platform starts on that server. (You can start and stop the engine software on each node independent of the state of other nodes.)

All the nodes share a single common Pega Platform database. The PegaRULES engine software on each node must be a compatible version or an identical version of the Pega Platform.

Each node contains an in-memory cache of recently accessed rules that may, in multiple-node operations, contain different instances. (The correct and most recent versions of the rules are always in the database.) Periodic pulse processing synchronizes the contents of the rule cache on a node to the latest copy in the PegaRULES database. Optionally, you can associate a description of each node using Data-Admin-Node instances. The information you enter appears on the System Nodes Detail display.

Note: Node names are limited to 32 characters.

Nodes can run or block specified agents, making it possible to dedicate a node to perform certain functions, hence improving the cluster performance. You can specify the list of agents to be run or blocked at the startup. Critical agents cannot be prevented from running. For more information, see the Pega Community article Configuring nodes to run selected agents.

In a multinode Pega Platform system, ensure that the clocks of every node are synchronized, and the clock on the server hosting the PegaRULES database is synchronized. Most vendor operating systems offer a means to accomplish this. Many calculations and decisions such as time-qualified rules, service-level agreements, and management reporting depend on clock settings and intervals.

UNIX and Linux-based systems require special configuration settings to ensure that the JVM recognizes Daylight Savings time. If not set, the times recorded in the Pega Platform log may not match the server clock time. See IBM Tech Note "Incorrect time stamps displayed by an application or in log files" about the TZ environment variable, and additional details for IBM WebSphere.

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