为什么没有水平可扩展的软件负载平衡器平衡 ssl 的例子？

Question

我有一堆关于 ssl、本地会话和负载平衡的问题，它们似乎是相互关联的，所以我提前为这个问题的长度道歉。

我有一个使用基于文件的会话的网站。该站点的性质是大部分是http，但有些部分是ssl。目前，由于基于文件的会话，任何 ssl 请求都需要与以前的任何 http 请求访问相同的服务器。

由于时间限制，我想做最简单的事情来负载平衡增加的 http 和 ssl 流量。

粘性负载平衡算法似乎有两种选择：

• 基于IP
• 基于cookie

基于 ip 的解决方案可能会起作用，但散列算法可能会在服务器关闭或添加时更改用户访问的服务器，这对于当前基于文件的会话设置是不合需要的。我还假设用户在浏览网站时合法地更改 ip 在技术上是可能的。

基于 cookie 的算法似乎更好，但是在通过 ssl 加密时无法检查 cookie 似乎存在其自身的问题。

我一直在搜索有关如何对 ssl 进行负载平衡的示例，但似乎找不到任何明确的设置示例，这些示例可以执行基于 cookie 的负载平衡，并且可以通过添加另一个 ssl 解码器来处理增加的 ssl 负载。

我见过的大多数显式示例都有位于浏览器客户端和负载均衡器之间的 ssl 解码器（通常是硬件、apache_mod_ssl 或 nginx）。这些示例通常看起来像这样（从http://haproxy.1wt.eu/download/1.3/doc/architecture.txt修改）：

      192.168.1.1 192.168.1.11-192.168.1.14
 -------+-----------+-----+-----+-----+
        | | | | |       
     +--+--+ +-+-+ +-+-+ +-+-+ +-+-+    
     | LB1 | | 一个 | | 乙 | | C | | D |    
     +-----+ +---+ +---+ +---+ +---+    
     apache 4 便宜的网络服务器
     mod_ssl
     代理 

上面例子中的 ssl 解码部分似乎是一个潜在的瓶颈，无法横向扩展。

我看过 haproxy，它似乎有一个“mode tcp”选项，可以允许这样的事情，这将允许您拥有多个 ssl 解码器：

              代理
                 |
            -------------
            | |
ssl-decoder-1 ssl-decoder2
            | |
        -------------------
        | | |  
      网络1 网络2 网络3

但是，在这样的设置中，您似乎会丢失客户端 IP，因为 haproxy 没有解码 ssl：https ://cloud-support.engineyard.com/discussions/problems/335-haproxy-not-passing-x-forwarded -为了

我也看过 nginx，我也没有看到任何水平可扩展的 ssl 解码器的明确示例。似乎有很多人将 nginx 作为潜在瓶颈的例子。至少这个链接似乎表明 nginx 甚至没有类似 haproxy 的设置的选项，你会说 nginx“不支持透明地将 TCP 连接传递到后端”如何通过 Apache SSL 流量通过 nginx 代理？.

问题：

• 为什么似乎没有更多设置示例添加更多 ssl 解码器来处理增加的流量？
• 是不是因为ssl解码步骤只是理论上的瓶颈，实际上除了流量荒谬的网站，一个解码器基本上就足够了？
• 想到的另一种可能的解决方案是，任何对 ssl 需求增加的人也有一个集中的会话存储，因此客户端在顺序请求上点击哪个 Web 服务器并不重要。然后您可以在每个网络服务器上启用 mod_ssl 或等效项。
• 上面引用的 haproxy 解决方案似乎有效（除了客户端 IP 问题），但是有没有人遇到过基于粘性 cookie 的软件负载平衡器解决方案，该解决方案可以通过增加解码器的数量同时保持客户端 IP 来工作，或者在技术上可能不是可能（因为您必须对请求进行解码才能获取客户端 IP，在这种情况下，我们会遇到解码器瓶颈）。

假设我所说的一切都是真的，这些似乎是我的选择：

• 使用 ip 散列（对可能合法更改 ip 的用户以及服务器添加和删除场景不利）
• 使用 nginx 或 mod_ssl 作为第一个接触 ssl 请求的程序，这将是潜在的 ssl 解码瓶颈
• 使用 haproxy 作为第一个处理 ssl 请求的程序，获得水平 ssl 可扩展性，但没有在 web 服务器级别为 ssl 请求记录 ips（可能暂时没问题）
• 从长远来看，转向移动或集中式会话存储，使粘性会话变得不必要

Answer 1

严肃地说，“最简单的事情”是转移到集中式会话存储。你必须用负载平衡器、haproxy、SSL 和其他东西来设置所有这些管道，当我见过的每一位会话处理代码都使得插入不同的存储引擎变得几乎是微不足道的时候，所以一个一些代码和非常非常少的额外复杂性可以解决您的所有问题。

Answer 2

womble 是正确的，共享会话存储使周围的事情变得更加容易。除了他的回答之外，我还可以扩展一下问题的负载平衡部分：

为什么似乎没有更多设置示例添加更多 ssl 解码器来处理增加的流量？

现代多核 PC每秒可以执行数千次SSL 事务。如果这成为瓶颈，那么来自F5、Citrix、Cisco 或类似公司的专用设备可能会更快。所以大多数站点永远不会超过一个好的单设备 SSL 和负载平衡解决方案。

假设我所说的一切都是真的，这些似乎是我的选择：

如果您需要，可以选择水平扩展 SSL 解密。

常见的做法是使用DNS Round Robin来实现高可用的SSL加速器对，即为域发布多个IP地址，每个IP地址指向一对SSL加速器。

在这种情况下，您可能会担心 DNS TTL 在用户会话中间超时，从而将用户撞到另一个应用程序服务器。这不应该是一种普遍现象，但它可能会发生。共享会话存储是常见的解决方案，但可以通过其他方式进行处理。

作为一个示例，您可以将 SSL 解密与应用程序服务器平衡分开。SSL 处理比基本负载平衡更占用 CPU，因此单个负载平衡器应该能够使几个 SSL 加速器饱和。像这样：

Internet --> DNS round robin to multiple SSL accelerators --> plain HTTP to a single HTTP load balancer --> plain HTTP to multiple application servers

正如开头提到的，共享会话存储简化了很多事情，并且几乎可以肯定是比将大量复杂性放入 SSL/负载平衡层更好的长期解决方案。