Setting up auto scaling for Liberty collectives
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.Before you begin
Auto scaling dynamically adjusts the number of Java virtual machines (JVMs) used to service your workload. This feature provides operational agility and decreases administrative overhead to enhance the resiliency of your 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. For more information on Dynamic Routing, see Setting up dynamic routing for Liberty collectives.
Liberty collective controllers can use the Tivoli® Remote Execution and Access (RXA) toolkit to perform selected operations on collective members. Review the tasks in Setting up RXA for Liberty collective operations to learn more about installing and using SSH.
You must also set your JAVA_HOME path before setting up auto scaling. Review the tasks in Setting the JAVA_HOME variable for Liberty collective members and controllers.
About this task
An auto scaling cluster is a server cluster that can expand and contract depending on the workload in your 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 by using policies when the consumption of resources rises above an upper threshold or falls below a lower threshold.
- 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. For more information on collective controllers and how to configure your controllers for high availability, see Configuring a Liberty collective. 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. For more information about replica sets, see Configuring Liberty collective replica sets.
Note: 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.
- JVM elasticity
- scalingMember-1.0The 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.Restriction: The Scaling Member feature
(
scalingMember-1.0) is not available on the IBM i platform.Note: 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" />For more information about the hostSingleton element, see Collective Member.
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
Procedure
- Create a collective to use for auto scaling.
Results
With the auto scaling feature enabled, you can now dynamically adjust the number of Java virtual machines (JVMs) or Liberty servers used to service your workload.