Payara

GlassFish & Payara Automated Clustering in the Cloud

Automated clustering simplifies the deployment of highly available GlassFish and Payara application-server environments by creating the required cluster topology, configuring communication between nodes and preparing the environment for scaling and failover.

In this article

Auto-Clustering Overview

GlassFish and Payara are Java application servers that can run applications across multiple instances. In a clustered configuration, several application-server nodes work together as one logical service, improving availability and allowing workloads to be distributed across the cluster.

With automated clustering, the platform handles much of the infrastructure preparation and application-server configuration that would otherwise need to be performed manually.

GlassFish

Provides Java EE/Jakarta EE application-server capabilities and supports clustered application deployment, load distribution and session replication.

Payara

Builds on the GlassFish ecosystem and adds production-oriented features for high availability, clustering, monitoring and enterprise workloads.

✓

Why use auto-clustering?

It reduces the amount of manual cluster setup required and makes it easier to build a repeatable, scalable topology for Java enterprise applications.

Cluster Topology

A typical GlassFish or Payara cluster contains multiple application-server instances behind a load-balancing layer. The cluster nodes share application state and cooperate to serve requests.

Load BalancerReceives incoming requests and distributes them across available application-server nodes.
Application NodesRun the deployed Java application and participate in the cluster.
Cluster CommunicationAllows nodes to discover one another and exchange information needed for synchronization and failover.
Shared Application StateSupports replicated HTTP sessions and other cluster-aware state where configured.
GlassFish and Payara cluster topology
A clustered topology can combine a load balancer with multiple GlassFish or Payara application nodes.

Create a Clustered Environment

  1. Open the environment topology wizard.
  2. Select GlassFish or Payara as the application-server stack.
  3. Enable High Availability or clustering where the option is available.
  4. Set the required number of application-server nodes.
  5. Add or retain a load-balancing layer for incoming traffic.
  6. Configure CPU, RAM, scaling limits and region settings.
  7. Create the environment and wait for automatic cluster configuration to complete.
Create GlassFish or Payara clustered environment
Configure the application-server layer and required node count in the topology wizard.

Node Discovery and Synchronization

After cluster creation, application-server instances must recognize one another and operate as members of the same cluster. Automated clustering prepares the internal configuration needed for this communication.

Automatic DiscoveryNew application-server nodes are added to the cluster without manually rebuilding the topology.
Internal NetworkingCluster traffic remains within the environment’s internal network where possible.
Configuration SynchronizationCluster-aware settings are applied so all instances participate in the same logical application-server group.

High Availability and Session Replication

For applications that maintain user sessions, high availability depends on making session data accessible when requests are moved from one instance to another.

GlassFish and Payara clustering can replicate HTTP session state across cluster members. If one application node becomes unavailable, another instance can continue serving the user with minimal disruption when the application and session configuration support replication.

i

Application configuration matters

Cluster infrastructure alone does not guarantee session failover. The deployed application must use a replication-compatible session model and the required server settings must be enabled.

Horizontal Scaling

One of the main benefits of automated clustering is the ability to increase or reduce the number of application-server nodes as workload changes.

Manual ScalingIncrease or decrease the number of GlassFish or Payara nodes directly from the topology wizard.
Automatic ScalingUse resource-based triggers to add or remove nodes according to application load.
Cluster IntegrationNewly created nodes can be incorporated into the application-server cluster automatically.
Load DistributionThe load-balancing layer starts routing requests to newly available instances.
GlassFish and Payara horizontal scaling
Scale the application-server layer while retaining the clustered topology.
✓

Design for statelessness where possible

Applications that minimize local node state are generally easier to scale and recover. Store persistent data in shared databases or other external services rather than relying on one application instance.

Cluster Management

After deployment, the cluster can be managed through the platform dashboard and the GlassFish or Payara administration tools.

DashboardManage topology, scaling, resource limits, node restart, logs and environment-level operations.
Admin ConsoleManage application-server-specific settings, deployments, resources and cluster configuration.
MonitoringTrack CPU, RAM, network, disk and application behavior across the application-server layer.
LogsReview node and application logs when troubleshooting cluster communication or application errors.

Expected Result

The application runs across a clustered GlassFish or Payara topology with multiple application-server instances. Incoming requests are distributed between healthy nodes, and the environment can be expanded horizontally while preserving the cluster configuration.

Important Notes

  • Use at least two application-server nodes when high availability is required.
  • Confirm that the deployed application supports clustered operation and session replication.
  • Keep persistent application data outside individual application-server containers.
  • Use a load-balancing layer to distribute requests across cluster members.
  • Review application and cluster logs after adding or removing nodes.
  • Test failover behavior before using the cluster for production workloads.

Related Guides