在设计网络拓扑时，有什么理由不依赖 LACP 吗？我指的是 L2切换到虚拟机管理程序连接，因此它是虚拟机聚合流量累积的地方。我们讨论的是 5 x 1 GbE LACP 绑定。
我与同事意见相左。他说：“为什么我们要在整个设置中添加另一层开销？这只是另一个潜在的故障点。”他总体上对链路聚合持怀疑态度。我认为 802.3ad 模式下的 Linux 绑定驱动程序是可靠的，也是不错的选择。
他还认为我们不需要它，因为我们的环境中永远不会有这么大的流量，简单的 1 GbE 就足够了。我们是一所高中，我们的 LAN 中有大约 100 个 PC 客户端和大约 10 台服务器。
因此，我们处于这样的境地：我们不知道我们是否需要 LACP。一些有关网络流量的额外数据是可以的，但我认为检索有意义的数字具有挑战性。所以最终更容易依靠直觉并说：“是的，为了确保万无一失，我们需要 LACP。”或者“不因为它不可靠，而且我们不需要它。”
有什么建议么？
答案1
事实上，LACP 的诞生正是解决LAG（链路聚合组）本身就存在一个危险的问题。
当在直接连接的接口之间使用时，LAG 并不危险。在这样的设置中，基本上任何网络问题都可以追溯到没有链接的端口 - 这会自动指示交换机停止向断开连接的端口发送流量。
但是，如果启用 LAG 的交换机和聚合 Gbit 端口之间有其他设备，则其他逻辑可能会出现问题，从而导致真正的问题，因为转发交换机没有关于这些瞬态问题的信息（它将继续盲目地将流量发送到断开连接/有问题的端口）。
为了解决这个问题，LACP 被定义：它使用基于心跳的系统不断监控聚合端口，并在丢失太多心跳时自动断开它们。
简而言之：如果配置正确，我认为使用 LACP 没有任何问题。唯一需要考虑的是，您不可避免地需要跟踪/管理稍微复杂的配置。
答案2
是的，我信任 LACP。与其他所有链路聚合方法相比，我更喜欢 LACP，因为它非常可靠、灵活，并且是 IEEE 标准，因此可以保证供应商互操作性。
如果您认为虚拟机每秒的流量将超过 1 千兆位（这很容易做到），那么您需要进行负载平衡。唯一适合您的负载平衡模式（在 Linux 上）是模式 2（balance-xor）或模式 4（LACP）。模式 2 使用与模式 4 相同的平衡，只是没有向交换机发送持续的心跳。