# Auto-Scaling Groups
## Overview
Auto-scaling provides an automated mechanism for managing the number of VM
instances. Instances will automatically be created or deleted in case of failure
or changes in application load, thus assuring that the right number of instances
are always available.
To implement auto-scaling, create collections of VM instances, called scaling
groups. A simple auto-scaling group can be created with a specified number
of instances. The auto-scaling group will maintain the specified number of
instances by creating a new instance to replace an instance which fails.
Policies can be added to an auto-scaling group in order to instruct the group
to maintain a performance metric as close as possible to a threshold. For example,
if a threshold is set for 50% CPU load, the auto-scaling group will automatically
create or terminate instances as the application load changes, so that CPU usage
will not exceed the specified threshold.
An auto-scaling group can also detect faulty instances, terminate them, and
create new instances to replace them.
Auto-scaling can be implemented on target groups, so that instances created
through auto-scaling, are automatically associated with the same target group.
This ensures that traffic load forwarded to a target group will include instances
created with auto-scaling.
For easier classification of VMs, tags can be created and applied to
auto-scaling groups. Based on the auto-scaling group configuration,
tags can be automatically propagated to VM instances during their launch.
## Implementing Auto-scaling Groups
Auto-scaling group implementation includes the following:
1. Creation of a launch configuration template which specifies the type of VM
instances created with auto-scaling. For example, a launch configuration
would specify the image to be used, instance type, key pairs, and security
groups. When an auto-scaling group automatically adds a new VM instance,
the new VM inherits the characteristics defined in the scaling group’s launch
configuration.
2. Specification of parameters related to the auto-scaling group such as the
number of instances that are available to the group, the metrics to monitor
when determining appropriate group size, the type of health checks to use,
and various other settings.
### Creating Launch Configurations
To create a launch configuration:
1. Navigate to the **Compute** > **Launch Config** view and select **Create**.
The Create Launch Configuration window is displayed with two tabs: **details**
and **images**.
2. In the **details** tab, configure:
* **Name** - name of the launch configuration to be created.
* **Description** - description that will help identify the launch
configuration.
* **Instance Type** - defines the compute resources (CPU and RAM).
* **VPC** - subnet of VPC in which the VM instances will be created. An
IP address in this range will automatically be assigned to the VM instance
upon creation, thus enabling the instances to communicate with other instances
in the VPC.
* **Security Groups** - (Optional) security group that will be used to
limit/allow connectivity to the launched VM instance.
* **Key Pair** - (Optional) the set of security credentials that will be
used to ensure the identity of the user when connecting to the launched
VM instance. You may either generate a new key or upload a key generated
from another tool.
* **Read cloud-init from file** - (Optional) drag and drop a cloud-init
file to be used to initialize the launched VM instance post creation.
3. Click **Next**. The Image tab is displayed.
4. Select an image from available list or click **+** to create a new source
image.
5. Use the **Override Block Device Mapping** option to either use the default
block device mapping associated with the selected image, or slide the selector
to the right position to override the default mapping. When override option
is selected, configure the following:
* **Snapshot-Volume** – select the Snapshot/Volume to be used for the block
device mapping.
* **Volume Type** - select the volume type from the dropdown list.
* **Override Size** - option to keep default size, or slide the selector
to override the default, and enter the new size.
* To add **Data Volumes** click **Add**, and select a volume from the
dropdown list or create a new volume.
6. Click **OK**. The image creation begins and its progress is displayed. When
completed, the **Action Succeeded** message is displayed in the top right
of the window, and the image is displayed in Launch Configuration list.
### Creating Auto-scaling Groups
#### Creating Auto-scaling Groups (UI)
To create an auto-scaling group in the zCompute UI:
1. Navigate to the **Compute** > **Auto-Scaling Groups** view and select **Create**.
The **Create Auto-Scaling Group** window is displayed with three tabs:
**Group Setup**, **Scaling Policy**, and **Advanced**.
2. In the **Group Setup** tab, configure:
* **Name** - name of the auto-scaling group.
* **Description** - description that will help identify the auto-scaling group.
* **Size Limit** - minimum and maximum numbers of instances that the group
can contain.
* **Desired Capacity** - target number of VM instances in the group. Use
of this field depends on scaling policy configuration in the following tab
as follows:
- **When no scaling policy is set**: The desired capacity is the number
of instances to be created in the group. It must be within the limits
of the defined minimum and maximum. If no capacity is specified when
the group is created, the system sets **Desired Capacity** to the minimum
size in the **Size Limit** field.
- **When scaling policy is set**: The desired capacity is the initial
number of instances, after which the scaling policies can change the
number of instances in the group.
* **Subnet** - select the subnet from the drop-down list or select **+** to
: define a new subnet.
* **Launch Configuration** - select the launch configuration from the drop-down
list or select **+** to define a new one.
* **Tags** - select tag from the drop-down list or select **+** to define
a new tag.
3. Click **Next**. The **Scaling Policy** tab is displayed. A policy can be
set separately for **CPU Utilization**, **Network Traffic - In**, or
**Network Traffic - Out**. If no scaling policy is desired, leave the slider
in the default, left position. To set a scaling policy for any of the metrics,
move the slider to the right and configure as follows:
* **Estimated Warm-up** - time (in seconds) until newly launched VM instance
contributes to the scaling group aggregated metrics.
* **Target** - above which alarm will trigger the scaling policy.
* **Disable Scale-in** - disable scale-in (deletion of VM instances).
4. Click **Next**. The **Advanced** tab is displayed. Configure as follows:
* **Health Check** - mechanism used to determine the health of a VM instance
in the scaling group.
- **VM Health** - use VMware’s VM Monitor tool.
- **Target Group** - use ELB health checks. This choice is available
only if scaling group is associated with a load balancer target group.
* **Target Groups** - select the target group from the drop-down list or
select **+** to define a new one.
* **Operation Cooldown** - minimal number of seconds between the completion
of one scaling activity and the commencement of any other scaling activity.
The cooldown period helps to ensure that auto-scaling doesn’t launch or
terminate additional instances before the previous scaling activity takes
effect.
* **Health Check Grace Period** - minimal length of time before checking
the health status of an instance.
* **Termination Policies** - policies to determine which instances will be
terminated in case of a scale-in event. Select one of the following from
the drop-down list.
- **Default** - terminate instances that have the oldest launch configuration.
- **Newest Instance** - terminate the newest instance in the group.
This policy is recommended when testing new launch configurations
which should not be left in production.
- **Oldest Instance** - terminate the oldest instance in the group.
This policy is recommended when upgrading VM instances in the auto-scaling
group to a new VM instance type. With this policy, older VM instances will
gradually be replaces with new ones.
- **Oldest Launch Configuration** - terminate the instance with the oldest
launch configuration. This policy is recommended when updating a group
and phasing out instances from a previous configuration.
* **Protect Instances from Scale-In** - when selected, newly launched instances
are protected from termination during scale-in.
5. Click **Finish**. When scaling policy creation is completed, the
**Action Succeeded** message is displayed in the top right of the window,
and the policy is displayed in the **Compute** > **Auto-Scaling Group** list.
#### Creating Auto-scaling Groups (CLI)
This example details the Symp CLI commands to create an auto-scaling group
that will propagate tags to VM instances on their launch.
It assumes an existing launch configuration.
1. At the Symp command line, list the projects to retrieve the project ID.
```console
project list -c id -c name
+----------------------------------+---------------------------+
| id | name |
+==================================+===========================+
| 7ff34832b6754f7d91a918302af3e77f | vpcproj1 |
| 983e87bd7687406dab90d0cda917233e | dvsproj1 |
+----------------------------------+---------------------------+
```
2. List the launch configurations for the project, to
retrieve the ID of the launch configuration that will be used by the
new auto-scaling group:
```console
autoscaling-groups launch-configuration list -c id -c name -c project_id -m grep-i=
```
For example:
```console
autoscaling-groups launch-configuration list -c id -c name -c project_id -m grep-i=7ff34832b6754f7d91a918302af3e77f
+--------------------------------------+----------+----------------------------------+
| id | name | project_id |
+======================================+==========+==================================+
| 19be0309-7159-440b-a537-b08475ed96d5 | launchc1 | 7ff34832b6754f7d91a918302af3e77f |
| a59a72f5-2067-4fdf-bf0e-fa5420848628 | launchc2 | 7ff34832b6754f7d91a918302af3e77f |
+--------------------------------------+----------+----------------------------------+
```
3. Create a new autoscaling group that will use the launch configuration ID
retrieved in the earlier step.
```console
autoscaling-groups group create --propagated-tags
```
For example:
```console
autoscaling-groups group create vpcgroup1 19be0309-7159-440b-a537-b08475ed96d5 1 3 --propagated-tags vpctag1 vpctag2
+---------------------------------------+---------------------------------------------+
| id | 8e248f96-637e-44ee-8161-0ff3e999e137 |
| name | vpcgroup1 |
| status | active |
| account_id | default |
| availability_zones | [] |
| created_at | 2023-10-31T13:20:41 |
| default_cooldown | 60 |
| description | |
| desired_capacity | 1 |
| health_check_grace_period | 300 |
| health_check_type | vm_monitor |
| honor_cooldown | true |
| instance_count | 0 |
| instances | [] |
| launch_configuration_id | 19be0309-7159-440b-a537-b08475ed96d5 |
| max_size | 3 |
| min_size | 1 |
| new_instances_protected_from_scale_in | false |
| placement_policy | none |
| project_id | 7ff34832b6754f7d91a918302af3e77f |
| scaling_policies | [] |
| service_linked_role | none |
| subnets | 6ff5209c-edd4-4620-9d81-e342f5e0d79d |
| suspended_processes | [] |
| +---------------------------------------------+
| tags | 7ff34832b6754f7d91a918302af3e77f:vpctag1 |
| | 7ff34832b6754f7d91a918302af3e77f:vpctag2 |
| +---------------------------------------------+
| target_group_ids | [] |
| termination_policies | default |
| updated_at | 2023-10-31T13:20:41 |
| user_id | 7918794e5d9849de90b3a8986d1085e6 |
+---------------------------------------+---------------------------------------------+
```
## Load Balancing and Auto-scaling Groups
Auto-scaling groups can be associated with a load balancer’s target group to guarantee
there will be a sufficient number of VM instances to which an application’s
load can be distributed.
For example, consider a scenario with the following sample entities:
* MyApplication
* LoadBalancerA
* TargetGroupA
* ScalingGroupA
**Scenario Description**:
1. MyApplication directs its requests to LoadBalancerA.
2. LoadBalancerA is associated with TargetGroupA. TargetGroupA has just
one instance.
3. ScalingGroupA is managing 20 instances and scaling the number of VM
instances if needed. ScalingGroupA is also associated with TargetGroupA.
4. Because of this association, LoadBalancerA can distribute the workload of
MyApplication among 21 instances; one in TargetGroupA and 20 in
ScalingGroupA.