第4层与第7层负载平衡

我试图决定在为我的数据中心使用第4层负载平衡解决方案还是第7层解决方案之间进行选择。不幸的是（出于我的理智），我的用例非常简单，以至于两个解决方案都能很好地工作，避免了大多数缺点，而没有真正利用其他优点。无论我们最终使用什么解决方案，它都必须具有高可用性和高吞吐量。但是，我们仅打算使用它在Web服务器群集上实现负载平衡，这些服务器对“粘性”会话管理（Cookie或IP），复杂的重写规则均无任何要求，因此，对于所有。

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

由于它只是HTTP，因此我可以使用第7层负载平衡解决方案，例如HAProxy或nginx。但是我也可以将LVS项目与ldirectord或keepalived或其他任何东西一起使用。

我曾尝试打破正反两面的优点和缺点，但最终却陷入了困境。您会推荐什么，为什么？我想念什么吗？

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

L4平衡可能会在多个后端服务器上反弹单个用户。（在某些情况下可能是有利的，但从调试/配置的角度来看，使用“ L7”更为有价值。）

编辑：使用HTTP平衡还有潜在的速度优势。借助保持活动状态，客户端可以与您的平衡器建立一个TCP会话，然后发送许多HIT，而无需重新建立新的TCP会话（三向握手）。同样，许多LB保持到后端系统的保持活动会话，从而无需在后端进行相同的握手。

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

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

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

鉴于进行L7平衡对您缺乏优势，我将改用L4平衡。我非常乐意在不牺牲太多的前提下尽可能地保持简单。

L7要求平衡器检查通过它们的数据包中的http标头，以进行适当的路由选择，从而增加了额外的开销，并且最终用户的等待时间略有增加。如果您一无所获，这对我来说似乎是毫无意义的支出。

一些DNS提供程序具有简单的故障转移功能。您已经提到您的需求不是，不是需求，但是如果您所需要的只是发生故障时进行故障转移的循环，那么您可以使用例如zoneedit.com的Failover。根据您的HA需求，可能足够好，您可以跳过体系结构中的整个层。