Defining scaling policies to manage workload

We can manage the workload by defining scaling policies.

If no scaling policy is previously defined, then by default, the scaling controller decides when to start and stop dynamic cluster members based on the following criteria:

• A minimum of two cluster members, if two cluster members are available, are kept active, assuming those members are not exceeding the metric threshold.

• Another cluster member is started when the average CPU, process memory use, or heap use of all active members exceeds 90%.

• A cluster member is stopped when the average CPU, process memory, or heap use drops below 30%.

Optionally, we can define scaling policies to change the criteria that the scaling controller uses for all clusters or for specific clusters. There are two types of scaling policies:

• Default scaling policy

  We can define a single default scaling policy to manage clusters that do not have a more-specific scaling policy defined. It provides defaults for other scaling policies.

  The following example shows how to define a default scaling policy that sets the minimum number of active cluster members to 3.

  <scalingDefinitions>
   <defaultScalingPolicy min="3"/>
  </scalingDefinitions>

• Scaling policy

  We can define a scaling policy to manage one or more clusters with different criteria from the default policy. The policy only needs to specify the differences; all unspecified values are taken from the default policy.

  The following example shows how to define a scaling policy that changes the CPU use thresholds for starting and stopping servers in a cluster named cluster1.

  <scalingDefinitions>
   <defaultScalingPolicy min="3"/>
   <scalingPolicy id="cluster1Policy">
    <bind clusters="cluster1"/>
    <metric name="CPU" min="10" max="70"/>
   </scalingPolicy>
  </scalingDefinitions>

  The value of the clusters attribute of the bind element is a comma-separated list of cluster names. An asterisk can be used at the end of the name only as a wildcard to match zero-or-more characters. For example:

  <bind clusters="west,south*"/>

  In this example, the scaling policy applies to a cluster named west and all clusters whose name starts with south. If a cluster name matches multiple policies, the scaling controller uses the following rules to choose a policy:

  • An exact match is preferred to a wildcard match.

  • If there are multiple wildcard matches, the policy with the longest prefix is used.

  The previous example also demonstrates how the default scaling policy establishes default values for all other scaling policies. The scaling policy with id cluster1Policy does not specify a value for the min attribute, so it uses the value from the default scaling policy that is 3.

The metric policy setting takes precedence over the minimum instances setting. If a scalingPolicy metric threshold is breached, the scaling controller will not start a new server on that host, even to meet the minimum number of instances specified by the scalingPolicy. For more information on scalingPolicy metrics see, scalingController-1.0.

1. Add the default scaling definitions.

   <scalingDefinitions>
    <defaultScalingPolicy enabled="true" min="1" max="2"/>
   </scalingDefinitions>
   
       

2. When a scaling policy is modified, the server.xml in the controller is also modified. We can check the messages.log file for the following messages to verify that the controller was successfully updated.

   CWWKG0016I: Starting server configuration update.
   CWWKG0028A: Processing included configuration resource: /home/AdminUser/liberty/workspave/build.image/wlp/usr/
   CWWKG0017I: The server configuration was successfully updated in 0.052 seconds

Results

Your scaling policies are now defined.

Tasks:

Set up Auto Scaling for Liberty collectives