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

Sun*_*arc 5 amazon-web-services autoscaling

脚本

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

问题

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

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

设置

  • AutoScaling组具有以下内容Termination Polices:OldestInstance,OldestLaunchConfiguration.该Default政策已被删除.
  • Default Cooldown被设置为0秒.
  • 该集团只有一个可用区.

故障排除

  • 我玩这个Cooldown设置.结束只是把它放在0.
  • 我等待不同的时间来查看现有服务器是否需要在终止之前运行一段时间.似乎如果它们不到5分钟,它们就不太可能被终止,但并非总是如此.我有20分钟的服务器没有被终止而不是新服务器.也许新推出的实例有一些终止保护宽限期?

让步

我知道在大多数情况下,我将要更换的服务器将运行很长时间.在生产中,这可能不是问题.仍然有可能在AutoScaling的正常过程中,旧服务器将保持运行而不是更新的服务器.这不是一种可接受的操作方式.

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

更新:2014年2月12日我继续在生产中看到这一点.已运行数周的旧启动配置的实例将保持运行,而较新的实例将被终止.在这一点上,我认为这是一个错误.亚马逊的一个主题在几年前为这个主题开放了,显然没有解决方案.

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

Mic*_*bot 3

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

\n
\n

在 Auto Scaling 选择要终止的实例之前,它首先会识别比该组使用的其他可用区拥有更多实例的可用区。如果所有可用区的实例数量相同,则随机识别一个可用区。在确定的可用区内,Auto Scaling 使用终止策略来选择要终止的实例。

\n

\xe2\x80\x94 http://docs.aws.amazon.com/AutoScaling/latest/DeveloperGuide/us-termination-policy.html

\n
\n

如果您失去平衡,那么保持平衡可以说是最明智的策略,尤其是在您使用 ELB 的情况下。文档有点含糊,但 ELB 会在 DNS 中为配置它的每个可用区域通告一个公共 IP 这三个IP地址将借助循环DNS实现第一层负载均衡。如果启用 ELB 的所有可用区都有运行状况良好的实例,那么流量到达的外部 IP 与 ELB 将流量提供给哪个可用区的服务器之间似乎存在 1:1 的相关性 --至少我的服务器日志是这样显示的。看来ELB 不会跨可用区域将流量路由到备用服务器,除非给定区域中的所有服务器都被检测为不健康,这可能是他们以这种方式实现自动缩放的理由之一

\n

尽管此算法可能并不总是在区域范围内首先杀死最旧的实例,但如果它确实按照记录运行,它将杀死所选可用区域中最旧的实例,并且在某个时刻它应该最终循环遍历所有可用区域它们在负载的几次变化过程中......所以它也不会让最旧的无限期运行。组中的实例数量越多,这种影响似乎就越不显着。

\n