1、绑定介绍
绑定(bond) 是由多个网卡组合成的、一个单一的、由软件定义的网络设备。因为一个绑定是由多个网卡组成的,因此它可以提供比单一网卡更高的网络传输速度,并提供了更好的网络容错功能(绑定只有在所有的网卡都出现问题时才会停止工作)。但是,绑定设备有一个限制:绑定必须由相同型号的网卡组成。
绑定设备的数据包传输算法是由绑定的模式所决定的。
注意:模式 1、2、3 和 4 支持虚拟机网络(使用网桥)和非虚拟机网络(无网桥);模式 0、5 和 6 只支持非虚拟机网络(无网桥)。
2、绑定模式
Red Hat Virtualization 使用 Mode 4 作为默认的模式,它同时也支持以下绑定模式:
模式 0(round-robin policy)(平衡抡循环策略)
传输的数据包会顺序使用网卡。它会首先使用绑定中的第一个有效的网卡,最后使用最后一个网卡。模式 0 提供了网络容错和网络负载均衡的功能,但它不能和网桥一起使用,因此与虚拟机逻辑网络不兼容。
特点:
模式 1(active-backup policy)(主-备份策略)
绑定中的一个网络接口被设置为活跃接口来处理网络数据,其它网络接口都为备份接口。如果活跃接口出现了问题,备份接口中的一个网络接口会成为活跃接口来继续处理网络数据。使用模式 1 的绑定设备的 MAC 地址只在一个端口上可见,这可以避免因为切换活跃接口所造成的 MAC 地址改变所带来的混淆。模式 1 提供了网络容错的功能。
特点:
模式 2(XOR policy)(异或运算平衡策略)
模式 2(XOR policy)会对源和目标 MAC 地址进行 XOR 操作,所获得的结果再对“次要网卡”的数量进行取模。系统会根据最后所获得的结果来选择用来传输数据包的接口。它保证了对于每个目标 MAC 地址,相同的接口都会被选择。模式 2 提供了容错和负载均衡的功能。
特点:
模式 3(broadcast policy)(广播策略)
使用绑定中的所有网卡来传输数据包。它提供了网络容错的功能。
特点:
这种模式的特点是一个报文会复制两份往bond下的两个接口分别发送出去,当有对端交换机失效,我们感觉不到任何downtime,但此法过于浪费资源;不过这种模式有很好的容错机制。此模式适用于金融行业,因为他们需要高可靠性的网络,不允许出现任何问题。
模式 4(IEEE 802.3ad policy)(IEEE 802.3ad 动态链接聚合)
模式 4(IEEE 802.3ad policy)会创建一个整合的组,这个组会共享网速和网络双工(duplex)设置。模式 4 会根据 IEEE 802.3ad 标准使用活动组中的所有网络接口。
特点:
802.3ad模式是IEEE标准,因此所有实现了802.3ad的对端都可以很好的互操作。802.3ad 协议包括聚合的自动配置,因此只需要很少的对交换机的手动配置(要指出的是,只有某些设备才能使用802.3ad)。802.3ad标准也要求帧按顺序(一定程度上)传递,因此通常单个连接不会看到包的乱序。802.3ad也有些缺点:标准要求所有设备在聚合操作时,要在同样的速率和双工模式,而且,和除了balance-rr模式外的其它bonding负载均衡模式一样,任何连接都不能使用多于一个接口的带宽。
此外,linux bonding的802.3ad实现通过对端来分发流量(通过MAC地址的XOR值),因此在“网关”型配置下,所有外出(Outgoing)流量将使用同一个设备。进入(Incoming)的流量也可能在同一个设备上终止,这依赖于对端802.3ad实现里的均衡策略。在“本地”型配置下,路两将通过 bond里的设备进行分发。
band4是要求参与绑定的端口都运行802.3ad协议。该方式与band0很相似,但是又有区别。在IEEE802.3ad中,“链路聚合控制协议(LACP)”自动通知交换机应该聚合哪些端口,IEEE802.3ad聚合配置之后,链路聚合控制协议单元(LACPDU)就会在服务器和交换机之间进行交换,LACP会通知交换机在聚合中配置的适配器应作为交换机上的一个适配器来考虑,而不再有用户的干预。(按照协议应当如此,但是H3C5500-EI交换机上并未发现有单独启用802.3ad或LACP的命令,而聚合组中的静态聚合的所有端口均不启用LACP协议,所以如果按照band4的模式操作的话,建议在交换机上手工做动态端口聚合,且手工指定全局报文按照源MAC和目的MAC地址进行聚合负载分担。)根据IEEE802.3ad的规范,前往相同IP地址的数据包都会通过相同的适配器进行发送。因此当在802.3ad方式下操作时,信息包会始终按照标准(standard)的方式进行分发,而不会按照轮询(Round-Robin)方式进行分发。
交换机端配置:
interface AggregatePort 1 配置聚合口 interface GigabitEthernet 0/23 port-group 1 mode active 接口下开启lacp 主动模式 interface GigabitEthernet 0/24 port-group 1 mode active
必要条件:
条件1:ethtool支持获取每个slave的速率和双工设定
条件2:switch(交换机)支持IEEE 802.3ad Dynamic link aggregation
条件3:大多数switch(交换机)需要经过特定配置才能支持802.3ad模式
模式 5(adaptive transmit load balancing policy)(适配器传输负载均衡)
模式 5 保证所有出站的网络流量会根据每个接口的负载进行分配,而所有入站的网络流量都被当前的接口所接收。如果用来接收网络流量的接口出现故障,另外一个网络接口会被指定来接收网络流量。因为模式 5 不能和网桥一起使用,所以它与虚拟机网络不兼容。
特点:
balance-tlb模式通过对端均衡外出(outgoing)流量。既然它是根据MAC地址进行均衡,在“网关”型配置(如上文所述)下,该模式会通过单个设备来发送所有流量,然而,在“本地”型网络配置下,该模式以相对智能的方式(不是balance-xor或802.3ad模式里提及的XOR方式)来均衡多个本地网络对端,因此那些数字不幸的MAC地址(比如XOR得到同样值)不会聚集到同一个接口上。
不像802.3ad,该模式的接口可以有不同的速率,而且不需要特别的交换机配置。不利的一面在于,该模式下所有进入的(incoming)流量会到达同一个接口;该模式要求slave接口的网络设备驱动有某种ethtool支持;而且ARP监控不可用。
模式 6(adaptive load balancing policy)(适配器适应性负载均衡)
Mode 5 的功能再加上不需要特殊的网络交换要求的 IPv4 网络数据接收负载均衡功能。它在处理接收负载时使用 ARP。因为模式 6 不能与网桥一起使用,所以它与虚拟机逻辑网络不兼容。
特点:
该模式包含了balance-tlb模式,同时加上针对IPV4流量的接收负载均衡(receive load balance, rlb),而且不需要任何switch(交换机)的支持。接收负载均衡是通过ARP协商实现的。bonding驱动截获本机发送的ARP应答,并把源硬件地址改写为bond中某个slave的唯一硬件地址,从而使得不同的对端使用不同的硬件地址进行通信。所有端口都会收到对端的arp请求报文,回复arp回时,bond驱动模块会截获所发的arp回复报文,根据算法算到相应端口,这时会把arp回复报文的源mac,send源mac都改成相应端口mac。从抓包情况分析回复报文是第一个从端口1发,第二个从端口2发。以此类推。
(还有一个点:每个端口除发送本端口回复的报文,也同样会发送其他端口回复的报文,mac还是其他端口的mac)这样来自服务器端的接收流量也会被均衡。
当本机发送ARP请求时,bonding驱动把对端的IP信息从ARP包中复制并保存下来。当ARP应答从对端到达时,bonding驱动把它的硬件地址提取出来,并发起一个ARP应答给bond中的某个slave(这个算法和上面一样,比如算到1口,就给发送arp请求,1回复时mac用1的mac)。使用ARP协商进行负载均衡的一个问题是:每次广播 ARP请求时都会使用bond的硬件地址,因此对端学习到这个硬件地址后,接收流量将会全部流向当前的slave。这个问题通过给所有的对端发送更新(ARP应答)来解决,往所有端口发送应答,应答中包含他们独一无二的硬件地址,从而导致流量重新分布。当新的slave加入到bond中时,或者某个未激活的slave重新激活时,接收流量也要重新分布。接收的负载被顺序地分布(round robin)在bond中最高速的slave上。
当某个链路被重新接上,或者一个新的slave加入到bond中,接收流量在所有当前激活的slave中全部重新分配,通过使用指定的MAC地址给每个 client发起ARP应答。下面介绍的updelay参数必须被设置为某个大于等于switch(交换机)转发延时的值,从而保证发往对端的ARP应答不会被switch(交换机)阻截。
当集群的机器数量较少,或者机器跨VLAN或者经过路由时,模式6就起不到很好的效果。mod=6与mod=0的区别:mod=6,先把eth0流量占满,再占eth1,....ethX;而mod=0的话,会发现2个口的流量都很稳定,基本一样的带宽。而mod=6,会发现第一个口流量很高,第2个口只占了小部分流量。
必要条件:
条件1:ethtool支持获取每个slave的速率;
条件2:底层驱动支持设置某个设备的硬件地址,从而使得总是有个slave(curr_active_slave)使用bond的硬件地址,同时保证每个bond 中的slave都有一个唯一的硬件地址。如果curr_active_slave出故障,它的硬件地址将会被新选出来的 curr_active_slave接管。