Note: Please go to docs.rightscale.com to access the current RightScale documentation set. Also, feel free to Chat with us!
Home > Guides > Dashboard Users Guide > Manage > Arrays > Concepts > Best Practices for Autoscaling Alerts

Best Practices for Autoscaling Alerts

Overview

Server arrays are commonly used for application tiers (e.g. PHP, Tomcat, Rails) where additional application servers are launched or terminated in response the changing workloads at the application level.

If you are using a server array for autoscaling purposes, you must configure each server with the appropriate alert specifications so that it can vote for a grow/shrink action, which causes the server array to resize up or down accordingly.

Things to Consider

Identify all voters

Depending on how the deployment is configured, you may need to add the alerts at multiple levels to ensure that each server will inherit the same alert. Use the reference architecture examples below as a general guideline to make sure that each "voting" server will inherit the same alert specifications.

  • If you are using the same ServerTemplate to launch each voting server and it's not being used in a different deployment, add the alert to the ServerTemplate.
  • If you are using a server array to launch all voting servers and the ServerTemplate is used in multiple deployments, add the alert to the Server Array's Next Alerts tab so that each new instance launched into the array will inherit its alert specifications from the array level.
  • If there are servers at the deployment level (under the deployment's Servers tab) and its ServerTemplate is used in multiple deployments, add the alert to each inactive server's Alerts tab. If server is already active (overational), you must add the alerts to each active server's Current Alerts and Next Alerts tabs to apply the alerts to the running server as well as ensure that it will be inherited by the next instantiation of that server.

Select the Metric

Before you create alerts for triggering an autoscaling event, the first step is to identify the appropriate metric for autoscaling purposes. If you pick an inappropriate metric for the alerts, the server array may potentially resize up/down under false conditions. Be sure to test autoscaling in a staging environment to make sure the server array is resizing appropriately as expected. You may need to change the metric or thresholds accordingly to ensure proper autoscaling behavior.

Add alerts at the appropriate level(s) to make sure that each "voting" server will inherit the same alert specifications.

If you do not have a specific metric that you want to use, it's recommended that you use 'cpu-idle' as the base metric for each alert. Although you can use a different metric for scaling down, it's generally recommended that you use the same metric for both resize actions.

screen-Scaling_Alerts-v1.png

  • Scale Up
    • If a server's 'cpu-0/cpu-idle' is < 30% available for longer than 5 minutes, vote to 'grow' the server array.
  • Scale Down
    • If a server's 'cpu-0/cpu-idle' is > 70% available for longer than 5 minutes, vote to 'shrink' the server array.
You must to post a comment.
Last modified
22:44, 16 May 2013

Tags

Classifications

This page has no classifications.

Announcements

None


© 2006-2014 RightScale, Inc. All rights reserved.
RightScale is a registered trademark of RightScale, Inc. All other products and services may be trademarks or servicemarks of their respective owners.