0

我们有一个运行 Apache 2.4 的遗留服务器集群，这些服务器运行我们的应用程序，位于 ELB 后面。此 ELB 有两个侦听器，一个 HTTP 和一个 HTTPS，它们在 ELB 处终止，并向其后面的实例发送常规 HTTP 流量。此 ELB 还关闭了预打开（它导致繁忙的工作人员堆积）。在正常负载下，每个实例有 1-3 个忙碌的工作人员。

我们有一个新的服务器集群，我们正试图迁移到一个新的 ELB 后面。此迁移的目的是允许 SNI – 为数千个域提供 TLS 流量。因此，此集群使用已在 ELB 级别启用的 mod_proxy_protocol。出于测试目的，我们一直在 DNS（Route 53）级别对流量进行加权，以将 30% 的流量发送到新的负载均衡器。即使在这么小的负载下，我们也会看到 5 到 10 个忙碌的工作人员，并且随着流量的增长而增长。

作为进一步的测试，我们采用了其中一个新实例，禁用了 proxy_protocol，并将其从新 ELB 移动到旧 ELB，工作人员数量下降到平均水平，即 1-3 个忙碌的工作人员。这似乎表明 ELB（HTTP 和 TCP 处理之间的差异？）或 mod_proxy_protocol 存在问题。

我的问题：为什么在使用代理协议和新的 ELB 时，我们有两倍繁忙的 apache 工作人员？我认为由于 TCP 侦听器是愚蠢的并且不对流量进行任何处理，因此它们会更快，因此比主动“修改”通过它们的流量的 HTTP 侦听器消耗更少的工作时间。

感谢任何帮助我们诊断此问题的指导。

4

1 回答 1

0

区别很简单但很重要：

HTTP 模式下的 ELB 负责保持来自浏览器的空闲保活连接，而不保持与实例的打开相应连接。浏览器连接和后端连接之间没有必要的关联——后端连接可以重复使用。

在 TCP 模式下，它是 1:1。必须如此，因为 ELB 不能为前端的不同浏览器连接重用后端连接——它没有解释管道中发生的事情。TCP 总是如此，但如果原因不直观，启用代理协议时应该特别明显。“PROXY标题”实际上并不是通常意义上的“标题”——它是序言。它只能在连接开始时发送，标识源地址和端口。连接一直持续到浏览器或服务器将其关闭或超时。这是 1:1。

这对于 Apache 不太可能是可行的。

回到 HTTP 模式，等待一分钟。

此 ELB 还关闭了预打开（它导致繁忙的工作人员堆积）。

我不知道你是怎么做到的——我从来没有见过它记录在案，所以我认为这一定是通过支持请求。

这似乎是一个完全解决错误问题的案例。与其拥有在您看来人为高的连接数量，您真正完成的只是将连接数量人为地保持在低水平——最终，您实际上可能会损害您的性能和扩展能力。这些备用连接的目的是处理突发需求。如果您的实例太小而无法处理它们，那么我建议真正的问题在于：您的实例太小。

另一种方法——这正是我用于可怕的基于 Apache 的应用程序的解决方案（其中一个有一个 Apache 服务器位于总共大约 15 到 20 个不同的 ELB 后面——这是必要的，因为每个 ELB 都使用一个由旧平台的一位客户提供的证书）——是 ELB 和 Apache 之间的 HAProxy。HAProxy 每天可以在微小的实例上处理数百个连接和数百万个请求（我说的是微小的 - t2.nano 和 t2.micro），并且它可以让所有 ELB 的连接保持活动状态但关闭每个请求后的 Apache 连接......所以它在两个方向上都在优化东西。

当然，您也可以将 HAProxy 与 TCP 平衡器和代理协议一起使用——HAProxy 的作者也是代理协议标准的创建者。您也可以只在带有 Apache 的实例上运行它，而不是在单独的实例上运行。它在内存和 CPU 方面是轻量级的，并且不会分叉。除了在 Lua 集成开发过程中偶尔提交错误报告外，我与该项目无关。

于 2017-02-01T02:21:18.877 回答