Set up the server-management environment for Liberty using collectives


Overview

To set up the server-management environment for the Liberty 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.

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. For more information see Collective architecture.


Multiple-server management features

  • collectiveController-1.0

    Enable controller functionality for a management collective. Include collective and cluster management MBeans accessible using the REST JMX connector 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.

    The collectiveController-1.0 feature and its capabilities are available only in WebSphere Application Server Network Deployment Liberty. The feature is not available in single-server products such as WebSphere Application Server Liberty, or WebSphere Application Server Liberty Core. If we have a multiple-server product installation, we can use its collectiveController-1.0 feature to work with collective members from single-server products.

  • 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

    Enable 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 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 send 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 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.

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


Set up collectives

  1. Configure a server to act as collective controller.

  2. Join a server to a collective as a member.

  3. Change the collective configuration as needed for the environment.

  4. Create a replica set

  5. Update a Liberty collective.

  6. Deploy a resource using deployment REST APIs.

  7. Set up static cluster members

  8. Set up dynamic routing of HTTP requests to collective members.

  9. Set up autonomic scaling of collectives.

  10. Configure health management

  11. Enter maintenance mode before performing diagnostic tests, maintenance, or tuning.


Administration tools

  • Jython scripts or a Java client such a JConsole to perform MBean operations.

  • bin/collective commands

    To get help:

      wlp/bin/collective help

    To view details about a specific command:

      wlp/bin/collective help create

  • WebSphere Liberty Administrative Center ("Admin Center")

    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://controller_host:controller_port/adminCenter/

    4. 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.

    5. Log in using your collective controller administrative user name and password.

    6. From the Toolbox, open the Server Config tool or Explore tool.

    To ensure we can remotely start and stop servers, complete the steps for the operating system in Set up RXA for Liberty collective operations.