【问题标题】:AWS autoscale ELB status checks grace periodAWS 自动缩放 ELB 状态检查宽限期
【发布时间】:2015-02-04 00:32:49
【问题描述】:

我在 AWS 自动缩放组中运行服务器。正在运行的服务器位于负载均衡器后面。我正在使用 ELB 来管理 Auto Scaling 组的健康检查。当服务器启动并加入自动缩放组时,它们当前会立即加入负载均衡器。

我需要等待多长时间(即运行状况检查宽限期)才能让他们加入负载均衡器?

是否应该在服务器处于运行状态后才可以?

应该是服务器通过系统和实例状态检查后才可以吗?

【问题讨论】:

    标签: amazon-web-services load-balancing autoscaling amazon-elb


    【解决方案1】:

    Auto Scaling 组有两种可用的运行状况检查:

    • EC2 健康检查: 这使用EC2 status check 来确定实例是否健康。它仅在管理程序级别运行,无法查看在实例上运行的应用程序的运行状况。
    • 弹性负载均衡器 (ELB) 运行状况检查: 这会导致 Auto Scaling 组将运行状况检查委托给能够检查特定 HTTP(S) URL 的弹性负载均衡器。这意味着它可以检查应用程序是否在实例上正确运行。

    鉴于您的系统正在使用 ELB 运行状况检查,Auto Scaling 在确定每个 EC2 实例的运行状况时会信任 ELB 运行状况检查的结果。这可能有点危险,因为如果实例需要一段时间才能启动,运行状况检查可能会错误地将实例标记为不健康。这反过来又会导致 Auto Scaling 终止实例并启动替换。

    为避免这种情况,Auto Scaling 组配置中有一个运行状况检查宽限期设置(以秒为单位)。这表示 Auto Scaling 应该等待多长时间才能开始使用 ELB 运行状况检查(反过来,它具有检查频率以及将实例标记为正常/不正常需要多少次检查的设置)。

    因此,如果您的应用程序需要 3 分钟才能启动,请将运行状况检查宽限期设置为至少 180 秒(3 分钟)。文档没有说明计时是从实例标记为“正在运行”的那一刻开始,还是从状态检查完成时开始,因此执行一些计时测试以避免任何“反弹”情况.

    事实上,我建议将运行状况检查宽限期设置为显着更高的值(例如,所需时间的两倍)。这不会影响您系统的运行,因为只要满足 ELB 健康检查,健康的实例就会开始服务流量,这比 Auto Scaling 宽限期要早。最坏的情况是几分钟后会终止一个真正不健康的实例,但这应该很少发生。

    【讨论】:

    • @kintuparantu 应用程序负载均衡器运行状况检查已在目标组上配置。请参阅:Health Checks for Your Target Groups 如果您有任何其他问题,请开始一个新问题,而不是通过对旧问题的评论来提问。
    【解决方案2】:

    documentation(现在)声明“宽限期在实例通过 EC2 系统状态检查和实例状态检查后开始。”

    因此,至少根据 2015 年中的 AWS 文档,答案是“在服务器通过系统和实例状态检查之后”。这就是我们设置环境的方式,虽然我没有做精确的时间安排,但它似乎是正确的。

    【讨论】:

      【解决方案3】:
      1. 如果您密切监控您的 cloudformation 堆栈事件,您将获得成功信号,表明您的 ASG 已更新。
      2. ASG 开始更新和 ASG 收到成功信号之间的时间差是健康检查宽限期。
      3. 始终建议将此运行状况检查宽限期设置为应用程序启动时间的两倍。假设您的应用程序需要 10 分钟才能启动,您应该将运行状况检查宽限期设置为 20 分钟。
      4. 原因是您永远不知道您的应用程序可能会抛出某种错误并进行多次重试。

      【讨论】:

        猜你喜欢
        • 2016-12-20
        • 2019-03-17
        • 1970-01-01
        • 2021-08-22
        • 2019-04-25
        • 2019-08-21
        • 2017-12-15
        • 2014-05-06
        • 2022-11-24
        相关资源
        最近更新 更多