链路层的网卡聚合-基于Linux bonding

     Linux总是可以用一种最简单的方式实现一个很复杂的功能，特别是网络方面的 ，哪怕这个功能被认为只是在高端设备上才有，linux也可以很容易的实现，以前的文章已经说了不少次了，比如vlan功能，比如高级路由和防火墙功能等等，本文着重说一下linux的bonding，也就是端口聚合的功能模块。不可否认，在网络设备这个层面上上，linux搞出了两个很成功的虚拟设备的概念，一个是tap网卡，另一个就是本文所讲述的bonding，关于tap网卡的内容，请参阅之前关于OpenVPN的文章。

     如果有一个问题摆在眼前，那就是关于linux bonding有什么比较好的资料，答案就是linux内核的文档，该文档在$KERNEL-ROOT/Documentation/networking/bonding.txt，我觉得没有任何资料比这个更权威了。
一、bonding简介
bonding是一个linux kernel的driver，加载了它以后，linux支持将多个物理网卡捆绑成一个虚拟的bond网卡，随着版本的升级，bond驱动可配置的参数越来越多，而且配置本身也越来越方便了。
     我们在很多地方会使用到物理网卡端口汇聚的功能，比如我们想提升网络速率，比如我们想提供热备份，比如我们想把我们的主机配置成一个网桥，并且使之支持802.3ad动态端口聚合协议等等，然而最重要的还是两点，第一点是负载均衡，第二点就是热备份啦。
二、驱动以及Changes介绍
linux的bonding驱动的最初版本仅仅提供了基本的机制，而且需要在加载模块的时候指定配置参数，如果想更改配置参数，那么必须重新加载bonding模块；然后modprobe支持一种rename的机制，也就是在modprobe的时候支持使用-o重新为此模块命名 ，这样就可以实现一个模块以不同的配置参数加载多次了，起初比如我有4个网口，想把两个配置成负载均衡，两个配置成热备，这只能手工重新将bonding编译成不同的名称来解决，modprobe有了-o选项之后，就可以两次加载相同的驱动了，比如可以使用：
modprobe bonding -o bond0 mode=0
modprobe bonding -o bond1 mode=1
加载两次bonding驱动，用lsmod看一下，结果是bond0和bond1，并没有bonding，这是由于modprobe加载时命名了，然而最终，这个命名机制不再被支持了，因为正如modprobe的man手册所叙述的一样，-o重命名机制主要适用于test。最后，bonding支持了sysfs的配置机制，对/sys/class/net/目录下的文件进行读或者写就可以完成对驱动的配置。
     不管怎样，在sysfs完全支持bonding配置之前，如果想往某一个bonding网卡添加设备或者删除设备的时候，还是要使用经典且传统的ioctl调用，因此必然需要一个用户态程序与之对应，该程序就是ifenslave。
     我想，如果linux的所有关于设备的配置都能统一于sysfs，所有的关于内核和进程配置统一于procfs(内核是所有进程共享的地址空间，也有自己的内核线程以及进程0，因此对内核的配置应该在procfs中)，对所有的消息，使用netlink通信，这就太好了，摆脱了命令式的ioctl配置，文件式(netlink使用的sendto之类的系统调用也可以归为文件系统调用相关的)的配置将更加高效，简单以及好玩！
