第 4 层与第 7 层负载平衡

Question

我正在尝试决定是为我的数据中心使用第 4 层负载平衡解决方案还是使用第 7 层解决方案。不幸的是（就我的理智而言），我的用例很简单，两种解决方案都可以很好地工作，避免了大多数弱点并且没有真正利用另一个的优势。无论我们最终使用什么解决方案，它都必须具有高可用性和高吞吐量。但我们只打算用它来平衡一组 Web 服务器的负载，这些服务器对“粘性”会话管理（cookie 或 IP）、复杂的重写规则没有任何要求——或者，就此而言，任何重写规则都在全部。

负载平衡器将连接到两台交换机，两者都具有到数据中心聚合层的独立连接，并使用快速生成树和交换机用于虚拟化的任何专有协议合并在一起。负载平衡器也将通过交叉电缆相互交叉链接。集群中的所有服务器都连接到两台交换机。负载均衡器所要做的就是将流量指向它们。

由于它只是 HTTP，我可以使用 HAProxy 或 nginx 等第 7 层负载平衡解决方案。但我也可以将 LVS 项目与 ldirectord 或 keepalived 一起使用。

我试图打破我所看到的利弊，但最终还是洗白了。你会推荐什么，为什么？我错过了什么吗？

Answer 1

“L7”的一个有用的好处是能够使用 cookie 来保持相同的浏览器访问相同的后端服务器。这使得调试客户端命中变得更加容易。

L4 平衡可能会在多个后端服务器上反弹单个用户。（这在某些情况下可能是有利的，但在调试/分析的意义上，使用“L7”更有价值。）

编辑：使用 HTTP 平衡还有一个潜在的速度优势。使用 keep-alives 客户端可以与您的平衡器建立单个 TCP 会话，然后发送许多 HIT，而无需重新建立新的 TCP 会话（3 次握手）。类似地，许多 LB 与后端系统保持保持活动会话，从而无需在后端进行相同的握手。

严格的 TCP 负载平衡可能无法轻松实现这两个目标。

/* FWIW：我不会说“L7”或“L4”，我会说 HTTP 或 TCP。但我坚持避免使用 OSI 来描述与它不匹配的事物。*/

我认为从根本上说，如果您不确定要部署什么，请选择您觉得简单自然的东西。测试它（使用 apache bench？）并确保它满足您的需求。对我来说 HTTP LB 更自然。

Answer 2

鉴于进行 L7 平衡对您没有任何好处，我会改用 L4 平衡。我非常喜欢保持它尽可能简单，不要牺牲太多。

L7 要求平衡器检查通过它们的数据包中的 http 标头以进行适当的路由，这会增加额外的开销并略微增加最终用户的延迟。如果你一无所获，这对我来说似乎是毫无意义的花费。