Using Auto Scaling

• 1: How Auto Scaling Works
• 2: Auto Scaling Concepts
• 2.1: Understanding Launch Configurations
• 2.2: Understanding Auto Scaling Groups
• 2.3: Understanding Auto Scaling Policies
• 2.4: Understanding Health Checks
• 2.5: Understanding Instance Termination Policies
• 3: Auto Scaling Usage Examples
• 3.1: Creating a Basic Auto Scaling Configuration
• 3.2: Configuring a Demand-Based Scaling Policy
• 3.3: Configuring Health Checks
• 3.4: Configuring an Instance Termination Policy
• 3.5: Configuring Auto Scaling with Elastic Load Balancing

1 - How Auto Scaling Works

Eucalyptus Auto Scaling is designed to address a common web application scenario: that you are running multiple copies of an application across several identical instances to adequately handle a certain volume of user requests. Eucalyptus Auto Scaling can help you make more efficient use of the computing resources in your cloud by automatically launching and terminating these instances, based on metrics and/or a schedule that you can define. There are three main Auto Scaling components that work together to provide this functionality: the Auto Scaling group , the launch configuration , and the scaling plan .

The Auto Scaling group contains the information about the instances that will be actually be used for scaling operations. The Auto Scaling group defines the minimum, desired, and maximum number of instances that you will use to scale your application.

The launch configuration contains all of the information necessary for Auto Scaling to launch instances, including instance type, image ID, key pairs, security groups, and block device mappings.

The scaling policy defines how to perform scaling actions. Scaling policies can execute automatically in response to CloudWatch alarms, or they you can execute them manually.

In addition to performing scaling operations based on the criteria defined in the scaling plan, Auto Scaling will periodically perform health checks to ensure that the instances in your Auto Scaling group are up and running. If an instance is determined to be unhealthy, Auto Scaling will terminate that instance and launch a new instance in order to maintain the minimum or desired number of instances in the scaling group.

2 - Auto Scaling Concepts

Auto Scaling Concepts

This section discusses Auto Scaling concepts and terminology.

2.1 - Understanding Launch Configurations

The launch configuration defines the settings used by the Eucalyptus instances launched within an Auto Scaling group. This includes the image name, the instance type, key pairs, security groups, and block device mappings. You associate the launch configuration with an Auto Scaling group. Each Auto Scaling group can have one (and only one) associated launch configuration.

Once you’ve created a launch configuration, you can’t change it; you must create a new launch configuration and then associate it with an Auto Scaling group. After you’ve created and attached a new launch configuration to an Auto Scaling group, any new instances will be launched using parameters defined in the new launch configuration; existing instances in the Auto Scaling group are not affected.

For more information, see Creating a Basic Auto Scaling Configuration .

2.2 - Understanding Auto Scaling Groups

An Auto Scaling group is the central component of Auto Scaling. An Auto Scaling group defines the parameters for the Eucalyptus instances are used for scaling, as well as the minimum, maximum, and (optionally) the desired number of instances to use for Auto Scaling your application. If you don’t specify the desired number of instances in your Auto Scaling group, the default value will be the same as the minimum number of instances defined.

In addition to instance and capacity definitions, each Auto Scaling group must specify one (and only one) launch configuration.

For more information, see Creating a Basic Auto Scaling Configuration .

2.3 - Understanding Auto Scaling Policies

An Auto Scaling policy defines how to perform scaling actions in response to CloudWatch alarms. Auto scaling policies can either scale-in , which terminates instances in your Auto Scaling group, or scale-out , which will launch new instances in your Auto Scaling group. You can define an Auto Scaling policy based on demand, or based on a fixed schedule.

Demand-Based Auto Scaling Policies

Demand-based Auto Scaling policies scale your application dynamically based on CloudWatch metrics (such as average CPU utilization) gathered from the instances running in your scaling group. For example, you can configure a CloudWatch alarm to monitor the CPU usages of the instances in your Auto Scaling group. A CloudWatch alarm definition includes thresholds - minimum and maximum values for the defined metric - that will cause the alarm to fire.

Cooldown Period

