我正在尝试为我的数据中心或第7层解决scheme使用第4层负载平衡解决scheme。 不幸的是（为了我的理智，就是这样），我的用例很简单，两种解决scheme都能很好地工作，避免了大部分的弱点，并且没有真正利用这些优势。 无论我们最终使用哪种解决scheme，都必须具有高可用性和高吞吐量。 但我们只打算使用它来对一组Web服务器进行负载平衡，而这些Web服务器中没有一个对“粘性”会话pipe理（cookie或IP）有任何要求，复杂的重写规则 – 或者就此而言，任何重写规则所有。
负载平衡器将连接到两台交换机，两台交换机都独立连接到数据中心汇聚层，并使用快速生成树和交换机用于虚拟化的任何专有协议合并在一起。 负载平衡器也将通过交叉电缆交叉连接。 集群中的所有服务器都连接到两台交换机。 负载平衡器所要做的就是将stream量指向它们。
由于它只是HTTP，所以我可以使用像HAProxy或nginx这样的第7层负载平衡解决scheme。 但是我也可以用ldirectord或者keepalived或者其他方法来使用LVS项目。
当我看到他们的时候，我试图分解利弊，但最后只是洗了一把。 你会推荐什么？为什么？ 我错过了什么吗？
像haproxy这样的“L7”的一个有用的好处是能够使用cookie来保持相同的浏览器击中相同的后端服务器。 这使得debugging客户端命中更容易。
L4平衡可能会在几个后端服务器上反弹一个用户。 （在某些情况下可能是有利的，但从debugging/分析的angular度来看，使用“L7”更有价值）。
编辑：使用HTTP平衡也有一个潜在的速度优势。 使用保活客户端可以为您的平衡器build立单个TCP会话，然后发送多个HIT而无需重新build立新的TCP会话（三次握手）。 类似地，许多LB保持对于后端系统的保持活动会话，从而不需要在后端执行相同的握手。
严格的TCP负载均衡可能无法轻松实现这两者。
/ * FWIW：我不会说“L7”或“L4”，我会说HTTP或TCP。 但是我是一个坚持使用OSI来描述它不匹配的东西。 * /
我认为，如果你不确定要部署什么，那么从根本上来说，应该对你感觉简单自然。 testing它（使用Apache的工作台？），并确保它适合您的需求。 对我来说HTTP LB更自然。
由于做L7平衡对你没有好处，所以我会selectL4平衡。 我非常喜欢保持简单，而不会牺牲太多。
L7要求平衡器检查正在通过它们的数据包中的http报头是否有适当的路由，增加了额外的开销，并增加了最终用户的等待时间。 如果你一无所获，那对我来说似乎是毫无意义的代价。
一些DNS提供商具有简单的故障转移function。 你已经提到了你的需求不是什么，也不是它们是什么，但是如果你所需要的只是在故障转移的情况下循环，那么你可以使用例如zoneedit.com的故障转移 。 根据您的HA需求可能足够好，你可以跳过你的架构整个层次。