High availability

Application outages can be costly to organizations. The organization loses business when the application is not available, and it may also be subject to penalties and fines. An unplanned application outage can also damage the organization's reputation.

Availability is a percentage of time your application is functioning. High availability (HA) has no standard definition because up-time requirements vary. In general, HA refers to systems that are durable and likely to operate continuously without failure for a long time. You can correlate the business value of HA to the cost of the system being unavailable. An industry standard way of referring to availability is in terms of nines:

To reduce the risk of unplanned application downtime, design the application to withstand this risk. Designing a highly available application means building redundancy and failover into your application so that these risks are minimized. For example, one implementation can have several load balancers, physical and virtual machines, shared storage repositories, and databases.

Clustering

The concept of clustering involves taking two or more Pega Platform servers and organizing them to work together to provide higher availability, reliability, and scalability than can be obtained by using a single Pega Platform server. The app servers can be on-premise or in a cloud and must have a means of dynamically allocating servers to support increased demand.

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

Load Balancing

Load balancing is a methodology to distribute the workload across multiple nodes in a multinode clustered environment. Load balancers monitor node health and direct requests to healthy nodes in the cluster. Since the requestor information (session, PRThread, and clipboard page) are stored in memory, Pega requires all requests from the same browser session to go to the same JVM. In network parlance, this is also known as sticky sessions or session affinity.

Session affinity is configured with the load balancer. It ensures that all requests from a user are handled by the same Pega Platform server. Load-balancing Pega nodes in a multinode clustered environment can be achieved by using hardware routers that support “sticky” HTTP sessions. Cisco systems Inc. and F5 Networks Inc. are examples of vendors who offer such hardware. There is also software, virtual, and cloud-based load balancer solutions such as Amazon EC2’s elastic scaling that are available.

The load balancers must support session based affinity and cookie persistence. Production load balancers offer a range of options for configuring session affinity. The Pega Platform supports session-based affinity. Session affinity is required in the load balancer for both slow drain and immediate drain quiesce. Immediate drain is the default quiesce method. Pega Platform settings related to cookie invalidation are applicable only for slow drain. You can configure cookies for high availability session affinity for slow drain quiesce using the following settings:

• session/ha/quiesce/customSessionInvalidationMethod
• session/ha/quiesce/cookieToInvalidate

SSO Authentication

Single sign-on (SSO) authentication, though not required, provides a seamless experience for the end user. Without SSO, the user reauthenticates when the user session is moved to another node.

Shared Storage

Users' session data is persisted in shared storage in the event of failover or server quiesce. The shared storage allows stateful application data to be moved between nodes. Pega supports a shared storage system which can either be a shared disk drive, Network File System (NFS), or a database. All three of these options require read write access on those systems for Pega to write data. By default Pega uses database persistence in a HA configuration. If organizations decide on a different shared storage system then they need to make sure the Shared Storage integrates with the Pega Platform. Implementation of the CustomPassivationMechanism plugin is required to use a custom passivation mechanism. It is essential to configure shared storage to support Quiesce and crash recovery.

Split schema

The database tier must have a failover solution that meets production service-level requirements. The Pega Platform database has a split schema. With split schema, the Pega Database Repository is defined in two separate schemas: Rules and Data. Rules includes the rule base and system objects, and Data includes data and work objects. Both can be configured during installation and upgrade.

When users save a change to a process flow, they are saving a record to the Rule schema. The Data schema stores run-time information such as processes state, case data, assignments, and audit history. The split schema design is used to support solutions that need to be highly available.

Split schema can also be used to separate customer transactional data and rules from an operational perspective. For example, data typically changes more than rules so it can be backed up more frequently. Rule upgrades and rollbacks can be managed independently from data.

With split schema rolling re-starts can be performed to support upgrades, reducing server downtime. In this example, the rules schema is copied and upgraded once. Each node in the cluster is then quiesced, redirected to the updated rules schema, and then restarted one at time.

For more information on high availability configuration, see the Deploying a highly available system article on the Pega Community.