JBoss Cluster Farm Deployment

Introduction

You setup a JBoss cluster and want to deploy applications to it.  You could copy your applications into each cluster nodes "deploy" folder.  There has to be a more efficient way to deploy application updates rather than manually copying them to each cluster node every time the application changes.

The JBoss developers came up with "cluster farm deployment" as the solution.  If you copy an application into the JBoss "farm" folder, the application archive will deploy locally and then be pushed to all other (running) cluster nodes.  When other nodes join the cluster, they will pull the application to their farm deployment folder and deploy it.

Deploying to the cluster (application push)

Start the server before updating the farm deployment directory. After starting the server, copy the application archive to the farm deployment directory (or touch it). The application will then be deployed on the cluster.  The cluster node that contains the application (or application change) will take the following actions:

• Deploy the application locally

• Push the new or updated application to every other node running in the cluster (saved to server temp folder)

• If the application already exists in the target farm folder, it is deleted which triggers undeployment

• The application is moved from temp folder to farm folder

• Nodes that join the cluster later will pull the application and deploy it

Question:  If I add applications to the JBoss farm folder before starting the application server, will the new/updated applications be pushed to the cluster during startup?

Answer: No, applications are only pushed for farm folder updates that occur while the cluster node is running.  If the node is the first member of the cluster, then it will define the applications that other cluster nodes deploy when they start up (see pull description below).

Removing an application from the cluster

Delete the application from one of the running cluster server nodes farm folder.  The application will be undeployed locally and then removed from all other cluster server nodes farm folder (triggers undeployment.)  You should manually delete the application from the farm folder of any server node not currently connected to the cluster.

New node joins the cluster (application pull)

When an application server starts up and joins the cluster for the first time, farm deployed applications are copied to this new cluster node.

The applications are pulled into the server farm folder and deployed from there.  Starting with release 4.0.3, applications are only pulled from the oldest member of the cluster.  In previous releases, applications were pulled from every other node in the cluster which wasn't efficient.  After the cluster is running, application changes made anywhere are still deployed to the other nodes in the cluster (see application push above.)  To see the details on this change, view JBCLUSTER-44.

When a cluster is split and later merges together again

A cluster is split when the network connection between two or more nodes is broken.  When a cluster is split, changes are not propagated between the clusters.  When a cluster is split, any changes to the set of deployed applications will only be made to the part of the split cluster that you are connected to.  New server nodes that join the isolated part of the cluster will not get any application changes that occurred since the split.  If a new server starts up without access to the running cluster, it will not be able to pull the current clustered applications and will deploy whatever it has currently in the farm folder.  If you find yourself with a split cluster and need to remove an application, simply delete the application in each part of the cluster.  You can do the same with application changes (make them to each part of the cluster).  Or, you could wait until the cluster merges together and touch the updated application in the farm folder to force a redeployment.