Setting up the server-management environment for Liberty by using collectives

To set up the server-management environment for the Liberty by using collectives, define the appropriate features in the server.xml file and run the corresponding collective command-line tasks to establish the administrative domain security configuration.

About this task

You can use collectives to manage multiple servers from a single management domain. For high availability, you can configure collective replica sets, clusters, or scaling. For general information about collectives, see Collective architecture.

Liberty provides multiple-server management in the following features:

collectiveController-1.0
The collectiveController-1.0 feature enables controller functionality for a management collective and includes collective- and cluster-management MBeans that are accessible using the REST JMX connector that is provided by the restConnector-1.0 feature. The restConnector-2.0 feature is tolerated. The collective controller acts as a storage and collaboration mechanism to which collective members can connect. The administrative domain security configuration for the collectiveController-1.0 feature is established using the collective command-line create and replicate tasks. For details about the feature, see Collective Controller.

The collectiveController-1.0 feature and its capabilities are available only in multiple-server products such as WebSphere® Application Server Network Deployment Liberty and WebSphere Application Server for z/OS® Liberty. The feature is not available in single-server products such as WebSphere Application Server Liberty, or WebSphere Application Server Liberty Core. If you have a multiple-server product installation, you can use its collectiveController-1.0 feature to work with collective members from single-server products.
collectiveMember-1.0
The collectiveMember-1.0 feature enables a server to be a member of a management collective and be managed by the collective controller. The administrative domain security configuration for the collectiveMember-1.0 feature is established using the collective command-line join task. For details about the feature, see Collective Member.
Tip: All servers enabled with the collectiveController-1.0 feature are managed; therefore, you do not need to specify collectiveMember-1.0 if the server already has the collectiveController-1.0 feature enabled.
clusterMember-1.0
The cluster member feature enables a collective member to participate in a static cluster. For details about the feature, see Static Cluster Member.
dynamicRouting-1.0
The dynamic routing feature is an Intelligent Management feature of the WebSphere plug-in for Apache and IHS that provides On Demand Router capabilities for the plug-in. The dynamic routing feature enables a server to run a REST service to which the plug-in can connect to dynamically route to all servers in a collective. For details about the feature, see Dynamic Routing.
scalingController-1.0
The scaling controller feature enables a collective controller to expand or contract an auto scaling cluster and manage the scaling controller. If an environment has many scaling controllers, only one of the running scaling controllers can make decisions. If that controller is stopped, another running scaling controller takes over for it. The scaling controller can start an auto scaling cluster member in response to increased resource usage, or it might stop an auto scaling cluster member in response to decreased resource usage. For details about the feature, see Scaling Controller.
scalingMember-1.0
The scaling member feature monitors the workload within a server and its host, then sends this information to the scaling controller. The scaling controller feature is enabled in the collective controllers that are part of the collective. This feature also enables dynamic clustering of the collective members and allows the servers to dynamically start or stop based on criteria that is specified by the scaling policy. If more than one scaling member is on the same host, each scaling member must define a hostSingleton element with a port in the server.xml file. All scaling members on the same host must use the same port to identify a host leader. The host leader is the only scaling member that communicates with the scaling controller. It communicates metric data from the members to the controller and communicates scaling decisions that are made by the controller to the members in the host. For details about the feature, see Scaling Member.

Restriction: The Scaling Member feature (scalingMember-1.0) is not available on the IBM i platform.

Procedure

Configure a server to act as collective controller.
- Create a collective controller server by using commands and then configure the controller server.xml file. See step 1 of Configuring a Liberty collective.
- Create a collective controller by using developer tools. See step 1 of Configuring a Liberty collective using the developer tools.
Join a server to a collective as a member.
- Join a server to a collective using commands and then configure the member server.xml file. See step 2 of Configuring a Liberty collective.
- Join a server to a collective using developer tools. See step 2 of Configuring a Liberty collective using the developer tools.
Change the collective configuration as needed for your environment.
- Register host computers with a collective.
- Override host information by revising parameters in the hostAuthInfo element of the member server.xml file.
- Updating collective-wide remote authentication keys
- Set up Remote Execution and Access (RXA) to enable collective controllers to start and stop servers.
- Set the JAVA_HOME variable for Liberty collective members.
- Generate collective controller SSL keys.
- Set administrative metadata for Liberty resources in an admin-metadata.xml file.
Create a replica set, which is a set of collective controllers that are configured to work together, to provide management high availability.
- Automatically share configurations among replicas.
- Change the port of a replica.
Backup, upgrade, or remove a collective controller, replica set, or member.
Deploy a resource by using deployment REST APIs.
Set up static cluster members to provide application high availability and scale.
Set up dynamic routing of HTTP requests to collective members.
Set up autonomic scaling of collectives.
Enter maintenance mode before you perform diagnostic tests, maintenance, or tuning on a host or server.
Configure health management to prevent disruption of service by detecting common problems and generating diagnostic actions based on configured health policies.

What to do next

You can administer the collective using the following tools:

Use Jython scripts or a Java client such a JConsole to perform collective controller MBean operations.
Run collective commands from a command line at the bin directory of your Liberty installation. For information about collective commands, run the collective help command:
```
wlp/bin/collective help
```
To view details about a specific command, include the command name; for example, to view details about the collective create command, run:
```
wlp/bin/collective help create
```
Tip: The example commands in this documentation are prefaced with wlp/bin/. This means to open a command line at the bin directory of your Liberty installation, such as C:\wlp\bin on Windows operating systems, and run the command.

The Collective Controller API packages also provide information about collective commands.
Use WebSphere Liberty Administrative Center ("Admin Center") to administer Liberty servers, applications, and other resources in the collective from a web browser on a smartphone, tablet, or computer.
1. Add the adminCenter-1.0 feature to the collective controller server.xml file.
2. To access Admin Center from a smartphone, tablet, or remote computer, ensure that the server.xml file sets the host attribute of the httpEndpoint element to * (asterisk) or to a defined host name.
3. Point a web browser at Admin Center. The URL uses the form:
```
https://collective_controller_host_name:collective_controller_port/adminCenter/
```
4. If your browser prompts you to confirm that the connection is trusted, specify an exception or otherwise enable the connection to continue to Admin Center.
5. Log in using your collective controller administrative user name and password.
6. From the Toolbox, open the Server Config tool or Explore tool.
  - Select Server Config . Use the Server Config tool to view and edit server configuration files such as server.xml files in the collective. For information about the Server Config tool, see Editing server configuration files in Admin Center.
  - Select Explore . Use the Explore tool to manage applications, clusters, servers, and hosts in the collective. For information about the Explore tool, see Exploring and managing resources with Admin Center.
For other information about enabling and using Admin Center, see Administering Liberty using Admin Center.

To ensure that you can remotely start and stop servers, complete the steps for your operating system in Setting up RXA for Liberty collective operations.