A cooldown period is the amount of time after an Auto Scaling activity takes place where further Auto Scaling activity is suspended. This is to allow time for the Auto Scaling activities (such as new instance launches or terminations) to fully complete so that resources are not unnecessarily launched or terminated. You can specify this amount of time; if you don’t specify a cooldown period, Auto Scaling uses a default cooldown period of 300 seconds (5 minutes).

For more information, go to Configuring a Demand-Based Scaling Policy .

2.4 - Understanding Health Checks

Auto scaling periodically performs health checks on the instances in your Auto Scaling group. By default, Auto Scaling group determines the health state of each instance by periodically checking the results of Eucalyptus instance status checks. When Auto Scaling determines that an instance is unhealthy, it terminates that instance and launches a new one.

If your Auto Scaling group is using elastic load balancing, Auto Scaling can determine the health status of the instances by checking the results of both Eucalyptus instance status checks and elastic load balancing instance health.

Auto scaling determines an instance is unhealthy if the calls to either Eucalyptus instance status checks or elastic load balancing instance health status checks return any state other than OK (or  InService ).

If there are multiple elastic load balancers associated with your Auto Scaling group, Auto Scaling will make health check calls to each load balancer. If any of the health check calls return any state other than  InService , that instance will be marked as unhealthy. After Auto Scaling marks an instance as unhealthy, it will remain marked in that state, even if subsequent calls from other load balancers return an  InService  state for the same instance.

For more information, go to Configuring Health Checks .

2.5 - Understanding Instance Termination Policies

Before Auto Scaling selects an instance to terminate, it first identifies the availability zone used by the group that contains the most instances. If all availability zones have the same number of instances, Auto Scaling selects a random availability zone, and then uses the termination policy to select the instance within that randomly selected availability zone for termination.

By default, Auto Scaling chooses the instance that was launched with the oldest launch configuration. If more than one instance was launched using the oldest launch configuration, Auto Scaling the instance that was created first using the oldest launch configuration.

You can override the default instance termination policy for your Auto Scaling group with one of the following options:

You can have more than one termination policy per Auto Scaling group. The termination policies are executed in the order they were created.

For more information, go to Configuring an Instance Termination Policy .

3 - Auto Scaling Usage Examples

Auto Scaling Usage Examples

This section contains examples of many common usage scenarios for Auto Scaling.

3.1 - Creating a Basic Auto Scaling Configuration

Auto scaling requires two basic elements to function properly: a launch configuration and an Auto Scaling group. The following examples show how to set up the basic elements of an Auto Scaling configuration.

Create a Launch Configuration

The launch configuration specifies the parameters that Auto Scaling will use when launching new instances for your Auto Scaling group. In this example, we will create a launch configuration with the minimum required parameters - in this case, we set up a launch configuration that specifies that all instances launched in the Auto Scaling group will be of instance type and use the image.To create a launch configuration:

Enter the following command: euscale-create-launch-config MyLaunchConfig --image-id emi-00123456 --instance-type m1.small To verify the launch configuration, enter the following command: euscale-describe-launch-configs MyLaunchConfig You should see output similar to the following:

LAUNCH-CONFIG	MyLaunchConfig	emi-00123456	m1.small

You’ve now created a launch configuration..

Create an Auto Scaling Group

The Auto Scaling group contains settings like the minimum, maximum, and desired number of Eucalyptus instances. At minimum, you must specify the name of the Auto Scaling group, the name of an existing launch configuration, the availability zone, and the minimum and maximum number of instances that should be running. In the following example, we will create an Auto Scaling group called MyScalingGroup in availability zone PARTI00, with a minimum size of 2 and a maximum size of 5.To create an Auto Scaling group: Enter the following command:

euscale-create-auto-scaling-group MyScalingGroup --launch-configuration
                    		MyLaunchConfig --availability-zones PARTI00 --min-size 2 --max-size 5
                    		--desired-capacity 2

Enter the following command to verify the Auto Scaling group you just created:

euscale-describe-auto-scaling-groups MyScalingGroup

This command will return output similar to the following:

AUTO-SCALING-GROUP	MyScalingGroup	MyLaunchConfig	PARTI00		2	5	2	Default
INSTANCE	i-1B853EC3	PARTI00	InService	Healthy	MyLaunchConfig
INSTANCE	i-ABC53ED7	PARTI00	InService	Healthy	MyLaunchConfig

