在
Linux下,您可以将多个网络接口组合到“绑定”网络接口中以提供故障转移.
但是有几种模式,其中一些不需要交换机支持.我不能在我的开关中受限制,因为我可以使用任何模式.
然而,在阅读有关不同模式的内容时,并不能立即明确每种模式的优缺点.
>某些模式是否提供更快的故障转移？
>每种模式的cpu负载影响如何？
>哪些模式可以结合带宽而不仅仅提供冗余？
>那有限制吗？
> balance-rr是否需要交换机支持？
>可靠性？你有长期的经历吗？
解决方法
>故障转移的最大因素是检测到链路故障的速度.从主机拔下电缆,它们都能很好地工作.在一个原本无效的交换机上保留一个实时链接,大多数模式(支持信标/保持活动的那些模式除外)将无处发送部分流量.
>一般来说,网络流量是中断驱动的.各种哈希算法不会产生有意义的差异.
>任何非活动/待机模式或广播模式都将分享不同程度的流量.某些模式可以基于每个数据包进行平衡,而其他模式则基于每个流进行工作.前者将更均匀地分散负载,而后者在实际网络中更有用(读取：功能/稳定).
>是的 – 每种模式都有局限性,但我们需要了解更多有关您的应用程序的信息.
>只有LACP / 802.3ad(模式4)明确要求支持交换机.也就是说,仅仅因为您使用特定模式发送到交换机并不意味着交换机将以相同的方式向您发送回来.
>我倾向于信任生产的唯一模式是802.3ad,通过适当配置的交换机,将确保只有正确的链路才会在通道中结束,并且在流量共享中提供一些对称性度量,并在时间内提供可预测的响应.链接已关闭.这种模式还避免了一些常见但令人讨厌的问题(即单播泛滥).主动/待机也很常见.在某些情况下可能需要其他模式,但IMO往往更痛苦.
>一般来说,网络流量是中断驱动的.各种哈希算法不会产生有意义的差异.
>任何非活动/待机模式或广播模式都将分享不同程度的流量.某些模式可以基于每个数据包进行平衡,而其他模式则基于每个流进行工作.前者将更均匀地分散负载,而后者在实际网络中更有用(读取：功能/稳定).
>是的 – 每种模式都有局限性,但我们需要了解更多有关您的应用程序的信息.
>只有LACP / 802.3ad(模式4)明确要求支持交换机.也就是说,仅仅因为您使用特定模式发送到交换机并不意味着交换机将以相同的方式向您发送回来.
>我倾向于信任生产的唯一模式是802.3ad,通过适当配置的交换机,将确保只有正确的链路才会在通道中结束,并且在流量共享中提供一些对称性度量,并在时间内提供可预测的响应.链接已关闭.这种模式还避免了一些常见但令人讨厌的问题(即单播泛滥).主动/待机也很常见.在某些情况下可能需要其他模式,但IMO往往更痛苦.
其他基于流量/ MAC / IP的平衡模式或活动/备用也可以很好,并且在处理非管理型交换机时可能需要.
