amazon-web-services - AWS AutoScaling 'oldestinstance' 终止策略并不总是终止最旧的实例

Question

设想

我正在创建一个脚本，它将新实例启动到 AutoScaling 组中，然后删除旧实例。目的是将新创建(或更新)的 AMI 引入 AutoScaling 组。这是通过增加 Desired 来实现的。容量是当前实例数的两倍。然后，在新实例之后是 Running , 减少 Desired容量相同的数字。

问题

当我运行脚本时，我看到组容量增加了一倍，新实例上线，它们达到 Running状态，然后减少组容量。奇迹般有效。问题是有时因减少而终止的实例实际上是新实例而不是旧实例。

问题

如何确保 AutoScaling 组将始终终止最旧的实例？

设置

AutoScaling 组具有以下 Termination Polices :OldestInstance，OldestLaunchConfiguration。 Default政策已被删除。

Default Cooldown设置为 0 秒。

集团只有一个可用区。

故障排除

我玩弄了Cooldown环境。最后只是把它放在0上。

我等待了不同长度的时间，以查看现有服务器是否需要运行一定时间才能终止。似乎如果它们不到 5 分钟，它们就不太可能被终止，但并非总是如此。我有 20 分钟前没有终止的服务器，而不是新的服务器。也许新启动的实例有一些终止保护宽限期？

让步

我知道在大多数情况下，我要更换的服务器已经运行了很长时间。在生产中，这可能不是问题。尽管如此，在 AutoScaling 的正常过程中，旧服务器可能会继续运行，而不是新服务器。这不是可接受的操作方式。

我可以强制终止特定实例，但这会破坏 OldestInstance 的要点。终止政策。

更新 : 2014 年 2 月 12 日
我继续在生产中看到这一点。已运行数周且具有较旧启动配置的实例将继续运行，而较新的实例将被终止。在这一点上，我认为这是一个错误。一个 thread at Amazon几年前为这个话题打开了，显然没有解决方案。

更新 : 2014 年 2 月 21 日
我一直在与 AWS 支持人员合作，此时他们已经初步确认这可能是一个错误。他们正在研究这个问题。

Answer 1

确切地说，您似乎做不到，因为除了运行正确数量的实例之外，自动扩展还试图为您做另一件事:保持您的实例计数在可用区之间保持平衡......并且它优先考虑这一点考虑高于您的终止政策。

Before Auto Scaling selects an instance to terminate, it first identifies the Availability Zone that has more instances than the other Availability Zones used by the group. If all Availability Zones have the same number of instances, it identifies a random Availability Zone. Within the identified Availability Zone, Auto Scaling uses the termination policy to select the instance for termination.

— http://docs.aws.amazon.com/AutoScaling/latest/DeveloperGuide/us-termination-policy.html

如果您失去平衡，那么保持平衡可以说是最明智的策略，尤其是在您使用 ELB 时。 documentation有点模棱两可，但 ELB 会在 DNS 中为配置它的每个可用区通告一个公共(public) IP；这三个IP地址将通过轮询DNS实现第一层负载均衡。如果启用 ELB 的所有可用区都有健康的实例，那么流量命中的外部 IP 与 ELB 将向哪个可用区的服务器提供流量之间似乎存在 1:1 的相关性——至少如此是我的服务器日志显示的。似乎 ELB 不会跨可用区域将流量路由到备用服务器，除非给定区域中的所有服务器都被检测为不健康，这可能是他们以这种方式实现自动缩放的理由之一。
尽管此算法可能并不总是在区域范围内首先杀死最旧的实例，但如果它确实按照记录的方式运行，它会杀死所选可用区域中最旧的实例，并且在某些时候它应该最终循环遍历所有它们在负载的几个变化过程中......所以它也不会让最旧的运行无限期。组中的实例数量越多，这种影响似乎就越不显着。