Flexible HA & Scalability Architectures with Payara Server

One of the lesser known features and key benefits of Payara Server is that it provides huge flexibility when architecting topologies for High Availability and Scalability. Utilising the embedded Hazelcast Data Grid for web session and JCache clustering brings the potential of many different topologies for scale out.

 (click to enlarge)

An example of some of the possible topologies is shown in the image above. The example shows two Hazelcast configurations - yellow and blue. Within a single configuration JCache and Web Session data is stored in all nodes within the same colour. In the image, nodes with a solid fill are hosting the application, nodes with no fill are in-memory data storage JVMs. The Payara Server instance types are shown within each node. Nodes with a lighter fill can be switched on or off, depending on the application load, to give elastic scalability. The topology is completely independent of the deployment across a number of physical host machines and could be spread across a number of physical hosts.

In the possible architecture visual you can see that storage of web session or cache data can be spread across more virtual machines than the application deployment. Also, web session and cache data can be stored in memory in non-Payara Server, or Payara Micro virtual machines. This gives great scalability advantages to technical architects designing Payara Server topologies.

By placing cluster data in additional virtual machines the availability of the data and the number of virtual machines is decoupled from the application deployment. This enables operations teams to completely take down an application without losing application data, or to devise rolling upgrade scenarios safe in the knowledge that no data will be lost.

Secondly, by using dedicated JVMs for storing application data in memory, the garbage collection ergonomics of these storage JVMs can be tuned for long term data storage with large old generations, whereas the application JVMs garbage collection can be tuned for high throughput.

Finally, with the "auto-clustering" capabilities of Payara Server, additional storage nodes or application processing nodes can be added on demand to increase scalability as the in-memory data needs grow.

Creating a shared Hazelcast configuration (one of the colours above) is as simple as ensuring your Payara Micro, Payara Standalone and Payara Server cluster instances all have the same Hazelcast configuration in the administration console.

CONCLUSION:

With Payara Server and Payara Micro you are not limited to traditional cluster architectures to scale out your web session and JCache data. Flexible in-memory data storage options are available without ever creating a traditional "cluster".  Further additional capabilities for WAN replication and high density memory storage are available withPayara Scales.