Configuring a Liberty server cluster

You 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, you 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.

Before you begin

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

Procedure

  1. 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>
    
  2. 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:

    <featureManager>
       <feature>collectiveMember-1.0</feature>
       <feature>clusterMember-1.0</feature>
    </featureManager>
    <clusterMember name="myCluster"/>

    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.

  3. 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:

    wlp/bin/server start myController
    
    wlp/bin/server start myMember

    You 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 you 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.

  4. 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 ${wlp.install.dir}/usr/servers/myController/logs/messages.log or, if the $WLP_USER_DIR variable is set in a server.env file or command window, $WLP_USER_DIR/servers/myController/logs/messages.log.

      CWWKX9051I: The myMember server has been added to the myCluster cluster.
    2. Look for messages that indicate the collective member is now a cluster member in the member messages log, $WLP_USER_DIR/servers/myMember/logs/messages.log.
      CWWKX7400I: The ClusterMember MBean is available.
                  myCluster
      CWWKF0012I: The server installed the following features: [clusterMember-1.0].

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 Creating a Liberty cluster with security considerations.

To administer the cluster, you 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. You can run the operations using Jython scripts or a Java client such as JConsole.

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

After configuring a static cluster, which this topic describes, you 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 Generating a Liberty server cluster plug-in configuration. For information about dynamic routing, see Setting up dynamic routing for Liberty collectives and Generating a plugin-cfg.xml to route to multiple collectives.

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