Rackspace Auto Scale Tips and How To's


Table of Contents

How an Invalid Load Balancer can Prevent Scaling

If you create a scaling group with more than one load balancer and one of the load balancers was invalid (bad configuration), Auto Scale creates servers, tries to add them to the load balancers, discovers that one of the load balancers is invalid, and deletes the servers and removes the node from the valid load balancers as well. So, if an invalid load balancer exists in the launchConfiguration, the scaling group will never scale.

How to Delete Scaling Groups with Missing Servers

If you have manually deleted servers outside of Auto Scale, or want to delete a scaling group without using the force delete option provided in the API, and you have existing servers in the group, update both the minEntities and maxEntities to 0 in the scaling group configuration and then delete the group.

PUT v1.0/{tenantId}/groups/{groupId}/config
{"maxEntities": 0, "cooldown": 0, "name": "ready_to_be_deleted", "minEntities": 0, "metadata": {}}
DELETE v1.0/{tenantId}/groups/{groupId}

How the ServiceNet Dependency Can Cause your Server Creation to Fail

When you configure your Auto Scale scaling group with a load balancer, you must include the Rackspace ServiceNet network as part of the launch configuration. You cannot have only a private network in the launch configuration. This is because, in a scale-up operation, Auto Scale tries to retrieve the ServiceNet IP address of the server it builds to add to the load balancer and fails if ServiceNet is not part of the configuration. Due to this failure, Auto Scale recovers by deleting the built server. This results in no active servers. You can avoid this problem by adding ServiceNet to the list of networks for the Auto Scale group. In future, Auto Scale will disallow this by validating that ServiceNet network is part of the launch configuration if a load balancer is configured.

How to Connect Auto Scale to a Single Cloud Monitoring Alarm

This tip shows you how to use a webhook to trigger an Auto Scale policy. It does not explain how to create a check or an Auto Scale group.  For information on creating checks and alarms, see the Cloud Monitoring Developer’s Guide or Cloud Monitoring Checks and Alarms documentation in the Knowledge Center.

The example values used for the configurations should be modified to meet your needs. These values use the Auto Scale API to first create a webhook policy with a desired capacity of 5 servers and a cooldown of 3 minutes, and then create a webhook named Cloud Monitoring. In steps 3, 4, and 5 we use the Monitoring API to create a notification using the webhook URL created in step 2, a notification plan using the webhook ID created in step 3, and an alarm that uses the notification plan created in step 4.

  1. Create webhook policy

    POST/autoscale: v1.0//groups//policies
    [
    {
    "name": "set group to 5 servers",
    "desiredCapacity": 5,
    "cooldown": 1800,
    "type": "webhook"
    }
    }
  2. Create webhook for MaaS under webhook policy

    POST/autoscale: v1.0//groups/policies//webhooks
    [
    {
    "metadata": {},
    "name": "Cloud Monitoring"
    }
    ]
  3. Create Cloud Monitoring notification

    POST/monitoring: /notifications
    {
    "label": "AutoScale",
    "type": "webhook",
    "details": {
    "url": <webhook_URL_from_AutoScale>
    }
    }
  4. Create Cloud Monitoring notification plan

    POST/monitoring: /notification_plans
    {
    "label": "Notification Plan 1",
    "critical_state": [
    <notification_ID_from_AutoScale>"
    ],
    
    "warning_state": [
    ],
    }
    "ok_state": [
    ]
    }
  5. Create alarm in Cloud Monitoring

    POST/monitoring: /entities//alarms
    '{
    "check_id": "<check_you_want_to_use>",
    "criteria": "<criteria_you_want_to_use>",
    "notification_plan_id": "<notification_plan_you_just_created>"
    }

How to Quickly Add or Remove Servers

To quickly add or remove servers, send a request to change the value of the minEntities or maxEntities parameter, as documented in the Rackspace Auto Scale API Developer's guide section "Edit the Current Configuration for your Scaling Group." 

