我正在尝试了解缩放策略和所需实例如何相互配合。
建议我遇到以下情况。
- 最小值:0
- 最多:4
- 所需实例数: 2
缩放策略:
- 横向扩展:当 CPU avg > 60%
- 缩减:当 CPU avg < 20%
初始状态:2 个实例已启动。
第一步:
将两个实例的 CPU 提高到平均 90%。
第二步发生:
Auto Scaling 将实例数增加到 3。
第三步:
将机器的平均 CPU 保持在 40% 左右，这样就不会触发横向扩展或缩减。
第四步:
现在我们有三个实例，没有横向扩展或横向扩展触发器，但所需的实例是两个。什么规则应该“赢”？
所需实例 2(将删除一个实例)？
或者扩展策略(什么都不应该改变，保持 3 个实例正常运行)？
最佳答案
Auto Scaling 将始终尝试为您提供所需容量 指示的实例数。
例如，当使用 Desired Capacity = 2 启动 Auto Scaling 组时，Auto Scaling 将启动 2 个实例。将 Desired Capacity 更改为 3 将导致 Auto Scaling 启动 1 个额外的实例(总数 = 3)。
扩展策略告诉自动扩展更改所需容量。
例如，由 CPU 超过给定阈值触发的 Amazon CloudWatch 警报可以配置为触发扩展策略。可以使用添加 1 个实例 规则配置扩展策略，这将导致 Desired Capacity 增加 1。(注意:Desired Capacity 将始终保持在 Min 和 Max 的边界内，因此扩展策略实际上可能不会改变 Desired Capacity。)
在您的示例中，第 1 步触发了 CloudWatch 警报，该警报执行了将 Desired Capacity 从 2 增加到 3 的扩展策略。没有“获胜”的竞争规则。
Scaling adjustment types可以是:ChangeInCapacity、ExactCapacity 和 PercentChangeInCapacity。
关于amazon-web-services - 所需实例 VS。缩放策略，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/38694203/