ELB 是基于 draining tcp 的吗?

Is ELB draining tcp based?

我遇到了一个有趣的问题。我们 运行 基于状态的基于 HTTPS 的应用程序。状态是基于会话 cookie 维护的。该应用程序的设计方式是,如果会话突然终止,该应用程序将恢复到主屏幕,任何未保存的数据都会丢失。所以保持会话对我们来说非常重要。

过去某个时候决定为此目的使用 AWS 服务,当前架构有一个 ELB,可以将负载平衡到自动扩展组。使用的第一个架构启用了基于 HTTP 的粘性会话。在测试期间发现,当缩小现有会话时,会立即关闭并重新路由到可用实例。即使在启用耗尽(超时 5 分钟)之后也会发生这种情况,根据文档应该可以防止这种情况发生。有人能告诉我我们做错了什么吗?这就是它应该工作的方式吗?

我的第二个问题是,我们发现使用 ELB 来平衡基于 tcp 连接的负载时,情况并非如此。在这种情况下,当我们缩小旧的 tcp 连接时,它会一直保持到它关闭或超时,并且新连接会被路由到其他实例。这是我们正在使用的当前设置。所以我的问题是为什么 ELB 在这两种情况下的行为不同,有什么方法可以让 ELB 使用 HTTP 粘性会话并基于 tcp 连接耗尽?

如果您有答案,请分享配置详细信息。谢谢。

关于问题 #1 - 这是 ELB 连接耗尽的预期行为。

来自文档:"Connection draining causes the ELB load balancer to stop sending new requests to a deregistering instance or an unhealthy instance, while keeping the existing connections open. This allows the load balancer to complete in-flight requests made to the deregistering or unhealthy instances." http://docs.aws.amazon.com/ElasticLoadBalancing/latest/DeveloperGuide/TerminologyandKeyConcepts.html#conn-drain

ELB 不知道您的会话状态,因为这是由您的应用程序管理的。连接耗尽仅适用于网络级别。如果没有与您的实例的开放连接,ELB 可能会选择您的实例从 AutoScaling 中注销(Auto Scaling 稍后将终止它)

问题 #2:在负载均衡器上使用 TCP 模式时,它不会尝试理解 HTTP 内容(例如 cookie)并愉快地将从客户端接收到的任何内容发送到后端。您正在试验的行为可能与客户端浏览器管理连接的方式有关(即保持打开连接)。这必须使用网络开发工具进行验证。

对于您的用例,我会调查自动缩放生命周期事件,以在自动缩放对您的实例采取操作时触发您的一段代码。使用生命周期事件,您有机会在实例的关键生命周期状态触发自定义代码并采取其他操作或要求 Auto Scaling 放弃更改。

可在此处获取详细信息http://docs.aws.amazon.com/AutoScaling/latest/DeveloperGuide/AutoScalingGroupLifecycle.html http://docs.aws.amazon.com/AutoScaling/latest/DeveloperGuide/lifecycle-hook-considerations.html