Example:

PUT //groups//config 
{ "name": "workers",
"cooldown": 60,
"minEntities": 5,
"maxEntities": 100,
"metadata": {
"firstkey": "this is a string",
"secondkey": "1", }
}

To remove a specific server from a scaling group, a new endpoint has been added to Auto Scale, DELETE server. For more information, see the Rackspace Auto Scale Developer's Guide Delete server from scaling group section.

How maxEntities and minEntities Settings Affect Scaling

If the number of active servers (desired capacity) in a scaling group is equal to the configured maxEntities value during a scale-up, or equal to the configured minEntities value during a scale-down, the call to execute the scaling policy returns a 400 Bad Request error response code with the message "No change in servers." If the number of active servers in a scaling group is less than the maxEntities value, the call to execute a scale-up policy returns a 200 OK response code and increases the number of servers to the maxEntities value or the amount specified.

If the number of active servers in a scaling group is greater than the minEntities value, the call to execute a scale-down policy returns a 200 OK response code and reduces the number of servers to the minEntities value or the amount specified.

The following diagram illustrates how the configured minimum and maximum number of servers in the scaling group restricts scale-ups and scale-downs.

How to Create and Update the launchConfiguration Setting

All update requests completely replace the item being updated. All requests except update launchConfiguration, validate that all fields are provided; a failed launchConfiguration update returns a 400 error response code. The following examples show how to create and update a launchConfiguration setting. Whereas creating uses a POST operation, updating uses a PUT operation.

Create a Scaling Group with the launchConfiguration Setting

This example creates a scaling group with load balancers, server metadata, networks and personality.

POST /<tenant_id>/groups
{
"launchConfiguration": {
"args": {
"loadBalancers": [
{
"port": 8080,
"loadBalancerId": 9099
}
],
"server": {
"name": "autoscale_server",
"imageRef": "0d589460-f177-4b0f-81c1-8ab8903ac7d8",
"flavorRef": "performance1-2",
OS-DCF:diskConfig": "AUTO",
"metadata": {
"build_config": "core",
"meta_key_1": "meta_value_1",
"meta_key_2": "meta_value_2"
},
"networks": [
{
"uuid": "11111111-1111-1111-1111-111111111111"
},
],
"uuid": "00000000-0000-0000-0000-000000000000"
"personality": [
{
"path": "/root/.csivh",
"contents": "VGhpcyBpcyBhIHRlc3QgZmlsZS4="
}
]
}
},
"type": "launch_server"
},
"groupConfiguration": {
"maxEntities": 10,
"cooldown": 360,
"name": "testscalinggroup198547",
"minEntities": 0,
"metadata": {
"gc_meta_key_2": "gc_meta_value_2",
"gc_meta_key_1": "gc_meta_value_1"
}
},
"scalingPolicies": [
{
"cooldown": 0,
"type": "webhook",
"name": "scale up by 1",
<"change": 1
}
]
}

Update launchConfiguration Setting Success

This example shows updating only the flavorRef and name parameters without the remaining fields, and a successful 204 response code.

