大数据场景下linux双网卡bond接入实践
01
双网卡bond调优背景
双网卡绑定技术较早在各个主机操作系统引入，如HP-UNIX的APA、IBM的EtherChannel，linux上也有对应bond技术。通过双网卡绑定，一方面利用主备网卡自动切换可以提高网络接入的高可用能力，另一方面双网卡bond部分模式下可以双活的接入，充分利用硬件资源，实现负载均衡，极大的提升主机接入带宽能力。近年，随着分步式计算、大数据大规模兴起，不断增长的计算节点之间海量数据传输交互，内部节点处理过程产生大量东西向流量，要求网络具有良好的扩展性和吞吐率，能够充分适应业务突发流量且具备高可靠性，对主机双网卡bond要求既能充分利用链路带宽资源又具备高可靠性显得尤其重要。目前大数据广泛应用的平台一般是基于linux操作系统，为此我们以linux下的bond模式为例开展研究和分析。
02
Linux双网卡bond方式简介
基于linux的操作系统网卡bond模式有七种，模式 (0~6) mode=0、mode=1、mode=2、mode=3、mode=4、mode=5、mode=6，七种bond模式分别说明如下：
第一种模式：mode=0，即：(balance-rr) Round-robin policy（负载均衡轮询策略）
特点：传输数据包顺序是依次传输（即：第1个包走eth0，下一个包就走eth1….一直循环下去，直到最后一个传输完毕），此模式提供负载平衡和容错能力；如果一个连接或者会话的数据包从不同的接口发出的话，中途再经过不同的链路，在客户端很有可能会出现数据包无序到达的问题，而无序到达的数据包需要重新要求被发送，这样网络的吞吐量就会下降。
第二种模式：mode=1，即： (active-backup) Active-backup policy（主-备用策略）
特点：只有一个网卡处于活动状态，当一个宕掉另一个即刻由备用状态转换为主用状态。从交换机上看，bond的MAC地址是唯一的，以避免SwitchARP表项发生混乱。此模式只提供了容错能力；由此可见此算法的优点是可以提供高网络连接的可用性，但是它的资源利用率较低，只有一个接口处于工作状态，在有N个网络接口的情况下，资源利用率为1/N。
第三种模式：mode=2，即：(balance-xor) XOR policy（平衡策略）
特点：基于指定的传输HASH策略传输数据包。缺省的策略是：通过源和目标mac做hash因子来做xor算法来选路的。其他的传输策略可以通过xmit_hash_policy选项指定，此模式提供负载平衡和容错能力。
第四种模式：mode=3，即：broadcast（广播策略）
特点：在每个slave接口上传输每个数据包，一个报文会复制两份往bond下的两个接口分别发送出去,当有对端交换机失效时无感知。此方式过于浪费资源，但有很好的容错机制。
第五种模式：mode=4，即：(802.3ad) IEEE 802.3ad Dynamic link aggregation（IEEE 802.3ad动态链路聚合）
特点：创建一个聚合组，它们共享同样的速率和双工设定。根据802.3ad规范将多个slave工作在同一个激活的聚合体下。外出流量的slave选举是基于传输hash策略，该策略可以通过xmit_hash_policy选项从缺省的XOR策略改变到其他策略。
必要条件：
条件1：ethtool支持获取每个slave的速率和双工设定
条件2：Switch(交换机)支持IEEE 802.3ad Dynamic link aggregation
条件3：大多数Switch(交换机)需要经过特定配置才能支持802.3ad模式
第六种模式：mode=5，即：(balance-tlb) Adaptive transmit load balancing（适配器传输负载均衡）
特点：不需要任何特别的Switch(交换机)支持的通道bonding。在每个slave上根据当前的负载（根据速度计算）分配外出流量。如果正在接受数据的slave出故障了，另一个slave接管失败的slave的MAC地址。
该模式的必要条件：ethtool支持获取每个slave的速率。
第七种模式：mode=6，即：(balance-alb) Adaptive load balancing（适配器适应性负载均衡）
特点：该模式包含了balance-tlb模式，同时加上针对IPV4流量的接收负载均衡(receive load balance, rlb)，而且不需要任何switch(交换机)的支持。接收负载均衡是通过ARP协商实现的。bonding驱动截获本机发送的ARP应答，并把源硬件地址改写为bond中某个slave的唯一硬件地址，从而使得不同的对端使用不同的硬件地址进行通信。来自服务器端的接收流量也会被均衡。当本机发送ARP请求时，bonding驱动把对端的IP信息从ARP包中复制并保存下来。当ARP应答从对端到达时，bonding驱动把它的硬件地址提取出来，并发起一个ARP应答给bond中的某个slave。使用ARP协商进行负载均衡的一个问题是：每次广播ARP请求时都会使用bond的硬件地址，因此对端学习到这个硬件地址后，接收流量将会全部流向当前的slave。这个问题可以通过给所有的对端发送更新（ARP应答）来解决，应答中包含他们独一无二的硬件地址，从而导致流量重新分布。当新的slave加入到bond中时，或者某个未激活的slave重新激活时，接收流量也要重新分布。
必要条件：
条件1：ethtool支持获取每个slave的速率；
条件2：底层驱动支持设置某个设备的硬件地址，从而使得总是有个slave(curr_active_slave)使用bond的硬件地址，同时保证每个bond中的slave都有一个唯一的硬件地址。如果curr_active_slave出故障，它的硬件地址将会被新选出来的curr_active_slave接管。
mode=6与mode=0的区别：mode=6，先把eth0流量占满，再占eth1，…ethX；而mode=0的话，会发现两个口的流量都很稳定，基本一样的带宽。在mode=6下，会发现第一个口流量很高，第2个口只占了小部分流量。
以上我们对linux双网卡不同bond模式进行了分析。通过分析可知，mode=1实现最简单，对接入交换机无适配要求，交换机无需做链路聚合配置；mode=0、mode=2需交换机配置静态链路聚合；mode=4需要交换机进行动态链路聚合配置；mode=3，报文会复制两份往bond下的两个接口分别发送出去，无形中增大了网络中无用的带宽；mode=5、mode=6两种模式基于网卡适配器传输特性实现，bond组里端口流量可能分担不均。对于mode=2、mode=3、mode=5、mode=6这些模式或配置复杂、或浪费资源而没得到广泛使用，故我们选取业界最常用的三种模式mode=0、mode=1、mode=4进行测试比较。
03
双网卡不同bond模式接入实测效果对比及调优
在大数据集群主机中多采用主备双网卡接入。随着大数据集群规模的扩大，集群内加载机对带宽需求与日俱增，为此我们对部分加载机进行了双网卡bond模式修改，将之前的主备模式调整成负载均衡轮询模式。经过调整，加载机双网卡能有效分担流量，流量已超过之前主备卡接入模式下最大10GEb/s限制，高峰时达到近20GEb/s。但在调整后，应用维护人员反映集群存在加载延时和失败率偏高的问题。经在集群内部加载机上抓包分析，发现存在大量out_of_order、lost_segment、duplicate_ack、retransmission报文。在网络存在多路径、拥塞时可能导致这些异常报文大量出现。在同样加载场景下，在主备网卡接入的加载机上抓包，发现仅有少量此类报文出现。初步怀疑因修改加载机双网卡bond接入为负载均衡轮询模式导致。
以下我们将在大数据集群环境下对linux主机mode=0、mode=1、mode=4三种模式进行测试对比，在主机端对bond端口抓包进行分析，并在抓包文件里统计out_of_order、lost_segment、duplicate_ack、retransmission报文数量，作为bond接入模式选择参考依据。
>>>>接入测试环境
| 项目 |
明细 |
| 软硬件环境 （三台配置相同的主机） |
X86服务器 |
| Cpu: 4*8 |
|
| 硬盘：21*900 SAS 10krpm |
|
| 内存：512GB |
|
| 操作系统：redhat 6.5 |
|
| 网络 |
2台N7010接入交换机，支持vPC(virtual port channel), 3台加载机，每台加载机或节点机两块万兆网卡分别连至不同交换机。 |
| 部署架构 |
主仓3*12 节点机+ 3加载机 |
| 数据库版本 |
GBase8a_MPP_Cluster-8.5.1.2_build11.4_r64_2-redhat6.2-x86_64.tar.bz2 |
>>>>
接入拓扑示意
不同bond模式下加载效率对比
在集群里分三次通过加载机向36台节点机装载数据，第一次通过加载机server1装载数据，第二次通过server2装载数据，第三次通过server3装载数据。每次加载机启动加载，待速度稳定后，观察加载机的加载速度，并在加载机机上使用tcpdump抓包。抓包后，使用Wireshark软件分析out_of_order、lost_segment、duplicate_ack、retransmission报文计数情况。每次装载数据只启动一个单任务作业，保持三次测试环境条件一致。
| 报文类型 |
注解 |
| out_of_order |
由于是通过不同的路径或者传输有问题，延时太长，或者包丢失，需要重新组合数据单元 |
| lost_segment |
这个错误非致命，如果大量出现，证明发送和接受者的通信机制需要改善 |
| duplicate_ack |
当收到一个它认为出问题的分片，Tcp立即产生一个应答。这个相同的ack不会延迟。其的意图是让对端知道一个分片被收到的时候出现问题，并且告诉它希望得到的序列号 |
| retransmission |
作为一个可靠的传输协议，传输控制协议（TCP）在发送主机需要从目标主机收到一个包时确认，如果未确认，就会重传 |
在某时间间隔内分别统计每次节点机加载速度和可能造成传输质量问题的相关报文计数情况。
| 加载机 |
节点机每节点加载速度 |
duplicate_ack |
retransmission |
lost_ segment |
out_of_order |
| 负载均衡轮询模式（mode=0） |
3.79MB/s |
11157 |
61 |
7524 |
12197 |
| 主备模式 （mode=1） |
5.33MB/s |
47 |
8 |
118 |
31 |
| 802.3ad动态链路聚合模式（mode=4） |
9.46MB/s |
56 |
13 |
134 |
45 |
从以上数据对比可以看出，双网卡在负载均衡轮询模式下网络传输质量低于主备卡模式及802.3ad动态链路聚合模式。802.3ad模式能高效利用两张卡同时进行数据传输，理论上速度较主备卡模式提升一倍。从网络质量方面对比，负载均衡轮询模式下的out_of_order数量是主备模式及802.3ad动态链路聚合模式的300多倍，表明在负载均衡轮询模式下报文的乱序严重，而接收端需要等报文顺序到达，可能会导致接收端认为报文丢失，引起拥塞窗口的调整和快速重传。另一方面，当TCP报文发生乱序时，接收端对接收到的数据在缓存中重新排序，并按照正确报文顺序交付给应用程序，这可能会导致所有已到达的报文在缓存中等待序号小的报文到达，而当缓存满时，后面的报文就不能再接收了，这样会导致应用程序性能的下降，也可能会影响到系统CPU资源的利用率。
>>>>大数据集群加载机主机网卡bond模式调优
在大数据加载机装载数据时，并发持续加大，长时间加载情况下，问题累加会更加严重。一方面加重了网络负担，同时会导致操作系统CPU 系统资源占用较多，周而复始恶性循环，可能造成加载失败和集群的分裂。
目前大数据集群其中一台加载机双网卡已修改为802.3ad动态链路聚合模式，暂未发现集群加载数据延时和失败率偏高的问题，后期可考虑在大数据集群主机中大范围采用802.3ad模式进行双网卡bond,更加有效利用网卡、交换机端口及链路资源。
双网卡bondmode=4模式，主机配置参考：
交换机侧配置参考：
本次以数据中心交换机Cisco Nexus7010（支持vPC，跨框链路聚合）为例,单台主机两张网卡分别接入主备两台交换机。在主机双网卡配置802.3ad bond模式下，交换机适配配置如下：
04
关于各类常用bond模式适用场景的思考
通过在大数据场景下双网卡三种bond接入模式的测试对比，结合现网生产环境，我们对这三种接入模式适用场景进行了梳理如下：
-
mode=0模式，网卡工作在负载均衡轮询模式。接入交换机需支持静态链路聚合功能，需配置port-channel。比较适用于在双网卡同时接入单台交换机的环境。当接入两台交换机时，两台交换机需堆叠或支持跨框链路聚合，若两台交换机网关双活，网络出口存在多条冗余链路时可能会出现数据包乱序、重传现象。
-
mode=1模式，网卡工作在主备用模式。该模式实现最简单，对接入交换机无特殊配置要求，中低端交换机均支持，交换机端口配置成access端口即可。主机双网卡可同时接入单台交换机或两台主备交换机上。适用于两台主备交换机不支持跨框链路聚合、主机对带宽需求不高但又要保证高可靠性的环境。目前在传统网络中较为常见。
-
mode=4模式，网卡工作在802.3ad动态链路聚合模式。接入交换机需支持动态链路聚合功能，需配置port-channel并封装LACP协议。适用于双网卡同时接入单台或两台交换机环境，两台交换机需堆叠或支持跨框802.3ad动态链路聚合。此种模式下，双网卡能有效分担流量压力，能有效增加主机接入带宽，同时也保证了高可靠性。可广泛运用于资源池、大数据环境。