Set up auto scaling for Liberty collectives


Overview

Auto scaling provides an autonomic scaling capability of Liberty servers. The auto scaling functionality is enabled by two Liberty features, Scaling Controller and Scaling Member.

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

Auto scaling dynamically adjusts the number of Java virtual machines (JVMs) used to service the workload. This feature provides operational agility and decreases administrative overhead to enhance the resiliency of the middleware environment. The conditions for auto scaling are defined by scaling policies. These conditions include the minimum or maximum number of server instances and the threshold values for each of the server resources.

This feature does not require the use of Dynamic Routing, however auto scaling performs well when both features are used together. It is recommended to use the two features together.

Liberty collective controllers can use the Tivoli RXA toolkit to perform selected operations on collective members.

Set the JAVA_HOME path before setting up auto scaling.

An auto scaling cluster is a server cluster that can expand and contract depending on the workload in the environment. The Liberty scaling controller controls the starting and stopping of scaling members that are based on performance information that is collected from the scaling members and configurable scaling policies. To be a scaling member of a server cluster, a Liberty scaling controller must also be a member of a Liberty collective. A server cluster has a unique name within a Liberty collective. In Liberty, members of the same server cluster will have the same cluster name, if they are within the same collective. Auto scaling capabilities are controlled using policies when the consumption of resources rises above an upper threshold or falls below a lower threshold.

The auto scaling functionality is enabled by two Liberty features, Scaling Controller and Scaling Member.

  • scalingController-1.0

    Decides when to expand or contract an auto scaling cluster. Collective controllers are required because they provide administration functionality that leverages the ability of the collective controller to manage the scaling controller. Only one of the running scaling controllers can make decisions. 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 across the entire cluster. If replica sets are being used, all collective controller members must be scaling controllers. When using replica sets if a controller is stopped, another running scaling controller takes over for it. The scaling controller keeps the last known state of the scaling members. Stopping the scaling controller and changing the state of the scaling members may cause some invalid actions at the scaling controller restart, until the scaling controller has gathered the latest scaling member state.

    The scaling controller supports the following usage scenarios:

      JVM elasticity The scaling controller starts and stops existing Liberty servers that are based on resource usage and optional scaling policies. There is no provisioning of new servers.
      Liberty elasticity The scaling controller can install Liberty software onto registered hosts and provision new servers, and then start and stop those servers, based on resource usage and optional scaling policies.

  • scalingMember-1.0

    The Scaling Member feature monitors the workload within the server and its host, when needed it sends this information back to the scaling controller. The Scaling Member feature must be enabled as a collective member in a collective. All scaling member servers must also belong to a cluster because all policy information is applied at the cluster member. If there are two or more scaling members on a host, then the scaling members are organized so that only one scaling member communicates with the scaling controller. The host leader is nominated from among all the scaling members on a host. If the host leader stops, then another scaling member will take over as the host leader. Each scaling member needs to define a hostSingleton element with a port in the server.xml. All the scaling members on the same host and cluster must use the same port. This port is used by an election service to identify a host leader. The host leader is the only scaling member that communicates with the scaling controller. The host leader 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 example:

      <hostSingleton name="ScalingMemberSingletonService" port="5164" />

    The scaling member monitors the use of the following resources within the server process:

    • CPU
    • Heap
    • Memory

    The scaling member monitors the use of the following resources at the host level:

    • CPU
    • Memory


Set up auto scaling

  1. Create a collective to use for auto scaling.

  2. Define scaling policies to change the criteria that the scaling controller uses to manage workload.

With the auto scaling feature enabled, we can now dynamically adjust the number of Java virtual machines (JVMs) or Liberty servers used to service the workload.

Note that the auto scaling cluster capabilities are only available in WebSphere Application Server Network Deployment Liberty and WebSphere Application Server for z/OS® Liberty.


Related concepts


Related tasks


Related reference