Rackspace Auto Scale Control Panel User Guide - Concepts
In the Introduction to Rackspace Auto Scale, we reviewed an outline of what you can do with Auto Scale and what is required for its setup. In this section we will discuss what Auto Scale does and the core concepts that drive it.
Before you use Rackspace Auto Scale, there are a few concepts that you should understand.
A server is defined as a virtual machine (VM) instance in the Rackspace Cloud Servers environment. To create a server, you must specify a name, image reference, and flavor reference. Server images and flavors are explained in this section.
Auto Scale works by creating servers that are based on server images that you have predefined. So, before you can use Auto Scale, you must have saved server images. If you create a server by using the Cloud Servers tab in the Cloud Control Panel and save the image, the image automatically appears in the Auto Scale tab.
A server image is a copy of a server's disk. It contains the operating system and all of the installed data and software on the server at the time the image was taken. Multiple, identical servers can be created from the same server image through the use of tools such as Auto Scale. A server image can be a base operating system installation, much like you would use to create a new cloud server before installing software on it, or it can contain all of the software necessary for a server to start operating. For example, a web server set to respond to HTTP requests after it finishes starting. A server image does not include configuration details such as IP address, server flavor, server networks, or mounted volumes. As a result, a given server image can be applied to servers that have different configurations than the master server from which the image was generated, as long as the instance type has as much or more disk storage as the original instance.
When you are configuring an image with software to use with Auto Scale, be sure to use dynamic elements instead of static elements. All of the files on cloned server images are identical, so if you are using hardcoded machine IDs in configuration files on the master server image, multiple systems will use the same hardcoded machine ID. Your server should be set to use DHCP to obtain an IP address, and other network parameters. The Rackspace Cloud Monitoring agent is designed to behave correctly when installed on server images using the same configuration file. Server images are available only in the region in which they were generated. Server images can be created such that they update themselves at start up with the newest version of software. Or you can create a new image and edit the scaling group to incorporate new software versions.
The server flavor is the amount of CPU, RAM, system disk, networks (the aggregate outbound bandwidth across all attached networks), and disk I/O that you assign when you configure a server. For example, the 512MB Standard Instance server flavor corresponds to 1 vCPU, 512MB RAM, 20GB System Disk, 80 Mb/s Network, and Good Disk I/O.
The server networks that you choose are all of the networks on which your service operates.
A scaling group is a set of identical servers and, optionally, a load balancer, defined by the launch configuration that you set. The group can scale up and down in response to load, as defined by the scaling policy that you configure and bound by your scaling group configuration.
Cooldowns enforce a period of time between possible actions. Auto Scale has the following types of cooldowns:
- Minimum (group) Cooldown: Use to enforce a minimum amount of time for your servers to scale up. The complexity of the servers that you are adding, not the number of servers, determines how much time they need to fully deploy. A 10-minute minimum cooldown is sufficient for most server images.
- Policy Cooldown: Use to prevent a policy from being triggered too soon. For scale-up policies, a longer policy cooldown is usually acceptable, whereas you might want a short policy cooldown for scale-down policies, ensuring a gradual removal of servers.
Note: Cooldowns are mainly relevant to event-based scaling policies because those policies are triggered by events that could occur before a required cooldown period. Schedule-based policies in conflict with a cooldown period will not execute.
The following graph illustrates how cooldowns affect policy execution.
The scaling policy determines what kind of scaling occurs—up or down—and when scaling occurs. You must define separate polices for scaling up and scaling down. You can have multiple scaling policies per scaling group.
For schedule-based policies, you can use a cron job to configure the schedule. At the specified time, Auto Scale adds servers or removes them as dictated by the policy.
You can also configure the scale-up and scale-down to be a set number, or a percentage of your total scaling group.
And, you can use a webhook to respond to an event and trigger a policy. You can create the policy with the webhook using the Control Panel, but you will have to use the Auto Scale API to create and configure the webhook. You can learn more about webhooks in the Auto Scale API Dev guide section Create and Manage Webhooks.
The following diagrams illustrate some of the principles governing scaling policies.
The following diagram illustrates how a percentage scale-up policy translates into a different amount of scaling each time that it is invoked and changes the total number of servers.
The following diagram illustrates how a scheduled scale-up policy can be configured to respond to anticipated increases in traffic.
The following diagram illustrates how the configured minimum and maximum number of servers in the scaling group restricts scale-ups and scale-downs.
The following diagram illustrates how a scale-down policy operates first on pending servers (servers in the process of being added) and then on the oldest servers in the scaling group.
A properly configured load balancer automatically distributes traffic to the least-loaded servers. The load balancer configuration in your scaling group is optional. If you do configure a load balancer, choose from the load balancers that you have added to your cloud server account. The load balancer sends traffic to your cloud servers on the node port that you configure.
User Guide Sections
- Rackspace Auto Scale Control Panel User Guide - Introduction
- Rackspace Auto Scale Control Panel User Guide - Concepts
- Rackspace Auto Scale Control Panel User Guide - Creating Scaling Groups
- Rackspace Auto Scale Control Panel User Guide - Creating Scaling Policies
© 2011-2013 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