The Deployment Group is the clustering feature of Payara Server.
Deployment Groups can be used as a target for deployments and other resources so that each are performed on the instances assigned to the Deployment Group. Payara Server’s Deployment Groups are an extremely flexible form of clustering as each instance can be part of one or more Deployment Groups.
When a Deployment Group is restarted, a rolling restart of each instance is performed to ensure the information contained in the Domain Data Grid is kept.
Deployment Group Benefits
Why You’ll Want to Use Deployment Groups
High Availability
Achieve failover with Deployment Groups – if one instance fails, another can pick up the workload.
Load Balancing
Distribute projects across nodes to reduce overhead and use resources flexibly.
Improved Performance
Deployment Group duplication provides greater processing power.
Scalability
As user base grows, resources can grow.
Simplified Lifecycle Management
Clustering simplifies the management of large/rapidly growing systems and can start and stop all servers in a cluster or individual servers.
No Data Loss During Restart
Deployment Groups support rolling restart which is Domain Data Grid aware – all instances in the group are stopped and then started in turn, giving the Data Grid enough time to adapt and providing no loss of data during the restart.
High Availability and Scalability
In production environments it is usually necessary to look at reliably hosting your application across multiple, redundant hosts to guarantee a reliable service and allow for future scaling. With Payara Server, it is possible to easily create and add instances to deployment groups using Hazelcast, making distributed application configuration a breeze.
Deployment Groups are a set of Payara Server instances that can be used to target resources and deployments which can be started and stopped together. Individual Payara Server instances can be in one or many deployment groups, or none at all, providing greater flexibility over traditional clustering. Deployment Groups allow for a loose grouping of one or more Payara instances and they will cluster automatically by sharing a single configuration.
Application servers running Jakarta EE (Java EE) applications can be clustered to run the same set of applications and share workload management. Clustering makes it possible to scale beyond the capabilities of a single application server. Requests are automatically routed to the running servers in the event of a failure, providing high availability for enterprise applications.
Co Authored with Nicolas Frankel (Hazelcast Developer Advocate), this article is also available as a PDF. The Hazelcast In-Memory Data Grid (IMDG) is an efficient method of storing data in a distributed way within the memory of the different processes of the cluster. Because it is distributed, searching the data locally requires 'moving' the data to your instance so it can be accessed, which is not overly efficient. Hazelcast SQL allows distributed queries which perform the search where the data is, and then transfers only the results to your process. Since the Payara products already use Hazelcast IMDG, using the Hazelcast SQL capabilities is straightforward: just add the additional JAR library to start using it.
Introduction The Apache Maven Cargo Plugin allows you to deploy your application to a Payara Server, running locally or remotely. Using Maven as a build tool is an easy way to immediately deploy the application during the build to a test or production server. We have created a custom version of the Cargo Plugin which also supports the Deployment Group feature of the Payara Server.
One of the cornerstones of any modern Payara Platform architecture is the use of the Domain Data Grid. The Domain Data Grid allows multiple Payara Server or Payara Micro instances to join and form a robust cluster of interchangeable nodes that can share data between each other and grant High Availability and Failover capabilities to any applications deployed in the cluster.
What happens when an application designed for a small user base needs to be scaled up and moved to the cloud? It needs to live in a distributed environment: responding to an appropriate number of concurrent user requests per second and ensuring users find the application reliable. Though Jakarta EE and Eclipse MicroProfile can help with reliable clustering, there is no standard API in Jakarta EE that defines how clustering should work currently. This might change in the future, but in the meantime, this gap must be filled by DevOps engineers. In this blog, we will cover 10 technical strategies to deal with clustering challenges when developing Jakarta EE and MicroProfile for cloud environments.
