Installation¶

pip install RAX-AutoScaler

Configuration¶

Edit config.json adding the following: * API username * API key * Region name * Autoscaling group section should contain:

• AutoScale Group UUID
• Scale Up Policy UUID
• Scale Down Policy UUID
• Check Type (agent.cpu, agent.load_average...)
• Metric Name (depends on the check type)
• Scale Up Threshold
• Scale Down Threshold
• Webhooks Url (Pre & Post commit url(s) for scale up/down)

Usage¶

Once configured you can invoke the autoscaler.py script.

–cluster option should be used when this script actually runs on auto-scale group members. Otherwise if it is running on a dedicated management instance you do not require this option.

–as-group option should be used when you have multiple groups listed in the config.json file.

–config-file option should be used if config.json file does not exists in current directory or in ‘/etc/rax-autoscaler’ path.

Once tested you should configure this script to run as a cron job either on a management instance or on all cluster members

Cloud Init¶

You can use the cloud-config file to auto-install RAX-Autoscaler on new servers. For example to do so on Rackspace cloud using supernova

supernova <region> boot –user-data ./cloud-config –image <image id/name> –flavor <flavor id/name> –config-drive=true <server name>

To use this with autoscale you would want to set the userdata of your launch configuration to the base64 encoded string of the file:

"launchConfiguration": {
      "args": {
          "server": {
              "config_drive" : true,
              "flavorRef": "general1-1",
              "imageRef": "CentOS 6.5 (PVHVM)",
              "key_name" : "MY_SSH_KEY",
              "user_data" : "I2Nsb3VkLWNvbmZpZwoKcGFja2FnZXM6CiAgLSBweXRob24tcGlwCgpydW5jbWQ6CiAgLSBbIHBpcCwgaW5zdGFsbCwgUkFYLUF1dG9TY2FsZXIgXQo=",
              "name": "test-autoscale"
          }
      },
      "type": "launch_server"
  }

This has been tested on these images:

• Ubuntu 14.04 LTS (PVHVM)
• CentOS 6.5 (PVHVM)

In the example the value of user_data contains the base64 encoded version of the following script:

echo -n "I2Nsb3VkLWNvbmZpZwoKcGFja2FnZXM6CiAgLSBweXRob24tcGlwCgpydW5jbWQ6CiAgLSBbIHBpcCwgaW5zdGFsbCwgUkFYLUF1dG9TY2FsZXIgXQo=" | base64 -D

To base64 encode a script :: cat /path/to/USER_DATA | base64

Size of USER_DATA can be reduced with gzip: :: cat /path/to/USER_DATA | gzip | base64

config.json¶

There are a few things to configure both on the Rackspace API side (essentially creating the autoscale group and setting the launch configuration) and on our side.

First up, create the autoscaling group in the portal and create 2 policies, 1 to scale up and another to scale down. The policy scale trigger should be set to webhook url.

The things we need now on the Rackspace side aren’t available in the portal so you’ll have to make use of https://cloud-api.info/ to quickly interact with the API. To login, you’ll need your API key which is available from the portal under the “Account Settings” screen.

I’m going to quote the config/config-template.json file to make it easier to explain

"autoscale_groups": {
    "group0": {

“group0” is just a name used internally by autoscale.py to make it easier for the user to reference the scaling group. It can stay as group0 or be changed to match what you’ve called the group in the portal

"group_id": "group id",

“group_id” is the UUID of the scaling group, this can be seen in the portal or in pitchfork by calling the “List Scaling Groups” API method https://cloud-api.info/autoscale/#list_scaling_groups-autoscale

"scale_up_policy": "scale up policy id",
"scale_down_policy": "scale down policy id",

scale_up_policy and scale_down_policy requires the UUID of the policies configured as webhooks in the portal. You can retrieve the UUID in pitchfork by calling the Get Policies List method https://cloud-api.info/autoscale/#get_policies_list-autoscale

"check_type": "agent.load_average",
"check_config": {},
"metric_name": "1m",

currently, the only check type we have is load_average (ram utilisation is on the backlog)

Webhook urls are an optional URL to call when we scale up or down. Pre is called before we call the Rackspace API, post is called after. You can configure multiple urls (or just a single url) to call at each stage.

Note¶

RAX-AutoScaler depends on Rackspace Monitoring Agent to get the data from nodes in scaling group.

If the agent is not installed please read: Install the Cloud Monitoring Agent: http://www.rackspace.com/knowledge_center/article/install-the-cloud-monitoring-agent

Contributing¶

• Fork it
• Create your feature branch (git checkout -b my-new-feature)
• Commit your changes (git commit -am ‘Add some feature’)
• Push to the branch (git push origin my-new-feature)
• Create new Pull Request

Monitoring Plugins¶

These plugins are used to provide different ways to determing whether to scale up or down. Currently there are 2 monitoring plugins available.

"raxmon":{
    "scale_up_threshold": 0.6,
    "scale_down_threshold": 0.4,
    "check_config": {},
    "metric_name": "1m",
    "check_type": "agent.load_average"
}

"raxclb":{
    "scale_up_threshold": 100,
    "scale_down_threshold": 10,
    "check_type": "SSL"
    "loadbalancers":[]
}

Creating Plugins¶

All monitoring plugins should inherit from raxas.core_plugins.base. You must implement a make_decision function that returns a 1 for scale up, -1, for scale down, or 0 for do nothing.:

from raxas.core_plugins.base import PluginBase
class Yourplugin(PluginBase):
    def __init__(self, scaling_group, config, args):
    super(Yourplugin, self).__init__(scaling_group, config, args)