Configuring clusters for GlassFish

In order to deliver the required performance, throughput, and reliability, a production environment typically needs to host enterprise applications using multiple running application server instances. In order to easily configure and maintain these server instances, most application server products, including GlassFish, allow these server instances to be grouped into a cluster and administered together. In this section, we first review the core concepts of the GlassFish cluster, and then show you how to configure and manage clusters.

Understanding GlassFish clusters

A GlassFish cluster is a logical entity that groups multiple GlassFish Server instances. The server instances within a cluster can run on different physical machines or on the same machine. The cluster is administered by the Domain Administration Server (DAS). The server instances in a cluster share the same configuration, and they host all applications and resources deployed to the cluster.

The main benefit of a cluster is that it significantly simplifies the administration of server instances. Instead of configuring these server instances and deploying applications to them individually, a cluster provides a one-stop administration facility to enforce the homogeneity of server instances. Besides, a cluster provides very good support for horizontal scalability. For example, if the production environment no longer has sufficient processing power, we can dynamically create a GlassFish Server instance and add it to the existing cluster without extensive reconfiguration. Finally, with the help of a load balancer and appropriate HA configuration, a cluster can be made resilient to server instance issues.

We will focus on the clustering aspect of GlassFish in this section. Load balancers and HA will be discussed later in this article.

The following figure illustrates the main components of a cluster from the administration perspective.

The components illustrated in the figure are described as follows:

• The Domain Administration Server (DAS): DAS is a special server instance responsible for administration of a domain. All administrative operations are routed to DAS. Upon receiving administrative requests, DAS is responsible for sending the request to an individual server instance, or broadcasting it to all the server instances in a cluster. DAS can administer server instances running on remote hosts as well.
• Node agent: A node agent is a light-weight process running on the physical server that hosts GlassFish Server instances. The node agent is responsible for managing the life cycle of these server instances. It can perform the following tasks:
  • Start, stop, restart, create, and delete server instances
  • Provide a view of the log files of failed server instance

If the node agent crashes, it does not affect the server instances and user applications that are currently running. However, a failed node agent can no longer manage and monitor those server instances.

• Server instance: With the exception of DAS, all the other server instances must be created with a reference to a node agent. A server instance can be stand-alone, or it can belong to a cluster. A stand-alone instance maintains and uses its own configuration, while a clustered instance inherits majority of the configuration information from the cluster.

In our experience, stand-alone server instances are rarely used. Even if you only need one server instance to host applications, we recommend that you define a cluster with only one instance. This approach always allows the server to be potentially scaled out by adding additional server instances to the cluster. The overhead of clustered instance is completely negligible.

• The central repository and repository cache: The central repository is maintained by DAS. The central repository contains the server instance configuration data, and the applications deployed to the GlassFish domain. Each server instance and cluster synchronizes the central repository to its local repository cache. Keep in mind that the repository cache is a subset of the central repository, because the server instance and cluster only synchronize the information pertinent to itself.

The local repository cache makes it possible to keep stand-alone and clustered server instances running while DAS is shut down. In fact, many organizations indeed shut down DAS in production environment, and they only start up the DAS when there is a new deployment of applications or resources. Without the DAS running, the GlassFish configuration cannot be changed using common administrative tasks.

A node agent is associated with a particular domain when it is created, and it can service only a single domain. If a physical machine hosts server instances that belong to multiple domains, it must run multiple node agents, one for each domain. DAS only needs the node agent to perform administrative operations on the server instances. The synchronization between DAS and server instances takes place directly through the JMX API remote connector.

The server instance or node agent synchronizes its state with the central repository in the following cases: completely at instance or node agent creation and start-up time, and incrementally as configuration changes are made to the central repository.

Now let’s dive into the process of configuring a GlassFish cluster.

Configuring clusters

In this section, we discuss the necessary steps to configure a GlassFish cluster, and along the way we will discuss more features of the GlassFish cluster.

GlassFish clusters can be created on most operating system and hardware platforms. The noticeable exceptions are Microsoft Windows running the 64-bit JDK software, and Mac OSX.

Obtaining cluster support

The very first thing we need to do in order to configure a cluster is to make sure that the GlassFish Server we are working with has cluster support. Earlier, we introduced the concept of the usage profile of GlassFish. As it turned out, clustering support is available in the cluster and enterprise profiles, and not in the developer profile by default. However, even if we originally installed GlassFish in the developer profile, we can easily upgrade the GlassFish Server to enable clustering support. To do this, complete the following steps:

1. Log on to the GlassFish Admin Console.
2. Click the Application Server node in the navigation pane.
3. Click the General tab in the main content pane.
4. Click Add Cluster Support, as shown in the following screenshot.
5. Click OK to confirm the choice.
6. Restart the GlassFish Server.

Once GlassFish restarts, we can log on to the Admin Console. We can confirm the cluster support by verifying the new Admin Console, as shown in the following screenshot.

As we can see, in the navigation panel, the previous Application Server node is replaced by the Domain node. If we click this node in the navigation panel, we will see just a few configuration options, such as managing the administrator password. Most of the other management options, such as JVM settings are no longer there in the Admin Console. The reason is that those features, such as JVM settings are applied to individual server instances. Therefore, these properties are now associated with the server instances in the cluster profile.

For a GlassFish Server that is upgraded from the developer profile, the original server instance now becomes the DAS instance and GlassFish treats the DAS as a stand-alone server instance. When we log on to the Admin Console, this server is listed under the Stand-Alone Instances node.

Once we have enabled clusters for GlassFish, we can start creating clusters. As all server instances are managed through node agents, the next step in creating a cluster is to create and start the node agents.