为什么没有可水平扩展的软件负载均衡器来平衡SSL的示例？

关于ssl，本地会话和负载平衡，我有很多问题似乎相互关联，因此对于这个问题的长度，我事先表示歉意。

我有一个使用基于文件的会话的网站。该站点的性质是，大多数站点是http，但是某些部分是ssl。当前，由于基于文件的会话，任何ssl请求都必须与以前的http请求命中同一台服务器。

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

粘性负载平衡算法似乎有2个选择：

• 基于IP
• 基于cookie

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

基于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 | | A | | B | | C | | D |    
     + ----- + + --- + + --- + + --- + + --- +    
     apache 4廉价的网络服务器
     mod_ssl
     hapoxy 

上面示例中的ssl解码部分似乎是无法水平扩展的潜在瓶颈。

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

              hapoxy
                 |
            -------------
            | |
ssl-decoder-1 ssl-decoder2
            | |
        -------------------
        | | |  
      web1 web2 web3

但是，在这种设置中，由于haproxy不会解码ssl，因此您似乎会丢失客户端ip：https ://cloud-support.engineyard.com/discussions/problems/335-haproxy-not-passing-x-forwarded -对于

我也看过nginx，也没有看到任何水平可扩展ssl解码器的显式示例。似乎有许多人将nginx视为潜在瓶颈的例子。至少这个环节似乎表明，即使nginx的不具有的选项HAProxy的类似设置，你会被说，nginx的“不支持透明地经过TCP连接到后端”失去了IP 如何通过阿帕奇通过Nginx代理的SSL流量？。

问题：

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

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

• 使用ip哈希（对于可能合法更改ip的用户以及服务器添加和删除方案不利）
• 使用nginx或mod_ssl作为第一个处理ssl请求的程序，这将是潜在的ssl解码瓶颈
• 使用haproxy作为第一个处理ssl请求的程序，获得了水平的ssl可伸缩性，但是在ssl请求的网络服务器级别上没有记录任何ips（可能暂时正常）
• 从长远来看，请转向移动或集中式会话存储，从而无需进行粘性会话

总而言之，“最简单的事情”是转移到集中式会话存储。您必须使用负载均衡器，haproxy，SSL及其它其余部分来设置所有这些管道，当我所见过的每一个会话处理代码都使得插入不同的存储引擎变得几乎平凡时，因此少量的代码，几乎没有什么额外的复杂性可以解决您的所有问题。

对于共享会话存储，womble是正确的，这使周围的一切变得容易得多。除了他的答案，我还可以扩展问题的负载平衡部分：

为什么似乎没有更多设置增加更多ssl解码器以应对流量增加的设置示例？

现代的多核PC每秒可以完成数千个 SSL事务。而且，如果这成为瓶颈，那么来自F5，Citrix，Cisco等的专用设备甚至可以更快。因此，大多数站点永远都不会超越一个好的单设备SSL和负载平衡解决方案。

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

如果需要，可以使用一些选项来水平扩展SSL解密。

常用的方法是使用DNS循环访问高可用的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 /负载平衡层中相比，几乎可以肯定，这是一个更好的长期解决方案。

当产品不断发展时，回答像这样已有2年历史的问题很有趣。目前，haproxy支持PROXY协议，即使在纯TCP模式下，它也可以将客户端的IP传递到下一跳。如果您想将其用作SSL服务器场（可能是由haproxy服务器制成）前面的第一层，它还支持本机SSL以及SSL粘性。因此，您的请求似乎提前了一段时间，实现已经赶上了:-)

我在这里同意womble和Jesper的观点。最简单/最好的方法是修复代码。当然，作为系统管理员，我们通常没有这种选择，但是即使在那种情况下，您也可以使用足够的技巧来获得相对便宜的现代硬件，以达到足够的扩展规模，即使不是真正地水平。

我只是想发表评论，说明您担心失去客户端IP。在任何主要的L7 / proxy解决方案中，您都可以在请求中插入X-Forwarded-For（或任何您想要的）标题。然后，在接收请求的后端Web服务器上，您可以更改日志文件格式，以将该值记录在用于记录第3层客户端ip的文件的同一空间中。这样，任何日志解析软件都不会看到差异（拖尾时也不会）。

一切都需要权衡，我们对您的设置了解得还不够，但是有了ha-proxy，nginx和清漆这三个您不能出错的三重奏，移动负载平衡可能是一个好主意代理层工具。这将解决您的ssl问题，并为您提供许多新选项，例如缓存，内容切换和标头处理。

一些随意的想法;）

首先，射击决定使用基于文件的会话数据的人。从文件系统读取/写入数据绝对不可能比返回源以提取所需数据要快。这是关于最差的处理方法。

我个人从未见过这样的情况，即在会话中存储数据要比仅根据需要直接从数据库中提取数据要好。就是说，我已经知道在什么地方使用内存缓存或类似的缓存策略可以帮助网站扩展到数百万个用户，但是这与使用会话的优势不同。

其次，您刚刚发现根本不使用会话的第一个原因：负载平衡。仅供参考-粘性并不意味着卡住。即使打开了粘性会话，您也确实有可能在使用应用程序的过程中将用户改组到另一台服务器。这将在最不适当的时间发生。粘性只是意味着负载均衡器将尝试将用户推回其最初所在的服务器，但这绝不是保证。

这通常会导致人们将会话存储回数据库中……我认为这完全是失败的。为了使会话正常工作，必须在每个页面请求上加载和写入会话。当它存储在数据库中（负载平衡服务器必需）时，这需要两个服务器查询：第一个获取数据，第二个写入任何更新。

失败的部分是人们通常使用会话，因此他们不必回到数据库即可提取用户名之类的信息。但是如果页面必须查询数据库以加载会话，那么……您应该可以在这里看到逻辑问题。

会话只会使情况更糟...因为它们的页面处理器必须在页面生命周期结束时将会话数据写回到数据库中，以防万一发生任何更改。这意味着您将得到两个结果，而不是一个查询来提取该用户名。对于每个单页加载。此外，这意味着序列化和反序列化具有自身性能影响的数据。

我的观点是：会议是邪恶的，没有会议，您通常会更好。只运行在一台Web服务器上的低流量站点不需要提高性能。网络农场上运行的高流量站点因此受到限制。

除了可以在前面使用Haproxy之外，您还可以使用轮询DNS在多个SSL解码器之间进行粗略平衡，然后将其传递给haproxy以实现适当的负载平衡。