Set up collectives
Overview
We can use collectives to manage multiple servers from a single management domain. For high availability, we can configure collective replica sets, clusters, or scaling. See Collective architecture.
To configure collectives, we set features in server.xml, and run collective command-line tasks to establish the administrative domain.
Configure a server to act as collective controller
Join a server to a collective as a member
Change the collective configuration as needed for the environment
- Register host computers with a collective
- Override host information
- Set up Remote Execution and Access (RXA)
- Set JAVA_HOME
- Generate collective controller SSL keys
- Create a replica set
- Backup, upgrade, or remove a collective controller, replica set, or member
- Set up static cluster members
- Set up dynamic routing of HTTP requests to collective members
Set up autonomic scaling of collectives
- Set up auto scaling for use with Intelligent Management dynamic routing.
- Configure auto-scalable clusters for JVM elasticity.
- Define scaling policies.
Features
- collectiveController-1.0
Provide access to REST JMX connectors (restConnector-1.0) for members of the collective. An administrative domain is established using collective tasks: create and replicate. Works with collective members from single-server products.
Available only in multiple-server products such as...
- WebSphere Application Server Liberty Network Deployment
- WebSphere Application Server Liberty for z/OS
The feature is not available in single-server products such as...
- WebSphere Application Server Liberty
- WebSphere Application Server Liberty - Express
- WebSphere Application Server Liberty Core
- collectiveMember-1.0
Enable 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. All servers enabled with the collectiveController-1.0 feature are managed; therefore, we do not need to specify collectiveMember-1.0 if the server already has the collectiveController-1.0 feature enabled.
- clusterMember-1.0
Allow a collective member to participate in a static cluster.
-
dynamicRouting-1.0
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 in order to dynamically route to all servers in a collective.
-
scalingController-1.0
Enable 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.
-
scalingMember-1.0
Monitor 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 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 server.xml. 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.
What to do next
We can administer the collective using the following tools:
- Use Jython scripts or a Java client such a JConsole to perform collective controller ClusterManager MBean operations.
- Run collective commands from a command prompt at the bin directory of the Liberty profile installation.
For help..
-
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
The example commands in this documentation are prefaced with wlp/bin/. This means to open a command prompt at the bin directory of the Liberty profile installation, such as C:\wlp\bin on Windows operating systems, and run the command.
-
Use WebSphere Liberty Administrative Center ("Admin Center") to administer Liberty profile servers, applications, and other resources in the collective from a web browser on a cell phone, tablet, or computer.
- Add the adminCenter-1.0 feature to the collective controller server.xml file.
- To access Admin Center from a cell phone, tablet, or remote computer, ensure that server.xml sets the host attribute of the httpEndpoint element to * (asterisk) or to a defined host name.
- Point a web browser at Admin Center. The URL uses the form:
- https://collective_controller_host_name:collective_controller_port/adminCenter/
- If the browser prompts you to confirm that the connection is trusted, specify an exception or otherwise enable the connection to continue to Admin Center.
- Log in using the collective controller administrative user name and password.
- Use the Explore tool to manage applications, clusters, servers, and hosts in the collective.
For other information about enabling and using Admin Center, see Administer the Liberty profile using Admin Center.
To ensure that we can remotely start and stop servers, complete the steps for the operating system in Set up RXA for Liberty collective operations.
- Add the adminCenter-1.0 feature to the collective controller server.xml file.