我正在尝试决定在我的数据中心使用第 4 层负载平衡解决方案还是第 7 层解决方案。不幸的是（为了我的理智），我的用例非常简单，两种解决方案都可以很好地工作，避免了大多数弱点，而没有真正利用对方的优势。无论我们最终使用哪种解决方案，它都必须具有高可用性和高吞吐量。但我们只计划使用它来在 Web 服务器集群上进行负载平衡，这些服务器都不需要“粘性”会话管理（cookie 或 IP）、复杂的重写规则 - 或者说，根本不需要任何重写规则。
负载平衡器将连接到两台交换机，两台交换机都具有独立连接到数据中心聚合层，并使用快速生成树和交换机用于虚拟化的任何专有协议合并在一起。负载平衡器还将通过交叉电缆相互交叉链接。集群中的所有服务器都连接到两台交换机。负载平衡器所要做的就是将流量指向它们。
由于它只是 HTTP，我可以使用第 7 层负载平衡解决方案，如 HAProxy 或 nginx。但我也可以将 LVS 项目与 ldirectord 或 keepalived 等结合使用。
我尝试分析我所看到的利弊，但最终却一无所获。您会推荐什么？为什么？我是否遗漏了什么？
答案1
类似 haproxy 的“L7”的一个实用好处是能够使用 cookie 来保持同一浏览器访问同一后端服务器。这使得调试客户端访问变得更加容易。
L4 平衡可能会使单个用户在多个后端服务器上反复跳转。（在某些情况下这可能是有利的，但从调试/分析的角度来看，使用“L7”更有价值。）
编辑：使用 HTTP 平衡还具有潜在的速度优势。使用保持活动，客户端可以与您的平衡器建立单个 TCP 会话，然后发送许多 HIT，而无需重新建立新的 TCP 会话（三次握手）。同样，许多 LB 维护与后端系统的保持活动会话，从而无需在后端进行相同的握手。
严格的 TCP 负载平衡可能无法轻松实现这两者。
/* FWIW：我不会说“L7”或“L4”，我会说 HTTP 或 TCP。但我坚持避免使用 OSI 来描述它不太匹配的事物。*/
我认为从根本上讲，如果您不确定要部署什么，请选择您觉得简单自然的。测试它（使用 apache bench？）并确保它能满足您的需求。对我来说，HTTP LB 更自然。
答案2
鉴于 L7 平衡对您没有好处，我建议改用 L4 平衡。我非常喜欢尽可能保持简单，但又不会牺牲太多。
L7 要求均衡器检查通过它们的数据包中的 http 标头，以确定适当的路由，这会增加额外的开销，并略微增加最终用户的延迟。如果你不会从中得到任何好处，那么这对我来说似乎是毫无意义的花费。
答案3
一些 DNS 提供商具有简单的故障转移功能。您提到了您的要求是什么，但没有提到它们是什么，但是如果您需要的只是在发生故障时进行故障转移的循环，那么您可以使用例如zoneedit.com 的故障转移。根据您的 HA 需求，这可能已经足够好了，您可以跳过架构中的整个层级。