AWS 网络 ELB 需要 4 分钟才能将目标识别为健康

Question

使用 AWS 网络 ELB：注册实例至少需要四分钟才能变得“健康”。实例和服务已经运行了好几天，我只是取消注册，然后在同一个目标组上注册，作为部署的一部分。如果我使用脚本或使用 AWS UI，CLI 没有区别。

健康检查设置是：

• 端口：尝试了各种，都通过 curl 测试了监听服务。 80,22,9001
• 健康阈值：2
• 不健康阈值：2
• 超时：10
• 间隔：30

我可以看到在任何指定的端口上都有连接请求，服务会做出适当的响应，然后连接会关闭。据我所知，这应该足以让 ELB 确定实例是否健康（一旦超过阈值）。这应该意味着我的实例在注册时间后不超过 90 秒内启动并运行。我不知道为什么会发生这种情况，应该直截了当。

鉴于我已满足我的实例健康的已知标准，我无法确定是什么导致了如此长时间的延迟。他们坐在Elb.InitialHealthChecking 原因大约 4 分钟。关于进一步测试以确定延迟原因的任何想法？

Answer 1

我们通过 NLB 解决了这个问题，并于 2018 年 3 月 20 日通过 AWS 支持提出了这个问题。他们的回应：

这是一个已知问题，新注册的实例会在较长时间内保持初始状态，而我们的内部团队已经在努力解决此问题。不幸的是，目前我们没有修复的预计到达时间。

他们确认，在正常情况下，目标应保持在 initial 状态，直到 HealthyThreshold 健康检查通过。

Answer 2

我可以确认这在 2021 年 9 月之前不起作用。我以为我做错了什么，但是，一切正常，4-5 分钟后处理到healthy status。 :|

Answer 3

这接近于 NLB 的预期行为。

是的，当您向网络负载均衡器注册新目标时，预计需要 90 到 180 秒才能完成注册过程。注册完成后，网络负载均衡器的运行状况检查系统将开始向目标发送健康检查。新注册的目标必须在配置的时间间隔内通过健康检查才能进入服务并接收流量。例如，如果您将运行状况检查的间隔配置为 30 秒，并且需要 3 次运行状况检查才能正常运行，则新注册的目标可以进入服务的最短时间是新目标通过第一次运行状况检查后的 90 秒。

同样，当您从网络负载均衡器取消注册目标时，预计需要 90-180 秒来处理请求的取消注册，之后它将不再接收新连接。在此期间，Elastic Load Balancing API 将报告目标处于“耗尽”状态。目标将继续接收新连接，直到取消注册处理完成。在配置的注销延迟结束时，目标将不会包含在目标组的 describe-target-health 响应中，并且在查询特定目标时将返回“未使用”，原因为“Target.NotRegistered”。

支持人员还确认没有正在进行的工作以使其速度超过 3 分钟。