AWS EC2自动缩放组: 我得到了最小和最大值,但是期望的实例限制是什么?

当您在 AWS EC2 MinMax边界中设置自动缩放组时,似乎是有意义的:

  • 根据政策缩减至最低数量
  • 根据政策扩大规模的最大数量

然而,我从来没有能够理解 Desired到底想要影响什么。

我总是将 Desired设置为等于 Min,因为一般来说,我希望向亚马逊支付尽可能少的什一税,除非你需要一个实例来处理加载,否则它应该在 Min的数量。

我知道如果你使用 ElasticBeanstalk并且将 Min设置为1,将 Max设置为2,那么它将 Desired设置为2(当然!)你不能为 Desired选择一个值。

不同的 Desired数量的用例是什么? 它们有什么不同?当你期望 AWS 的规模低于你的 Desired,如果想要的是大于 Min

44702 次浏览

Think about it like a sliding range UI element.

enter image description here

With min and max, you are setting the lower bound of your instance scaling. Withe desired capacity, you are setting what you'd currently like the instance count to hover.

Example: You know your application will have heavy load due to a marketing email or product launch...simply scale up your desired capacity beforehand:

aws autoscaling set-desired-capacity --auto-scaling-group-name my-auto-scaling-group --desired-capacity 2 --honor-cooldown

Source

Here are the explanations for the "min, desired and max" values from AWS support:

MIN: This will be the minimum number of instances that can run in your auto scale group. If your scale down CloudWatch alarm is triggered, your auto scale group will never terminate instances below this number

DESIRED: If you trip a CloudWatch alarm for a scale up event, then it will notify the auto scaler to change it's desired to a specified higher amount and the auto scaler will start an instance/s to meet that number. If you trip a CloudWatch alarm to scale down, then it will change the auto scaler desired to a specified lower number and the auto scaler will terminate instance/s to get to that number.

MAX: This will be the maximum number of instances that you can run in your auto scale group. If your scale up CloudWatch alarm stays triggered, your auto scale group will never create instances more than the maximum amount specified.

When you expect AWS to scale lower than your Desired if desired is larger than Min?

This happens when you set a CloudWatch alarm based on some AutoScaling policy. Whenever that alarm is triggered it will update the DesiredCount to whatever is mentioned in config.

e.g., If an AutoScalingGroup config has Min=1, Desired=3, Max=5 and there is an Alarm set on an AutoScalingPolicy which says if CPU usage is <50% for consecutive 10 mins then Remove 1 instances then it will keep reducing the instance count by 1 whenever the alarm is triggered until the DesiredCount = MinCount.

Lessons Learnt: Set the MinCount to be > 0 or = DesiredCount. This will make sure that the application is not brought down when the mincount=0 and CPU usage goes down.

In layman's terms, DesiredCapacity value is automatically updated on scale-in and scale-out events.

In other words,

Scale-in or Scale-out are done by decreasing or increasing the DesiredCapacity value.

Desired capacity simply means the number of instances that will come up / fired up when you launch the autoscaling. That means if desired capacity = 4, then 4 instances will keep on running until and unless any scale up or scale down event triggers. If scale up event occurs, the number of instances will go up till maximum capacity and if scale down event occurs it will go down till the minimum capacity.

Correct me if wrong, thanks.

"Desired" is (necessarily) ambiguous.

  • It means the "initial" number of instances. Why not just "initial" then? Because the number may change by autoscaling events.
  • So it means "current" number of instance. Why not just "current" then? Because during an autoscaling event, instances will start / terminate. Those instances do not count towards "current" number of instances. By "current", a user expects instances that are operate-able.
  • So it means "target" number of instance. Why not just "target" then? I guess "target" is just as good (ambiguous) as "desired"...

I noticed that desired capacity went down and no new instance came up when

  1. I set one of the instances to standby. It kept on running but was detached from ELB ( requests were not forwarded to that particular instance when accessed via ELB DNS ). No new instance has been initiated by AWS. Rather desired capacity was decreased by 1.
  2. When I changed the state of instance ( from standby ) the instance was again attached to ELB ( the instance started to get requests when accessed via ELB DNS ). The desired capacity was increased by 1 and became 2.

Hence it seems no of instances attached to ELB can't cross the threshold limit set by min and max but the desired capacity is adjusted or changed automatically based on the occurrence of scale in or scale out event. It was definitely something unknown to me.

It might be a way to let AWS know that this is the desired capacity required for the respective ELB at a given point in time.

Min and max is self explanatory but desired was confusing until i have attached Target Tracking Auto scaling policy with the ASG where CPU utilization was the target metric. Here, desired instances were scaled out and scaled in based on target CPU utilization. If any desired count are placed through cloudformation/manual, for time being ASG will create same number of instances as desired count. But later ASG policy will automatically adjust the desire instances based on target CPU utilization.

Desired is what we start initially. It will go to min or max depending on the scale-in / scale-out.

I liked the analogy with a slider to understand this - https://stackoverflow.com/a/36272945/10779109

Think of min and max as the maximum allowed brightness on a screen. You probably don't want to min to be 0 in that case (sidenote). The desired quantity keeps changing based on the env (in the case of ASG, it depends on the scaling policies).

For instance, if the following check runs every hour, this is where desired quantity is required.

if low_load(<CPU or Mem etc>) and desired_capacity>= min_capacity:
desired_capacity = desired_capacity-1

Max capacity can also be understood in the same way where you'd want to keep increasing the desired quantity based on a cloudwatch_alarm (or any scaling policy) up to the max capacity.