You can configure collective replica sets.
Before you begin
The collectiveController-1.0 feature
and its capabilities are available only in WebSphere® Application Server Liberty Network
Deployment and WebSphere Application Server Liberty for z/OS®. The feature is not available in WebSphere
Application Server Liberty, WebSphere Application Server Liberty -
Express, or WebSphere Application Server Liberty Core. If you have
a WebSphere Application Server Liberty Network Deployment installation,
you can use its collectiveController-1.0 feature
to work with collective members from WebSphere Application Server
Liberty, WebSphere Application Server Liberty - Express, or WebSphere
Application Server Liberty Core installations.
About this task
A replica set is a set of collective controllers that
are configured to work together. Each replica contains all the repository
updates that the other replicas within the set have processed. Therefore,
there is no need for a member or client to connect with a particular
collective controller each time that it interacts with the collective;
any of the collective controllers configured in the replica set can
provide the same data.
You can
perform three different procedures to configure a collective replica
set:
Procedure
- Optional: If necessary, you can
modify the default configuration of the initial replica set.
The
configuration of the initial replica set occurs when the initial collective
controller is created. If it is necessary to modify the default replica
configuration, the following properties can be changed in the server.xml file:
Optional
settings: These values will default but can be altered.
- replicaHost
- Hostname for each individual replica
- replicaPort
- Port for each individual replica
This is not the http or https
port of the collective controller, but it is a unique port that is
used for communication between the replicas of the replica set.
- repositoryDir
- Directory location that should be used to store repository data
- Add a replica to an existing replica set.
During the life of a replica set, it might become necessary
to add one or more replicas to an existing set, to increase capacity
for example.
The existing replicas in the replica set do not
require any updates to their configuration. You might want to update
them so that their configurations in the server.xml files
more accurately reflect the replicas forming the replica set, but
this is unnecessary and will not affect their behaviors.
Note: It
is not necessary to change the replicaSet value
in the server.xml file of an existing replica
in the set. No change to the configuration of an existing replica
is required. If you do want to update the replicaSet values
in the configurations of existing replicas in the set so that the
configuration values are consistent across all replicas in the set,
you must set the isInitialReplicaSet value in
the configurations of the existing replicas to false.
This is because after you alter the replicaSet value,
it no longer describes the initial replica set—it now describes
a changed replica set.
To add a new replica, follow these
steps:
- Ensure that the existing replica set is running and
that a majority of the replicas are available.
- Create a new server that will be the new collective
controller.
wlp/bin/server create MyNewController
- Replicate to transform the new server into a collective
controller.
wlp/bin/collective replicate MyNewController
--host=host_of_running_controller
--port=https_port_of_running_controller
--user=user_for_running_controller
--password=user_password
--keystorePassword=password_for_new_controller
The replicate command
writes XML output to a console screen. You will copy the output into
the server.xml file.

To write the output of the command to a file, instead of to a console
screen, specify an optional
--createConfigFile=output_file_path
parameter. Then, include the outputted file in the collective configuration by
adding an
include statement to the server.xml
file:
<include location=output_file_path />
- Configure the new replica's server.xml file
using the replicate command.
Copy
the XML output of the
replicate command into the
server.xml file.
You can modify the replica configuration as follows:
- Required setting:
This value must be explicitly set.
The XML printed by the
replicate command contains
this configuration and is sufficient for this setting.
- replicaSet
- Space-delimited list containing the host:port for
each of the replicaHosts and replicaPorts in
the replica set, excluding the values for the collective controller
now being added to the set
For example,
original.host.com:10001 some.other.host.com:10003
At
least one of the values in this set must already be a replica of the
existing replica set.
- Optional settings:
These will default but can be altered.
- isInitialReplicaSet
- False
- replicaHost
- Hostname for each individual replica
- replicaPort
- Port for each individual replica
This is not the http or https
port of the collective controller, but it is a unique port that is
used for communication between the replicas of the replica set.
- repositoryDir
- Directory location that should be used to store repository data
Here is an example of what you might add to a new replica server.xml file: <collectiveController replicaHost="localhost"
replicaPort="10012"
replicaSet="localhost:10010 localhost:10011"
isInitialReplicaSet="false"/>
The XML printed by
the
replicate command will require updating the
server's security configuration as well as specifying the
collectiveRootKeys keystore
password. The server's security configuration should be identical
to the original collective controller's configuration, and the
collectiveRootKeys keystore
password should be the password used for the original collective controller's
collectiveRootKeys keystore
password. If the replica was created from the controller created in
Configuring a Liberty collective, the new controller's
configuration should contain the following:
<quickStartSecurity userName="adminUser" userPassword="adminPassword" />
<!-- collective root signers keystore -->
<keyStore id="collectiveRootKeys" password="yourPassword"
location="${server.config.dir}/resources/collective/rootKeys.jks" />
- Start the new replica by starting the new collective
controller.
- Invoke the addReplica operation on
the collective utility to activate the new replica. The argument to
the addReplica set must be the replica endpoint (in
the form "replicaHost:replicaPort") of the replica
to add.
wlp/bin/collective addReplica myhost.com:10010
--host=host_of_running_controller
--port=port_of_running_controller
--user=user_for_running_controller
--password=user_password
- Remove a replica from an existing replica
set.
During the life of a replica set, it might become
necessary to remove one or more replicas from the set.
The
existing replicas in the replica set do not require any updates to
their configuration. You might want to update them so that their
configurations in the server.xml files more accurately
reflect the replicas forming the replica set.
Note: It is not
necessary to change the replicaSet value int
the server.xml file of an existing replica in
the set. No change to the configuration of an existing replica is
required. If you do want to update the replicaSet values
in the configurations of existing replicas in the set so that the
configuration values are consistent across all replicas in the set,
you must set the isInitialReplicaSet value in
the configurations of the existing replicas to false.
This is because after you alter the replicaSet value,
it no longer describes the initial replica set—it now describes
a changed replica set.
To remove a replica from a set, follow
these steps:
- Ensure the existing replica set is running with a majority of
the replicas available.
- Invoke the removeReplica operation of the WebSphere:feature=collectiveController,type=RepositoryConfiguration,name=RepositoryConfiguration MBean,
passing in the replica endpoint (in the form "replicaHost:replicaPort")
of the replica to remove.