LinkedIn
Copied!

Table of Contents

Configuring application tier architecture for redundancy

Version:

Only available versions of this content are shown in the dropdown

Highly available application tier architectures must have enough computing power to support fail-over, as well as a means to allocate new servers to support increased demands for service.

To deploy a highly available production system, two or more physical or virtual machines are needed. These allow for horizontal cluster scale and provide hardware redundancy to maximize efficiency and offer a solution for crash recovery. Each machine can deploy one or more Pega Platform servers.

Organizations can employ vertical cluster scale by adding multiple Pega Platform server instances to support production load. Determine the number of Pega Platform server instances based on capacity planning and by evaluating operational thresholds.

For information on supported application server platform versions, see the Platform Support Guide for your version of Pega Platform. For more information, see Pega Platform Support Guide Resources.

Server redundancy

For consistency, the term "Pega Platform server" is used for each web application server instance (JVM) on a physical or virtual machine. The decision to configure multiple Pega Platform servers on physical or virtual machines must be coupled with redundancy at the machine level.

Pega Platform servers must be designed to support redundancy among Pega Platform various components, such as connectors, services, listeners, and search. The exact configuration varies based on the specifics of the applications in the production environment.

Single sign-on for automatic reauthentication

Pega Platform high availability features are secure and require reauthentication in the event of a Pega Platform server crash. The Pega Platform retains operator authorization for redirection of a user during server quiesce. A single sign-on solution, although not required, enables a seamless user experience.

For more information, see Configuring SSO login authentication with a SAML identity provider.

Shared filesystem storage

Database passivation storage is the default storage method. You can choose filesystem storage if you prefer.

To use filesystem passivation for high availability, you must select a fault-tolerant shared storage solution and integrate it with Pega Platform. Application servers require fault-tolerant shared storage in order to facilitate initiated and uninitiated shutdowns. Pega Platform supports shared storage using Network File Storage (NFS) or shared disk out of the box when using filesystem passivation, but these solutions are not inherently fault tolerant.

  • For NFS solutions, the shared storage must point to an NFS location to support access from all nodes.
  • For disk-oriented solutions, Pega Platform servers require read/write access to shared storage.

To support crash recovery when your system uses file system storage, the setting storage/class/passivation:/rootpath must be set to shared storage that is available to all servers in the cluster. For example: <env name="storage/class/passivation:/rootpath" value="P:\passivation" />.

  • Depending on the operating system, the details of the configuration will vary.
  • Shared storage should be deployed so it is not a single point of failure.
  • Shared storage itself should have a failover solution.
  • Server restart is required to change the location of shared storage in the Pega Platform.

For more information, see Configuring your system for passivation and activation.

    Did you find this content helpful?

    Have a question? Get answers now.

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