PUT /<tenant_id>/groups/<group_id>/launch
{<
"type": "launch_server",
"args": {
"server": {
"flavorRef": performance1-4,
"name": "update_launch_config",
"imageRef": "0d589460-f177-4b0f-81c1-8ab8903ac7d8"
}}

Get launch config response:

GET /{tenant_id}/groups/{group_id}/launch (The load balancers, server's metadata, personality and networks are overwritten due to the update above)
{
"type": "launch_server",
"args": {
"server": {
"flavorRef": performance1-4,
"name": "update_launch_config",
"imageRef": "0d589460-f177-4b0f-81c1-8ab8903ac7d8"
}}}

Update launchConfiguration Eviction Policy

When a launchConfiguration setting is updated, the servers that scale up after the update use the latest launchConfiguration settings.

A scale-down that occurs after the launchConfiguration setting has been updated, first deletes servers with the older launchConfiguration setting. The only exception to this is when servers are building. Servers being built (pending) are deleted first in a scale-down policy execution, then servers with the older launchConfiguration setting, and last any other servers required by the scale-down policy.

Deleting Servers

About the Server "Active" State when Deleting Servers

Servers can be deleted only after they are in the Active state. For example, if a scale-up policy is executing to build five servers and while the servers are still building, a scale-down policy executes to scale down by two servers. You will see five servers until they are all done building and go into the Active state, immediately after which two servers will be deleted.

Deleting a Specific Server from a Scaling Group

To remove a specific server from a scaling group, a new endpoint has been added to Auto Scale, DELETE server. For more information, see the Rackspace Auto Scale Developer's Guide Delete server from scaling group section.

How to Choose the "Flavor" of a Server for a Scaling Group

If you create an image of a server with a certain amount of RAM, say 2GB RAM (flavorRef = 4 for standard, performance-4 for performance), and use that image to create a scaling group, you must choose the flavor in the scaling group that is equal to, or greater than, the flavor of the server from which the image was created.

How to do Cloud Bursting with Auto Scale and RackConnect

Autoscale + RackConnect allows bursting into the public cloud from events in a dedicated environment. RackConnect is provisioned by setting a metadata flag of a RackConnect Group in the Autoscale launchConfiguration metadata section, see example below. When that section is set properly, and Autoscale scales up a group, the new server will be modified by RackConnect to have it's public interface disabled, and will begin receiving Private Cloud traffic from the RackConnect Load Balancer. There is a KC article that describes this process in detail, see Cloud Bursting Using Auto Scale Rackconnect and F5 Load Balancers.

Example RackConnect metadata key/value pair for Auto Scale:

"metadata": { 
"RackConnectLBPool": "MyRCPoolName"
}

How to use Auto Scale to change the size of your performance server

The new Rackspace Performance Servers do not resize as simply as the First Gen servers. You have to go through a process, detailed in Changing the size of your performance server in order to resize, and you don't keep your IP address. You can use Auto Scale to accomplish performance server resizing keeping your IP address, and have it happen dynamically in response to load. You pay for the higher-flavor servers only when you need them, when you don't need them, you can scale back down to lower-flavor servers—or keep the higher-flavor servers and just scale back how many servers are in your group.

Auto Scale allows you to create scaling groups: a construct based on a single, configured server (that will boot at startup) and a set of launch configurations for new servers, including flavor, that will be created on-demand from that server image. And scaling policies (up and down): a configuration that triggers the creation-or destruction-of new servers, in response to either a set schedule or a monitoring alert (typically based on load). And the best part is…Auto Scale is a free service for all Rackspace Cloud accounts.

To do this, you will want to familiarize yourself with Auto Scale, start Getting started with Rackspace Auto Scale. When you're ready to set up your scaling system, use the following guidelines.

  1. Create two scaling groups: one with a lower-flavor for the server setting in the launchConfiguration option, and another with higher-flavor server setting in the launchConfiguration. Configure both scaling groups with same image and load balancer. 

  2. Create two policies for each scaling group: 

    ◦   One policy with desiredCapcity=0

    ◦   One with desiredCapacity=2 or 3  (that is: scale up by 2 or 3). 

When you want a higher flavor server, execute the scale up policy on with the high-flavor scaling group and desired=0 policy on the low-flavor group. Do vice-versa when switching from high flavor to low flavor.

This will work well for single server deployments. In fact, for smaller deployments, the scale up policy might just be +1 instead of 2 or 3.

One disadvantage of this technique is being charged for load balancer when you don't really need it. But that cost should be offset by the scaling down, using lower-flavor (and less expensive) servers when load is lighter.



Was this content helpful?




© 2014 Rackspace US, Inc.

Except where otherwise noted, content on this site is licensed under a Creative Commons Attribution-NonCommercial-NoDerivs 3.0 Unported License


See license specifics and DISCLAIMER