Once you’ve created the Auto Scaling group, Auto Scaling will launch the appropriate number of instances.

3.2 - Configuring a Demand-Based Scaling Policy

An Auto Scaling group needs a scaling policy to determine when to perform scaling activities. Auto scaling policies work with CloudWatch to identify metrics and set alarms, which are triggered when the metrics fall outside of a specified value range. To configure a scale-based policy, you need to create the policy, and then create CloudWatch alarms to associate with the policy.In the following example, we will create a demand-based scaling policy.

Create Auto Scaling Policies

To create the scaling policies:

Create a scale-out policy using the following command:

euscale-put-scaling-policy MyScaleoutPolicy --auto-scaling-group MyScalingGroup --adjustment=30 --type PercentChangeInCapacity

This command will return a unique Amazon Resource Name (ARN) for the new policy.

arn:aws:autoscaling::706221218191:scalingPolicy:5d02981b-f440-4c8f-98f2-8a620dc2b787:
    autoScalingGroupName/MyScalingGroup:policyName/MyScaleoutPolicy

Create a scale-in policy using the following command:

euscale-put-scaling-policy MyScaleinPolicy -g MyScalingGroup --adjustment=-2  --type ChangeInCapacity

This command will return output containing a unique Amazon Resource Name (ARN) for the new policy, similar to the following:

arn:aws:autoscaling::706221218191:scalingPolicy:d28c6ffc-e9f1-4a48-a79c-8b431794c367:
    autoScalingGroupName/MyScalingGroup:policyName/MyScaleinPolicy

Create CloudWatch Alarms

To create CloudWatch alarms:

Create a Cloudwatch alarm for scaling out when the average CPU usage exceeds 80 percent:

euwatch-put-metric-alarm AddCapacity  --metric-name CPUUtilization --unit Percent
--namespace "AWS/EC2" --statistic Average --period 120 --threshold 80 --comparison-operator 
GreaterThanOrEqualToThreshold --dimensions "AutoScalingGroupName=MyScalingGroup" 
--evaluation-periods 2 --alarm-actions 
arn:aws:autoscaling::706221218191:scalingPolicy:5d02981b-f440-4c8f-98f2-8a620dc2b787:
   autoScalingGroupName/MyScalingGroup:policyName/MyScaleoutPolicy

Create a Cloudwatch alarm for scaling in when the average CPU usage falls below 40 percent:

euwatch-put-metric-alarm RemoveCapacity --metric-name CPUUtilization --unit Percent
--namespace "AWS/EC2" --statistic Average  --period 120  --threshold 40  --comparison-operator 
LessThanOrEqualToThreshold  --dimensions "AutoScalingGroupName=MyScalingGroup" --evaluation-periods 2 
--alarm-actions 
 arn:aws:autoscaling::706221218191:scalingPolicy:d28c6ffc-e9f1-4a48-a79c-8b431794c367:
  autoScalingGroupName/MyScalingGroup:policyName/MyScaleinPolicy

Verify Your Alarms and Policies

Once you’ve created your Auto Scaling policies and CloudWatch alarms, you should verify them.To verify your alarms and policies:

Use the CloudWatch command euwatch-describe-alarms to see a list of the alarms you’ve created:

euwatch-describe-alarms 

This will return output similar to the following:

AddCapacity	INSUFFICIENT_DATA	arn:aws:autoscaling::706221218191:scalingPolicy:5d02981b-f440-4c8f-98f2-8a620dc2b787:
   autoScalingGroupName/MyScalingGroup:policyName/MyScaleoutPolicy	
   AWS/EC2	CPUUtilization	120	Average	2	GreaterThanOrEqualToThreshold	80.0
RemoveCapacity	INSUFFICIENT_DATA	arn:aws:autoscaling::706221218191:scalingPolicy:d28c6ffc-e9f1-4a48-a79c-8b431794c367:
autoScalingGroupName/MyScalingGroup:policyName/MyScaleinPolicy	
   AWS/EC2	CPUUtilization	120	Average	2	LessThanOrEqualToThreshold	40.0

