Deployment Groups in Payara Server 5

Photo of Steve Millidge by Steve Millidge

In Payara Server 5 we have introduced the concept of a Deployment Group - in this blog post, we'll explore why they are important and what they are used for.

 

 Payara Server & Payara Micro  Download Here 

 

What About Clusters?

Payara Server 4 and GlassFish have the concept of a Cluster. A Cluster is a number of concepts rolled into one. First, a cluster is a named group of server instances. You can create a cluster and add a number of server instances to the cluster. These instances are somewhat hidden in the administration console and only appear under the cluster which created them. However, in the internals of Payara Server, these instances are normal standalone instances that share a single configuration. Secondly, a cluster is a convenient target for deployment. When deploying an application or configuring a resource you can target the cluster to ensure the application or resource is deployed to all the servers in the cluster. Thirdly, a Cluster is the unit of data sharing for web sessions stateful session beans and SSO credentials. In Payara Server 4 and GlassFish, an old clustering library named Shoal provided this data sharing infrastructure. Finally, a Cluster can be the unit of life-cycle management. You can start and stop all the servers in a cluster or individual servers.

 

How do Deployment Groups Differ?

In Payara Server 5, with the introduction of the Domain Data Grid we are taking the original concept of the cluster and splitting out the responsibilities into different components. The Domain Data Grid provides domain wide data sharing for web sessions, stateful session beans and the like while also introducing powerful data grid capabilities and JCache support. The Deployment Group is complimentary to the Domain Data Grid. The Deployment Group provides the other 3 Cluster capabilities.

 

Deployment Groups as a Named Group of Servers

When you create a Deployment Group you can add and remove existing standalone instances from the group (see the image below). However, Deployment Groups provide greater flexibility than traditional clusters. First, an instance can be in many different deployment groups. Also, you can add an instance to a deployment group at any time and any targeted applications or resources will automatically be deployed. In a similar fashion you can also remove an instance from a deployment group and applications and resources will be undeployed. Payara Server instances in the deployment group are not hidden in the administration console and are still visible for management under the 'Instances' section of the admin console navigation tree.

 

deployment groups blog 1.png

 

Similar control is also provided via asadmin, for example the commands below would create a deployment group called core-web and add the preexisting instance server1 to the deployment group:

asadmin> create-deployment-group core-web
asadmin> add-instance-to-deployment-group --instance server1 --deploymentgroup core-web

Deployment Groups as a Target of Deployment

Once you have created a deployment group in a similar manner as for Clusters, a deployment group can be used as a target for deployment of resources and applications, and all servers currently in the deployment group or added later will have the application deployed on them. A deployment group name can also be used as the target for asadmin commands. For example, the asadmin command below would deploy the ecommerce.war to all the server instances in the deployment group core-web:

asadmin> deploy --target core-web ecommerce.war 

Deployment Group as a Unit of Control

Deployment Groups also provide lifecycle management capabilites. You can start a deployment group and all instances currently in the group will be started. Similarly, you can stop a deployment group. In addition, Deployment Groups support a rolling restart which is Data Grid aware. In a rolling restart, all instances in the group are stopped and then started again in turn, ensuring that the Data Grid has enough time to adapt and ensure no loss of data during the restart.

 

For example, in asadmin the command below would restart all Payara Instances in the core-web deployment group.

asadmin> restart-deployment-group core-web

Payara Server Instances are the Primary Resource

With the introduction of Deployment Groups and the Domain Data Grid, Payara Server instances become the primary resource for management. First, you create the managed servers you need running on various nodes in your environment. You can then add these instances to various deployment groups depending on requirements. For example, imagine you are in a cloud environment and you have a couple of deployment groups "core-web" running your core e-commerce system and "reporting" running applications for management reporting. With deployment groups in response to peak load it is very simple to re-purpose a reporting instance to the core-web deployment group with a single asadmin command.

asadmin> add-instance-to-deployment-group --instance reporting-1 --deploymentgroup core-web

For another example in a cloud environment (shown below), you could have each IAAS virtual server configured to have a couple of generic Payara Server instances running on them (colored grey). Then, when you come to deploy applications, you could select a number of these instances to be in deployment group 1 (colored blue), a number in deployment group 2 (colored orange) and so on. With the flexibility to change the distribution as time goes on. As data sharing of sessions is spread throughout the whole Payara Server domain, moving instances between deployment groups does not impact accessibility of web session data.

 

deployment groups blog 2.png

 

The Future of Deployment Groups

With the introduction of Deployment Groups we have much more flexible instance model that can adapt to cloud, elastic and container infrastructure. We envisage an administrator adding instances and moving them between deployment groups as demand requires. We are also planning future functionality whereby deployment groups can be used and integrate with service discovery mechanisms and service meshes for container infrastructure like Kubernetes, where adding a server to the deployment group also updates the service discovery or load balancers.

 

The old concept of the Cluster is still available in Payara Server 5 but please try out deployment groups! Give us feedback on how they work for you and let us know how you would like us to evolve the concept.

 

Payara Server 5 Data Sheet 

 

Comments