没有来自ELB的流量到其中一个Auto Scaling实例

Question

我们使用Auto Scaling,它对我们来说非常有用,但今天早上发生了一些事情.由于某些原因,其中一个实例的CPU利用率约为%0,这使得100%的CPU利用率被带到同一可用区中的其余实例,并且没有扩展,因为所有实例的平均CPU利用率约为%70触发器应该在%80被命中时启动新实例.ELB实例运行状况检查也被使用,但是这个%0实例是健康的.

是否可以配置Auto Scaling来删除此类实例？我们不想为检查设置任何自定义cronjobs.

Answer 1

更新2

是否可以配置Auto Scaling来删除此类实例？

是的,请参阅下文 - 根据您的评论,您已经正确地完成了这项工作.

我们不想为检查设置任何自定义cronjobs.

鉴于您的配置显然是正确的(暗示Auto Scaling和/或ELB 各自存在问题),我担心通过主动关闭未使用的实例或促进as-set-instance-health无法避免自定义解决方案,正如我在下面的初步答案中已经提出的那样 - 前者是由tribalcrossing对ELB- Unhealthy 实例的回答建议OOS然后自动从ELB中删除,这似乎解决了你的情况:

我们运行一个每5分钟触发一次的cronjob来扫描一个ELB中的所有服务器,检查它是否已超过5分钟且不健康.当我们找到一个时,我们将其关闭.我们已经在ELB中遇到了"死"实例的问题,并抛弃了触发自动缩放操作的监控指标,而cronjob已经为我们解决了这个问题.

更新1

ELB实例运行状况检查也被使用,但是这个%0实例是健康的.

您指的是哪个健康指标？您是如何依次得出健康状况的结论？

重要的是要意识到,Autoscaling和ELB以不同方式测量健康实例,请参阅alighafour对Autoscaling的响应,不对不健康的实例做出反应:

ELB在应用层检查,同时在机器层进行自动缩放检查.

这个差异在AWS团队对链接问题的响应中进一步详细说明了ELB-Unhealthy实例,然后OOS自动从ELB中删除(实际上解决了反向问题):

Autoscaling正在查看实例运行状况 - 如果数据显示实例不健康,它们将关闭实例.他们当时会将它从ELB中取出然后关闭实例.

另一方面,ELB通过读取文件或连接到端口来执行应用程序运行状况检查.如果应用程序未通过一定数量的这些检查,则实例将继续运行,但ELB不会向其发送任何新流量.ELB继续执行运行状况检查 - 如果应用程序实例再次变得健康,它将开始将流量路由到它.ELB不会从ELB注册中删除实例 - 它只是停止发送流量,直到它再次健康.[强调我的]

结论

看起来上述场景可能确实适用于您的体验:ELB停止向您的实例发送流量,因为ELB运行状况检查失败,而Auto Scaling运行状况检查未发现实例的问题 ; 例如,如果ELB运行状况检查探测Apache服务的网页,可能会发生这种情况,该网页无论出于何种原因都无法响应(例如,Apache崩溃或其他情况).

解

您需要配置Auto Scaling策略,以根据EC2运行状况和 ELB运行状况两者的健康状况做出决策,如维护当前扩展级别内的为Elastic Load Balancing创建 运行状况检查一节中所述:

默认情况下,Auto Scaling对所有Auto-Scaling管理的实例使用Amazon EC2运行状况.要同时使用Elastic Load Balancer的运行状况检查,请将组的HealthCheckType属性设置为ELB:

% as-update-autoscaling-group myGroup –-health-check-type ELB

有了这种配置,只要ELB运行状况检查失败,实例就会被认为是不健康的,并且它将被相应地替换.

初步答复

是否可以为一个Auto Scaling组提供多个触发器？

不幸的是,请参阅AWS团队对如何在模板中设置多个触发器的响应:

遗憾的是,Auto Scaling服务仅允许每个Auto Scaling组使用1个触发器,因此我们目前不支持在模板中为同一组启用多个触发器.

另一种方法可以实现通过定制解决方案的设定,例如健康,在一节中提到的自定义健康检查中保持当前的缩放比例级别:

如果您有自己的运行状况检查系统,则可以将其与Auto Scaling集成.使用SetInstanceHealth将实例的运行状况信息直接从系统发送到Auto Scaling.