Configure a Liberty server cluster

Overview

We can configure a collective member to be part of a server cluster by adding the clusterMember-1.0 feature to the member server.xml file. Optionally, we can specify a cluster name to place the member in a particular server cluster. A server cluster has a unique name within a Liberty collective. All Liberty servers that specify the same cluster name within the same collective are members of the same server cluster.

To be a member of a server cluster, a Liberty server must also be a member of a Liberty collective. If we do not have a Liberty collective and member already, create a collective controller and member server to join the collective.

See Configure a Liberty collective.

For sample Liberty admin scripts, see:

liberty-collective-sample-admin-scripts

Configure a cluster

Add the clusterMember-1.0 feature to the feature manager of the member server.xml file.

<featureManager>
   <feature>collectiveMember-1.0</feature>
   <feature>clusterMember-1.0</feature> 
</featureManager>

Optional: To designate that the member belong to a particular server cluster, add a clusterMember element that specifies a cluster name.
For example, place the member in the myCluster cluster:
The default cluster name is defaultCluster. If the member server.xml does not have a clusterMember element that specifies a valid cluster name, then the member is added to defaultCluster.
Only specify one cluster name. A single collective can have multiple clusters, but a server can only be part of one cluster at a time.
If the collective controller and member server are not running, then start them.
The collective controller and member server must be running for the member to be added to the cluster. For example, use the start command to start a collective controller named myController and a member named myMember:
We can configure a collective member to be a cluster member while the member server is running. The new configuration is updated dynamically and published to the collective controller. If we configure a collective member to be a cluster member while the member server is stopped, the member server will not become a member of a cluster until the server starts.
Verify that the member is part of the cluster.
1. Look for a message that indicates the collective member now belongs to the cluster in the collective controller messages log.
  The default path for the log is...
  ...or, if the $WLP_USER_DIR variable is set in a server.env file or command window...
2. Look for messages that indicate the collective member is now a cluster member in the member messages log...
Trouble: In some cases, the server is configured to be part of a cluster but the member is not shown to be part of the cluster. A collective server can be configured to be a cluster member while it is running. The new configuration is dynamically updated and published to the collective controller. If there is a problem publishing to the controller, it affects the server joining the cluster. If a collective server is configured to be a cluster member while the server is stopped, the server is not a member of a cluster until the server is started.

What to do next

To enable application security for the cluster, copy the LTPA key file from one of the cluster members to all the other members in the cluster.

See Create a Liberty cluster with security considerations.

To administer the cluster, we can run collective controller ClusterManager MBean operations such as start or stop the server cluster, list clusters and cluster members in the collective, or generate a plug-in configuration file. We can run the operations using Jython scripts or a Java client such as JConsole.

Also, we can use WebSphere Liberty Administrative Center ("Admin Center") to administer the cluster and its servers, applications, and other resources from a web browser.

See Administer Liberty using Admin Center.

After configuring a static cluster, which this topic describes, we can route application requests to Liberty servers using IBM HTTP Server (IHS). Static clusters can receive requests through either static or dynamic routing. For information about static routing, see Generate a Liberty server cluster plug-in configuration. For information about dynamic routing, see Set up dynamic routing for Liberty collectives and Generate a plugin-cfg.xml to route to multiple collectives.

To configure an auto scaling cluster, which expands and contracts depending on the workload in the environment, see Set up auto scaling for Liberty collectives. Auto scaling clusters can receive requests only through dynamic routing.