Use the euscale-describe-policies command to see the scaling policies you’ve created:

euscale-describe-policies --auto-scaling-group MyScalingGroup

This will return output similar to the following (note that this output has been split into multiple lines for legibility):

SCALING-POLICY	MyScalingGroup	MyScaleinPolicy	-2	ChangeInCapacity	arn:aws:autoscaling::706221218191:
  scalingPolicy:d28c6ffc-e9f1-4a48-a79c-8b431794c367:
  autoScalingGroupName/MyScalingGroup:policyName/MyScaleinPolicy
SCALING-POLICY	MyScalingGroup	MyScaleoutPolicy	30	PercentChangeInCapacity	arn:aws:autoscaling::706221218191:
  scalingPolicy:5d02981b-f440-4c8f-98f2-8a620dc2b787:
  autoScalingGroupName/MyScalingGroup:policyName/MyScaleoutPolicy

3.3 - Configuring Health Checks

By default, Auto Scaling group determines the health state of each instance by periodically checking the results of instance status checks. You can specify using the ELB health check method in addition to using the instance health check method.To use load balancing health checks for an Auto Scaling group:

Use the following command to specify ELB health checks for an Auto Scaling group:

euscale-update-auto-scaling-group MyScalingGroup –-health-check-type ELB –-grace-period 300 

3.4 - Configuring an Instance Termination Policy

You can control how Auto Scaling determines which instances to terminate. You can specify a termination policy when you create an Auto Scaling group, and you can change the termination policy at any time using the command.You can override the default instance termination policy for your Auto Scaling group with one of the following options:

To configure an instance termination policy:

Specify the –termination-policies parameter when creating or updating the Auto Scaling group. For example:

euscale-update-auto-scaling-group MyScalingGroup --termination-policies "NewestInstance"

Verify that your Auto Scaling group has updated the termination policy by running the following command: euscale-describe-auto-scaling-groups MyScalingGroup This command should return output similar to the following:

AUTO-SCALING-GROUP	MyScalingGroup	MyLaunchConfig	PARTI00		2	5	2	NewestInstance
INSTANCE	i-1B853EC3	PARTI00	InService	Healthy	MyLaunchConfig
INSTANCE	i-ABC53ED7	PARTI00	InService	Healthy	MyLaunchConfig

3.5 - Configuring Auto Scaling with Elastic Load Balancing

This example shows how to set up Auto Scaling with Elastic Load Balancing.To set up a load-balanced auto scaling configuration:

If you don’t already have a launch configuration, create one: euscale-create-launch-config MyLaunchConfig --image-id emi-50783D25 --instance-type m1.medium --group mysecuritygroup Create a new auto scaling group associated with a load balancer: euscale-create-auto-scaling-group MyScalingGroup --launch-configuration MyLaunchConfig --load-balancers MyLoadBalancer --availability-zones AcmeAvailabilityZone --min-size 2 --max-size 4 Authorize the security group used by the load balancer for back-end port communication. For example:

$ eulb-describe-lbs --show-long
LOAD_BALANCER	MyLoadBalancer	MyLoadBalancer-408396244283.elb.acme.eucalyptus-systems.com			
{interval=200,target=HTTP:80/,timeout=3,healthy-threshold=2,unhealthy-threshold=4}		AcmeAvailabilityZone		
{protocol=HTTP,lb-port=80,instance-protocol=HTTP,instance-port=80}					
{owner-alias=944786667073,group-name=euca-internal-408396244283-MyLoadBalancer}		
2014-05-28T18:13:17.902Z

euca-authorize mysecuritygroup -u 944786667073 -o euca-internal-408396244283-MyLoadBalancer -p -1 Verify that your Auto Scaling group has been created with a load balancer:

$ euscale-describe-auto-scaling-groups
AUTO-SCALING-GROUP	MyScalingGroup	MyLaunchConfig	AcmeAvailabilityZone	MyLoadBalancer	2	4	2	Default
INSTANCE	i-DFCD0CBC	AcmeAvailabilityZone	InService	Healthy	MyLaunchConfig
INSTANCE	i-B3431043	AcmeAvailabilityZone	InService	Healthy	MyLaunchConfig