我正在创建一个脚本,将新实例启动到AutoScaling组,然后删除旧实例。目的是将新创建的(或更新的)AMI引入AutoScaling组。这是通过将Desired
容量增加目前实例数的两倍来实现的。然后,在新实例Running
之后,将Desired
容量减少相同的数量。
当我运行脚本时,我会看到组容量增加一倍,新实例联机,它们达到Running
状态,然后组容量减少。奇迹般有效。问题是SOMETIMES由减少终止的实例实际上是新的实例而不是旧实例。
如何确保AutoScaling组始终终止最旧的实例?
Termination Polices
:OldestInstance,OldestLaunchConfiguration。 Default
政策已被删除。Default Cooldown
设置为0秒。Cooldown
设置。结束只是把它放在0。我知道在大多数情况下,我将要更换的服务器已经运行了很长时间。在生产中,这可能不是问题。仍然有可能在AutoScaling的正常过程中,旧服务器将保持运行而不是更新的服务器。这不是一种可接受的操作方式。
我可以强制终止特定实例,但这会违反OldestInstance
终止政策的要点。
更新:2014年2月12日 我继续在生产中看到这一点。已运行数周的较旧启动配置的实例将保持运行,而较新的实例将被终止。在这一点上,我认为这是一个错误。几年前为这个主题打开了thread at Amazon,显然没有解决方案。
更新:2014年2月21日 我一直在与AWS支持人员合作,此时他们已初步确认这可能是一个错误。他们正在研究这个问题。
答案 0 :(得分:3)
它看起来并不像你能做到的,因为除了正确运行实例数之外,自动扩展还试图为你做另外一件事:保持你的实例计数在可用区间保持平衡......和它将此考虑优先于您的终止政策。
在Auto Scaling选择要终止的实例之前,它首先标识的可用区域的实例数多于该组使用的其他可用区域。如果所有可用区具有相同数量的实例,则它标识随机可用区。在标识的可用区内,Auto Scaling使用终止策略选择要终止的实例。
- http://docs.aws.amazon.com/AutoScaling/latest/DeveloperGuide/us-termination-policy.html
如果你失去平衡,那么保持平衡可以说是最明智的策略,特别是如果你使用的是ELB。 documentation有点含糊不清,但ELB会在DNS中为每个配置它的可用区域公布一个公共IP;这三个IP地址将通过循环DNS实现第一层负载均衡。如果启用ELB的所有可用区域都具有健康的实例,那么流量点击的外部IP与ELB将提供流量的可用区域服务器之间似乎存在1:1的相关性 - 至少是我的服务器日志显示的。它出现 ELB不会将可用区域之间的流量路由到备用服务器,除非给定区域中的所有服务器都被检测为不健康,这可能是他们实施原因的理由之一以这种方式自动缩放。
虽然这个算法可能并不总是在区域范围内首先杀死最旧的实例,但如果它确实按照文档记录运行,它会杀死所选可用区域中最旧的实例,并且在某些时候它应该最终循环通过他们所有这些在负载的几个班次的过程...所以它不会无限期地离开最老的运行。该组中的实例数量越大,这种效应似乎就越不显着。
答案 1 :(得分:0)
还有其他几种方法可以做到:
或者:
最终回滚部署:
或者使用新的ASG API,您可以从ASG附加/分离实例:
您可能想要使用旧ASG的原因是因为再次设置所有策略(即使自动化)也可能是一个小问题,并且尽可能少地更改会感觉更安全。
一个。
答案 2 :(得分:0)
我的用例是我们需要缩小规模并能够选择哪些机器停机。不幸的是终止政策" OldestFirst"我们也没有为我们工作。我能够使用ambakshi共享的附加/分离方法的变体来删除最旧的(或我选择的任何实例),同时降低自动缩放组的所需实例值。
步骤1 - 将自动缩放组最小值更改为您要缩小到的数字。
第2步 - 暂停ASG
步骤3 - 分离要终止的实例,可以在一个命令中执行多个实例。确保使用should-decrement-desired-capacity标志
第4步 - 恢复ASG
步骤5 - 使用控制台或CLI终止您的实例
<强>更新强>
没有必要暂停Auto Scaling组,只需执行步骤1,3和5就可以了。请注意可能发生的任何可用区域平衡。