Linux bond模式 | 使用场景 | 特点 | 原理 | 交换机配置要求 | 缺点 |
mode=0(balance-rr)(平衡抡循环策略) | 适用于简单负载均衡,但不严格要求数据包顺序的场景。(常用) 比如:适用文件服务器、大型数据传输、高流量Web服务器等场景。不适用需要严格保持数据包顺序或者要求极高网络一致性(如某些实时通信应用)的场景。 | 链路负载均衡、增加整体带宽、高可用 | 传输数据包顺序是依次传输(即:第1个包走eth0,下一个包就走eth1….一直循环下去,直到最后一个传输完毕),此模式提供负载平衡和容错能力。 | 交换机应该能够识别并处理从多个接口发出的流量,且不会因流量来自同一MAC地址但不同接口而产生冲突。某些交换机可能需要设置为端口聚合(但不是LACP模式),或者配置为允许独立接口接受来自同一源MAC的不同流量。 | 数据包无序到达:当一个连接或会话的数据包从不同的网络接口发出,并经过不同的物理链路时,在客户端可能会出现数据包无序到达的现象。虽然TCP/IP协议栈会尝试重新排序这些数据包,但无序到达的数据包可能需要重新发送,这会导致网络的吞吐量下降。 交换机配置问题:如果交换机没有正确配置,或者聚合组中的某个端口出现故障,可能会导致数据包丢失或传输问题。 切换时间过长:如果网络接口的切换时间过长(例如,由于硬件故障或驱动程序问题),可能会导致缓冲区溢出,从而导致数据包丢失。 |
mode=1(active-backup)(主-备份策略) | 适用于需要高可用性场景。(常用) | 这个是主备模式,只有一块网卡是active,另一块是备用的standby,所有流量都在active链路上处理,交换机配置的是捆绑的话将不能工作,因为交换机往两块网卡发包,有一半包是丢弃的。 | 只有一个设备处于活动状态,当一个宕掉另一个马上由备份转换为主设备。mac地址是外部可见得,从外面看来,bond的MAC地址是唯一的,以避免switch(交换机)发生混乱。 | 无特殊的交换机配置要求,推荐将连接到交换机的接口配置为Access模式或类似的非聚合模式。 | 资源利用率低。 恢复时主接口优先:当主接口恢复正常时,它通常会重新接管网络通信,而备份接口则再次回到待机状态。 |
mode=2(balance-xor)(平衡策略) | 多个网络接口之间实现负载均衡和容错多个网络接口之间实现负载均衡和容错。(生产环境中使用较少) | 负载均衡、容错 | 传输是根据 [(源MAC地址 XOR 目标MAC地址) mod 设备数量] 的布尔值来选择传输设备的。这意味着对于每个数据包,系统都会根据源MAC地址、目标MAC地址以及当前可用的网络接口数量来计算一个值,然后基于这个值来决定数据包应该通过哪个网络接口进行传输。 | 交换机通常不需要进行特殊的配置,但你需要确保交换机支持链路聚合和负载分担。 | 1)配置复杂:该模式需要交换机支持链路聚合(如Cisco的Port Channel),并可能需要配置xmit_hash_policy和交换机的port channel,增加了配置的复杂性和难度。 2)资源利用率可能较低:在某些情况下,由于基于XOR Hash算法的数据包分发方式,可能导致部分网络接口的资源利用率较低,尤其是在网络接口数量较多、网络流量不均衡的情况下。 |
mode=3(broadcast)(广播策略) | 实际生产环境中几乎不用,因为会造成大量不必要的数据复制。 | 高可用 | 在每个slave接口上传输每个数据包,此模式提供了容错能力 | 无特殊要求。 | 交换机配置:mode=3(broadcast)模式通常需要与交换机的聚合强制不协商方式配合使用。 资源利用率低:在拥有N个网络接口的情况下,只有一个接口处于工作状态,资源利用率为1/N。 |
mode=4(802.3ad)(IEEE 802.3ad 动态链接聚合) | 适用于要求高带宽和高可用性的网络环境,比如数据中心、服务器集群的连接。(生产环境中使用较多) 比如:数据中心、企业网络、互联网服务提供商 | 高可用、冗余和负载均衡 | IEEE 802.3ad是执行链路聚合的标准方法,其将多个以太网适配器聚集到单独的虚拟适配器上,提供更高的带宽并防止发生故障。与“以太通道”相似,IEEE 802.3ad也需要交换机的支持,但不同的是,交换机不需要手动配置来了解哪些端口属于同一个聚合。 | LACP支持:交换机必须支持 IEEE 802.3ad 和 LACP 协议。 端口配置:需要配置参与链路聚合的物理端口,通常配置为 LACP 活动模式(active)或被动模式(passive)。 同速率端口:聚合的物理端口应具有相同的速率(例如,都为 1Gbps 或 10Gbps),以避免带宽不对称的问题。 相同配置:参与聚合的端口应具有相同的配置参数,如 VLAN、MTU 等。 | 流量模式单一的情况下,很难实现真正的负载均衡。 |
mode=5(balance-tlb)(适配器传输负载均衡) | 适用于需要根据发送流量动态调整但不支持LACP或不需要接收负载平衡的场景。 | 发送流量负载均衡 | 数据发送是根据每个slave(可以理解为网络接口或服务器节点)的负载情况选择slave进行发送的,而接收时则使用当前轮到的slave。这种负载均衡模式解决了数据发送的瓶颈问题,但无法并行接收数据包。 | 不涉及 | 单接口入站限制: 入站流量只能通过一个接口进入,无法平衡接收流量。 无冗余故障转移: 入站流量的单接口特性导致在该接口故障时,接收流量会中断。 链路使用不对称: 仅对传输流量进行负载均衡,可能导致链路使用不对称。 |
mode=6(balance-alb)(适配器适应性负载均衡) | 在Mode 5的基础上增加了接收负载平衡的能力,但需要内核支持并且有一定的限制。它尝试通过ARP协商来平衡接收流量,适用于希望在不支持LACP的情况下实现较高级别负载平衡的环境。 | 适应性负载均衡 | 接收负载均衡原理: 接收数据时,则采用ARP协商的方式来实现负载均衡。具体而言,bonding驱动会截获本机发送的ARP应答,并把源硬件地址改写为bond中某个slave的唯一硬件地址,从而使得不同的对端使用不同的硬件地址进行通信。同时,来自服务器端的接收流量也会被均衡。 | 不涉及 | 复杂性增加: 由于需要处理 ARP 响应来调整入站流量路径,实现较为复杂。 兼容性问题: 需要网络中的其他设备正确处理修改后的 ARP 响应,某些网络设备可能不兼容。 单故障点: 尽管改善了入站流量的平衡,但仍然依赖于单一的 ARP 处理机制,可能存在单点故障风险。 |
Linux网卡bond的其中模式详解
于 2024-05-20 15:51:43 首次发布