解决服务器聚合中的中断问题
2017-11-22
引言：随着服务的提升，广电双向网络的各类服务器流量逐步提升。由于安全性及稳定性的要求，避免单点故障，网线也需要有备份。这就要求我们针对很多设备采用多网卡聚合分担流量和单点风险。而手动聚合会导致服务器的服务中断一小会儿。下面笔者就结合自身经验，谈一谈设计网卡bonding脚本解决服务器聚合中的业务中断问题。
手动聚合的隐患
随着济宁广电双向网业务，特别是智慧系列业务的增加，济宁市每个县都逐步增加了服务器的数量，每台服务器上的流量也从几百Mbps增加到了两三个Gbps，这就需要对服务器的千兆网卡做聚合。由于县区一些同事术业有专攻，对Linux可能不熟悉，需要市公司远程进行配置。
如此操作存在隐患：手动配置比较慢，网络调整中服务中断的时间过长。如果加快配置速度，一旦整个配置的流程有任何地方出现失误，就会导致服务器断网，没法再远程调整，只能开车去县公司修复，反而导致中断时间更长。
网卡绑定方法明细
Linux服务器的网络组件共有7种绑定方法。但在某些中文搜索引擎上搜索出来的linux网卡聚合绑定方式，内容大同小异，甚至部分搜索结果中某命令中单词错误的字母都一样，很明显都是蜘蛛机器人（网络爬虫）自动采集出来的文章（各蜘蛛网站都有SEO优化，蜘蛛会自动替换同义词以便欺骗搜索引擎的相应检测功能）。
有可能原始文章的作者写的非常清楚明白，但搜索页面的前几页的结果都是有各种问题的，我们已经很难找到真正的实用原文了。
笔者直接到redhat官方产品手册30.8.Specific Kernel Module Capabilities章节中找到了七种绑定模式（mode）的英文说明。
下面结合网络运维中交换机的操作，简略介绍各种模式的选择。配置文件中，模式的选择是用mode=
1.Mode=0，balance-rr
轮询容错、负载均衡。数据从每个绑定的网卡按顺序依次收发。但缺点是不同的包由于走不同的口子，到达目的地的顺序可能会错乱。交换机不用配置。
2.Mode=1，active-backup
主备容错。数据全部走第一个口，坏掉后才走第二个口，然后是第三个。端口使用效率只有1/N。交换机不用配置。
3.Mode=2，balance-xor
异或容错、负载均衡。用外界请求的mac地址与某个网卡运算，连接建立后数据从第一个可用的接口收发。需要交换机支持。
4.Mode=3，broadcast
广播容错。数据包从所有网卡都发送出去，虽然端口利用率100%，但对服务器来说只有一份数据发出去，流量利用率1/N。
5.Mode=4，802.3ad
使用IEEE 802.3ad动态链路聚合协议。交换机同样需要启用802.3ad协议。
6.Mode=5，balance-tlb
基于传输负载均衡TLB的容错。发送的包根据各口的负载选择，接收的包使用对方传输进来的口，如果这个口传输失败，则另外一个网口通过接管故障网口的MAC来接收数据。此模式需要内核能识别的本地地址，故而不能位于桥接虚拟机之后。
7.Mode=6，balance-alb
自适应负载均衡ALB的容错，基于IPV4流量的收发负载均衡。其中接收数据的负载均衡通过ARP协商处理。同样不能位于桥接之后。
bonding脚本设计
脚本采用#!/bin/bash作为执行引擎。用于将服务器eth0-3或em1-4绑定到一起。
第一步：
#初始化
第二步：
#判断服务器是eth0-3命名还是em1-4命名
第三步:
#然后设置4个网卡
第四步:
#复制模板到对应的网卡，用cat防止cp被alias绑定-i参数
第五步:
#设置聚合模板
第六步：
#用mode=4，交换机需要同样开启lacp active 802.3ad聚合
第七步:
#重启网络
第八步：
#删除此shell脚本本身
上述脚本的完整代码，我已经开源公布至github.com/leniy平台
安全运行方式
第一，选择空闲的交换机端口并shutdown掉，然后用这个网口连接服务器新网卡
第二，交换机开启lacp none模式，即普通的聚合，默认很据目的mac和来源mac的异或运算选择端口，但由于新加的端口屏蔽掉了，数据全部走之前在用的网口，网络不会断。
第三，服务器执行脚本后网卡聚合完成，采用802.3ad模式。对于交换机来说，此时交换机为普通聚合模式，会忽略802.3ad协议包直接接收数据，同时由于另外一个网口已经关闭了，所以不会出现环路或mac冲突等故障。此时网络只在脚本执行的一瞬间闪断一次。
第四，然后交换机开启lacp active模 式， 即802.3ad，与服务器相同。此时新加端口shutdown数据全部走旧网卡。然后登录交换机no shutdown对应的端口，则新数据包自动开始负载均衡。
业务中断时间测试
上述 1、2、4 步骤网络不中断，第3步网络闪断，聚合过程中ssh连接一直正常，可以证明网络没有长时间中断。同时经过10次专门的测试，ping没有发现网络有中断的情况。
因为ping间隔约为1s，且连续10次测试都没有遇到闪断，则我们可以认为网络闪断时间远远少于1秒。且本服务器用于流媒体推流，视频UDP切片长于1秒，则可以认为服务未断一直正常提供服务。
结语
其实linux网卡聚合非常方便，熟悉了七种模式后直接手动输入代码即可，不熟悉的话修改别人的代码挨个尝试也行。但很多人仍不会或不敢配置，最关键的原因在于远程调试时错任何一步，网络就断了，开车去现场至少耗时半天才能恢复。因此一个完善的脚本就显得尤为重要。