三、bonding配置参数
在内核文档中，列举了许多bonding驱动的参数，然后本文不是文档的翻译，因此不再翻译文档和介绍和主题无关的参数，仅对比较重要的参数进行介绍，并且这些介绍也不是翻译，而是一些建议或者心得。
ad_select： 802.3ad相关。如果不明白这个，那不要紧，抛开Linux的bonding驱动，直接去看802.3ad的规范就可以了。列举这个选项说明linux bonding驱动完全支持了动态端口聚合协议。
arp_interval和arp_ip_target： 以一个固定的间隔向某些固定的地址发送arp，以监控链路。有些配置下，需要使用arp来监控链路，因为这是一种三层的链路监控 ，使用网卡状态或者链路层pdu监控只能监控到双绞线两端的接口 的健康情况，而监控不到到下一条路由器或者目的主机之间的全部链路的健康状况。
primary： 表示优先权，顺序排列，当出现某种选择事件时，按照从前到后的顺序选择网口，比如802.3ad协议中的选择行为。
fail_over_mac： 对于热备模式是否使用同一个mac地址，如果不使用一个mac的话，就要完全依赖免费arp机制更新其它机器的arp缓存了。比如，两个有网卡，网卡1和网卡2处于热备模式，网卡1的mac是mac1，网卡2的mac是mac2，网卡1一直是master，但是网卡1突然down掉了，此时需要网卡2接替，然而网卡2的mac地址与之前的网卡1不同，别的主机回复数据包的时候还是使用网卡1的mac地址来回复的，由于mac1已经不在网络上了，这就会导致数据包将不会被任何网卡接收。因此网卡2接替了master的角色之后，最好有一个回调事件，处理这个事件的时候，进行一次免费的arp广播，广播自己更换了mac地址。
lacp_rate： 发送802.3ad的LACPDU，以便对端设备自动获取链路聚合的信息。
max_bonds： 初始时创建bond设备接口的数量，默认值是1。但是这个参数并不影响可以创建的最大的bond设备数量。
use_carrier： 使用MII的ioctl还是使用驱动获取保持的状态，如果是前者的话需要自己调用mii的接口进行硬件检测，而后者则是驱动自动进行硬件检测(使用watchdog或者定时器)，bonding驱动只是获取结果，然而这依赖网卡驱动必须支持状态检测，如果不支持的话，网卡的状态将一直是on。
mode： 这个参数最重要，配置以什么模式运行，这个参数在bond设备up状态下是不能更改的，必须先down设备(使用ifconfig bondX down)才可以配置，主要的有以下几个：
1.balance-rr or 0： 轮转方式的负载均衡模式，流量轮流在各个bondX的真实设备之间分发。注意，一定要用状态检测机制，否则如果一个设备down掉以后，由于没有状态检测，该设备将一直是up状态，仍然接受发送任务，这将会出现丢包。
2.active-backup or 1： 热备模式。在比较高的版本中，免费arp会在切换时自动发送，避免一些故障，比如fail_over_mac参数描述的故障。
3.balance-xor or 2： 我不知道既然bonding有了xmit_hash_policy这个参数，为何还要将之单独设置成一种模式，在这个模式中，流量也是分发的，和轮转负载不同的是，它使用源/目的mac地址为自变量通过xor|mod函数计算出到底将数据包分发到哪一个口。
4.broadcast or 3： 向所有的口广播数据，这个模式很XX，但是容错性很强大。
5.802.3ad or 4： 这个就不多说了，就是以802.3ad的方式运行。
…
xmit_hash_policy： 这个参数的重要性我认为仅次于mode参数，mode参数定义了分发模式 ，而这个参数定义了分发策略 ，文档上说这个参数用于mode2和mode4，我觉得还可以定义更为复杂的策略呢。
1.layer2： 使用二层帧头作为计算分发出口的参数，这导致通过同一个网关的数据流将完全从一个端口发送，为了更加细化分发策略，必须使用一些三层信息，然而却增加了计算开销，天啊，一切都要权衡！
2.layer2+3： 在1的基础上增加了三层的ip报头信息，计算量增加了，然而负载却更加均衡了，一个个主机到主机的数据流形成并且同一个流被分发到同一个端口，根据这个思想，如果要使负载更加均衡，我们在继续增加代价的前提下可以拿到4层的信息。
3.layer3+4： 这个还用多说吗？可以形成一个个端口到端口的流，负载更加均衡。然而且慢！ 事情还没有结束，虽然策略上我们不想将同一个tcp流的传输处理并行化以避免re-order或者re-transmit，因为tcp本身就是一个串行协议，比如Intel的8257X系列网卡芯片都在尽量减少将一个tcp流的包分发到不同的cpu，同样，端口聚合的环境下，同一个tcp流也应该使用本policy使用同一个端口发送，但是不要忘记，tcp要经过ip，而ip是可能要分段的，分了段的ip数据报中直到其被重组(到达对端或者到达一个使用nat的设备)都再也不能将之划为某个tcp流了。ip是一个完全无连接的协议，它只关心按照本地的mtu进行分段而不管别的，这就导致很多时候我们使用layer3+4策略不会得到完全满意的结果。可是事情又不是那么严重，因为ip只是依照本地的mtu进行分段，而tcp是端到端的，它可以使用诸如mss以及mtu发现之类的机制配合滑动窗口机制最大限度减少ip分段，因此layer3+4策略，很OK！
miimon和arp： 使用miimon仅能检测链路层的状态，也就是链路层的端到端连接(即交换机某个口和与之直连的本地网卡口)，然而交换机的上行口如果down掉了还是无法检测到，因此必然需要网络层的状态检测，最简单也是最直接的方式就是arp了，可以直接arp网关，如果定时器到期网关还没有回复arp reply，则认为链路不通了。