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
-
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:
<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.
-
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.
-
Verify that the member is part of the cluster.
-
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.
-
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.