Set up Auto Scaling for Liberty collectives

The Auto Scaling for Liberty feature provides an autonomic scaling capability of Liberty servers. Auto Scaling can dynamically adjust the number of Java virtual machines (JVMs) based on workload and dynamic routing to intelligently manage the workload. This feature provides operational agility and decreases administrative overhead to enhance the resiliency of our middleware environment. The conditions for auto scaling are defined by scaling policies. These conditions include, the minimum/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.

We must have SSH installed on the computer for all non-Windows platforms before we can set up auto scaling. For a Windows platform, we must either have SSH or the Windows remote protocol enabled. Review the tasks in Set up RXA for Liberty collective operations to install SSH.

Also set the JAVA_HOME path before setting up auto scaling. Review the tasks in Set the JAVA_HOME variable for Liberty collective members

An auto scaling cluster is a server cluster that can expand and contract depending on the workload in the environment. The Liberty profile controls the starting and stopping of cluster members based on performance information that is collected from the cluster members and configurable scaling policies. To be a member of a server cluster, a Liberty profile must also be a member of a Liberty collective. A server cluster has a unique name within a Liberty collective. All Liberty profiles that specify the same cluster name within the same collective are members of the same server cluster. 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

  The scaling controller feature 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. 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. collectivesIt is recommended for every collective controller to also be a scaling controller for simplicity.

  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 based on resource usage and optional scaling policies. There is no provisioning of new servers.

• scalingMember-1.0

  The scaling member feature monitors the workload within the server and its host, then sends the monitoring 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.

  All scaling member servers must also belong to a cluster because all policy information is applied at the cluster member.

  Each scaling member needs to define a hostSingleton element with a port in the server.xml. All the scaling members on the same host 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. 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 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

1. Create a collective to use for auto scaling.

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

Results

With the auto scaling feature enabled, we can now dynamically adjust the number of Java virtual machines (JVMs) and dynamic routing to intelligently manage the workload.

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