背景:我的Java 7 Elastic Beanstalk应用程序运行正常。它通常只使用一个实例,但如果CPU负载达到70%则会激活另一个实例,如果低于20%则关闭它,最多允许的实例数为2。可以有相当多的使用范围,因此从一开始就有经济意义,在需要时最多可以达到两个。唯一的问题是,在部署时,它必须从S3下载5GB索引文件并解压缩,这意味着总部署时间为30分钟。 但我认为AWS知道应用程序仍在部署,并且在正确部署之前不会开始向其发送请求,我已配置以下ebextension
option_settings:
- namespace: aws:elasticbeanstalk:command
option_name: Timeout
value: 1800
最近我部署了一个新版本的应用程序,我注意到AWS有一个新的运行状况检查监视器来监视HttpCodes。我认为当新的应用程序实例仍在部署并导致
时,它会返回错误实例至少连续失败了健康检查的不健康阈值数。
所以我的服务器出现故障,但我不确定,HealthCheck是否会导致问题,我该如何检查?
目前的解决方法是部署到更快的实例,但这意味着我现在正在为我不需要的容量付费,因此长期来说这不是一个经济上可行的解决方案。
答案 0 :(得分:0)
新的AWS Elastic Beanstalk运行状况检查正式称为"增强型"运行状况检查从各种来源收集数据,并为您提供运行状况和颜色以及为环境和所有实例分配的运行状况的原因。这些来源包括来自EC2实例的数据,ELB健康检查,ELB的云观察指标,SQS等。
如果您看到"实例已连续至少失败了健康检查的不健康阈值数。"在原因中,这意味着实例未通过负载均衡器运行状况检查。来自ELB的此消息的可能原因记录在here。为了澄清,如果负载均衡器运行状况检查失败,ELB将不会向您的实例发送流量。无论您是否使用增强型运行状况报告系统,这都是负载均衡器的行为。增强的健康状况只是将ELB中的信息显示在beanstalk健康原因/事件中。 如果您的环境中有一个实例,并且部署需要30分钟,那么在部署期间,您的环境可能无法为任何流量提供服务。
您能为负载均衡器提供运行状况检查配置吗?您可以在beanstalk配置页面的负载平衡面板中找到运行状况检查,如here所示。
如果您的应用程序中有可靠的运行状况检查URL,要通知ELB您的实例已准备好提供流量,那么您应该使用它来进行运行状况检查而不是默认的TCP:80检查。 您还可以通过查看AWS管理控制台上的“运行状况”窗格来查看实例是否在部署期间接收流量。
但重申一下,如果您只有一个实例并且部署需要很长时间,那么在此期间您的环境将无法用于客户流量。对某些用例来说可能没问题。如果没有,则建议您使用至少2个实例和滚动部署(基于运行状况或基于时间)批量大小<实例数。
即使你有一个更快的实例需要花费5分钟从S3下载大文件并进行处理,那么对于那些5分钟,如果你的负载均衡器的运行状况检查是,你的实例将无法为客户流量提供服务。没有通过。
下载5 GB文件是运行应用程序的先决条件吗?您是否有必要将此文件作为应用程序部署的一部分下载,或者也可以将其作为应用程序中后台线程的一部分来执行?如果在更新期间下载文件并不重要,您可以进行非常快速的部署,并且您的实例可以立即为流量提供服务。
消息"实例至少连续失败了健康状况检查的UnhealthyThreshold数。"只是告诉你,ELB认为你的实例是不健康的(基于你的健康检查配置),因此没有收到任何流量。
当你说"所以我的服务器失败",你的意思是环境的健康状况是严重/红色的吗?如果是这种情况,那么在负载均衡器后面有一个实例并且部署时间超过30分钟就是肯定的,那么在部署期间,预计实例将不会像负载均衡器那样健康。再次,如果您认为您的实例甚至可以在部署完成之前提供流量(长轮询是从S3下载),那么您应该考虑将下载从S3移动到后台线程,以便您的应用程序在较短的时间内运行不健康停机时间最短。
如果您需要进一步澄清,请与我们联系。