Scale-Out Performance and Availability Clusters

Attention: This feature is in Early Adopter Product (EAP) release status. We will continue the development of additional features and provide additional interfaces via patch updates and future releases. Please contact Micro Focus SupportLine if you require further clarification.

Enterprise server instances are typically deployed as a scale-up server. This means that performance is improved by adding or replacing the existing hardware components. Ultimately, the servers performance is limited by the machines existing resources.

A Performance and Availability Cluster (PAC) enables you to configure enterprise server instances in a scale-out architecture. In a PAC, multiple enterprise server instances work together, as a single logical entity.

Note: As the PAC is an EAP, some objects and features are not yet PAC enabled. Such as, CWS behaviour is unchanged, task numbers are not unique across a PAC, XA resources are local resources.

A PAC can provide the following advantages over a single enterprise server instance:

Availability - A PAC that utilizes distributed enterprise server instances improves robustness to hardware or network issues.
Performance - Multiple enterprise server instances working together to maximize the overall performance and throughput, potentially performing better than a single enterprise server instance.

The enterprise server instances in a PAC need to be able to share synchronized user and system data. To facilitate the sharing and synchronicity requirement a PAC uses a data store referred to as a Scale-Out Repository (SOR). There are two specific types of SOR:

A PAC SOR (or PSOR) - This stores system, configuration, and other data that needs to be accessible by all enterprise server instances in the PAC
Note: A PAC must have only one PSOR.
A SOR - This repository can be used to store user data, currently limited to non-recoverable TS and TD queues.

You can choose which instances of user data are stored in a SOR using a SOR Model. For example, if only a subset of TSQs need to be shared, then a SOR Model can be used to specify which TSQs are directed to the SOR. Instance data that does not match a SOR Model rule continues to be stored on its local enterprise server instance.