Creating a Schedule-Based Autoscaling Policy

On Compute Cloud@Customer, you can create schedule-based autoscaling policies.

An autoscaling policy is part of an autoscaling configuration. Each policy of a schedule-based autoscaling configuration has a schedule and either a target pool size or a lifecycle action.

The procedures in this section describe how to create policies separate from creating the autoscaling configuration.

Designing Policies

This section provides some tips for designing and troubleshooting policies.

Create two separate policies to scale a pool in and out or to change the state of the pool between stopped and running.

  • Scale example: One policy specifies a larger size for the pool at the beginning of a high demand period, and a second policy specifies a smaller pool size at the end of the high demand period.

  • State example: One policy stops all instances in the pool at the beginning of a regular compute node maintenance period, and a second policy starts the pool at the end of the maintenance period.

Design the policy schedule as follows:

  • Use cron expressions. Autoscaling uses a cron implementation similar to the Quartz cron implementation. All fields require a value. If fields conflict, such as day of month and day of week, use a specific value for one and a question mark for the other.

  • Provide all schedule times in UTC.

  • Use an online cron expression generator such as Quartz cron expression generator to verify your schedule expressions.

  • Ensure that policy schedules don't conflict. See the descriptions in Multiple Schedule Management of which policies run when schedules conflict.

Take the following steps if a policy fails to run, or appears to fail to run:

  • Check that the autoscaling configuration and autoscaling policy are both enabled.

  • Check the schedule expression. Is the policy set to run when you meant for it to run? Remember, all expression times must be provided in UTC.

  • Was the policy set to start instances that were already running, or stop instances that were already stopped?

    In addition to a policy conflict, a power action might have been performed on the pool separate from any autoscaling policy. That separate power action could prevent the policy action from succeeding. The policy power action is not retried.

  • Was the policy set to scale out, but not enough resources were available?

    The scale policy sets the pool size, and the pool continues to try to reach that size as resources become available.

  • Is the operation specified by the policy still executing or waiting to run?

    • Check whether the pool is in the Scaling, Starting, Stopping, or Rebooting state, which indicates that the policy operation is still running.

    • If a state change operation tries to run while a state change operation is already running on the same pool, the second operation fails to run.

    • A limited number of pools can be changing state concurrently. If too many other pools are already changing state, then the pool must wait to begin changing state. The time to change state is longer when more instances are involved because instances are started, stopped, or rebooted serially.

    • A limited number of pools can be changing size concurrently. If other pools are already changing size, your pool might need to wait to begin scaling. The time to scale is longer when more instances are involved because instances are deleted or created serially. Delete and creating instances are both background operations and take some time to begin after the pool size has been updated by the policy.

Was this article helpful?