目前，我们正在使用 HA 代理来满足负载平衡需求。我们计划将 LVS 与 HA 代理集成，以创建一个可以处理 L4 到 L7 负载平衡和 HA 的负载平衡解决方案。
选择 LVS 的原因是
- 为长期 TCP 会话提供更好的 L4 支持
- 直接服务器返回（在 HA 代理中不可能）
- 当活动负载均衡器发生故障时，对现有连接进行故障转移。
目前，使用 HA Proxy，备份负载平衡器仅负责将新会话负载平衡到后端服务器，而由活动负载平衡器提供服务的现有连接将丢失。我们希望，由于 LVS 在内核空间中运行，它甚至可以对现有会话进行故障转移。
这里有人同时使用过 LVS 和 HA Proxy 吗？
如果是这样，您能否提供一些关于整合两者的指示 - 所有数据包是否都应该由 LVS 接收，然后将 L7 请求发送到 HA 代理？
答案1
我已经推出了混合 IPVS/HAProxy 设置。HAProxy 用于执行一些相当繁重的 L7 决策，因此必须在相对较低的流量量下进行扩展。将 IPVS 放在前面可以对 HAProxy 节点进行扩展，并且无需在该层管理故障转移。对于我需要的特定用例，它运行良好。
对于您所述情况，我不建议使用此设置。通过混合使用两者，您将首先消除选择 IPVS 的原因，因为只要 HAProxy 在堆栈中的某个地方，它的行为就会与现在相同。HAProxy 与长寿命 TCP 连接相关的任何问题仍将存在（因为 TCP 连接仍通过 HAProxy 实例），您只能从 HAProxy 框到 Internet 执行 DSR，并且当 HAProxy 框发生故障时，您仍然会丢失通过该实例的所有连接。
如果你不需要HAProxy 为您提供的特定功能（L7 智能），那么只需使用 IPVS（以获得您所说的想要的好处）。如果您做如果您需要 HAProxy 提供的特定功能，则使用它代替 IPVS。是的，这是一种权衡。您需要决定哪个更重要，以及哪些缺失的功能可以更轻松地进行设计（例如，通过将一些智能转移到后端，或者更好地处理断开的连接并重新建立连接而不会对用户造成可见的影响）。
仅当你需要 HAProxy 的功能时，和你需要扩展 HAProxy，因为在某些情况下，单个 HAProxy 无法工作但单个 IPVS DSR 盒就可以，然后结合使用两者。