当没有可用的后端服务器时,AWS TCP ELB 拒绝连接

AWS TCP ELB refuse connection when there is no available back-end server

我们有一个 TCP 应用程序以我们未设计且无法控制的协议接收连接。 该协议将假设如果它可以建立 TCP 连接,那么它可以发送消息并且该消息被确认。

如果直接连接到一台机器,这工作正常,如果机器或应用程序关闭,tcp 连接将被拒绝或断开,客户端将尝试重新传送消息。

当我们使用AWS弹性负载均衡器时,ELB会与客户端建立TCP连接,而不管是否有可用的后端服务器来完成请求。 因此,如果我们的应用程序或服务器崩溃,我们就会丢失消息。

ELB 会在不久后关闭 TCP 连接,但还不够好。

有没有办法让ELB只有能到达后端服务器才建立连接? 我们有什么选择(在 AWS 生态系统中)来平衡基于 TCP 的服务,同时在无法提供服务时仍然拒绝连接。

您可以从 ELB 创建健康检查以验证后端 EC2 实例是否在 TCP 端口上响应。参见 ELB Health Checks

然后,您监控 ELB 发送到 CloudWatch 的 EC2 实例的健康状态。

一旦您确定 none 个 EC2 实例正在 TCP 端口上响应,您可以从 ELB 中删除 TCP 侦听器。参见 Delete ELB Listeners

希望 ELB 停止接受 TCP 连接。

请注意,我尚未测试此解决方案。

我认为这无法通过 ELB 实现。按照设计,负载均衡器将管理 2 组连接(前端 - LB 和 LB - 后端)。负载均衡器将尝试最大限度地减少为接收到的流量提供服务所需的时间。这意味着 FE-LB 连接将在 LB 寻找要使用/重用的后端连接时建立。所有后端主机都死掉的情况是一种极端情况,您最终会看到您所看到的行为。通常这没什么大不了的,因为一旦 LB 发现它无法为流量提供服务,请求就会断开连接。

回到你的协议:对我来说,你将建立连接的能力解释为等同于消息传递似乎真的很奇怪。听起来您正在使用 TCP,但没有等待确认消息已在目的地实际收到。对我来说,这似乎是错误的,无论有没有负载均衡器,最终都会给你带来麻烦。

并且不要听起来太悲观(我明白我们不是生活在一个理想的世界)我在这种特定情况下会做的,如果你可以在客户端部署额外的软件,将是使用 tcp 代理在客户端上,只要负载均衡器 unhealthy/unable 服务于流量,它就会自动被禁用。指示客户端连接到此代理。远非理想,但应该可以解决问题。