10G 网络升级(服务器端 bonding)

本次升级最大的"意外"之一就是关于服务器 bonding 的问题,归根到底还是在升级之前文档看的不够充分,调研的不够仔细。下面会对其做一个比较全面的分析。
说到 bonding,最重要的问题之一就是模式的选择,这个是要根据各自不同业务来选择的,切勿人云亦云,我整理了一份表格,说明每一种模式的一些特性以及交换机对其的支持情况。

选哪个模式最合适?很明显,正常情况下,mode4 是一个比较好的选择,但是需要注意的是端对端尤其是交换机 active/on 选择,对于服务器来说,稍微有点繁杂,需要根据网口的情况来分:

  • 四口的,如果有内外网,没有问题
  • 两口的,如果仅仅有内网或者公网,也没有问题
  • 两口的,如果既要有内网又要有公网,很明显,还缺少两个端口,这时候在 Linux 上做 VLAN  的价值就体现出来了

确认完模式,接下来就是 bonding 的安装,bonding 这个 module 默认应该都是随发型版本加载的,可以在 /etc/modprobe.d/ 目录下面加载;接下来就是修改网卡对应的配置了,各个不同的发型版本大同小异,这里分别给一个 Ubuntu 以及 RHEL 的范例。这两个主流发型版本的 bonding 的配置还是比较灵活的,除了可以在 /etc/modprobe.d/ 里面指定 bonding 的各种参数之外,还可以在 network-scripts/ 以及 interface 里面指定,比如可以在 ifcfg-bond0 里面指定 bonding opts:
# cat /etc/sysconfig/network-scripts/ifcfg-bond0
DEVICE=bond0

BONDING_OPTS="mode=4 miimon=100"

跟 bonding 有关的几个实时文件分别在 /proc/net/bonding/:
# cat /proc/net/bonding/bond0

以及 /sys/class/net/ 下面:
# cat /sys/class/net/bonding_masters
bond0

# cat /sys/class/net/bond0/bonding/mode
balance-alb 6

# cat /sys/class/net/bond0/address
99:11:11:11:dd:dd

要让 bonding 生效,我认为最 KISS 的办法还是直接重启机器,尽管可以通过 ifenslave 或者在加载完 bonding 之后直接在 /sys/(/sys/class/net/ 下面) 里面 "on the fly"。官方的建议是通过 iproute2(ip link set eth0 master bond0) 或者 sysfs 修改生效,ifenslave 会被逐渐抛弃。
在启动的时候,注意查看系统的 /var/log/messages,这个文件里面能看到很多跟 bonding 相关的信息。

对于 bonding 一对或者多对网卡的监控,可以二选一:
1. miimon
2. arp_interval 以及 arp_ip_target
不用任何监控的弊端之一就是一个网卡挂了无法及时的切换到另外一块网卡上,这个明显是不容许的。
对于 ARP 的监控方式,一般用在兼容 etherchannel 的模式里面,也就是交换机会将流量分散到多条链路上;如果是以 XOR 的方式(单条链路)则不可行。除此之外,ARP 的方式不可以跟 miimon 同时使用。
对于 miimon 来说,有 downdelay, updelay, user_carrier 几个参数比较重要。
如果想使用 balance-xor 或者 802.3ad,还需要了解下 xmit_hash_policy 以便更好的平衡流量。

既然是端到端的系统,除了要考虑服务器方面的 bonding 状态,也要考虑对端 FEX 的支持情况,在上篇已经说过,主流的 2k 跟 5k 的接法无外乎 single-homed 也就是一台 2k 仅连接一台 5k 或者是 dual-homed 也就是一台 2k 同时连接两台 5k。其中前者的 topo 支持 2k 的到服务器的 vPC、FCOE 以及 static pinning,而后者是不可以对 2k 下挂的服务器做 vPC,单凭这一点就没什么优势了,更何况这种接法还有其他不少的缺点。

这里有一篇文章提到遇到 Orphan Port 也就是单上联的情况,这个在实际情况中还时有发生,尤其是比较早期的服务器,那时候网口的数量还不足以达到双上联的标准,对于这类情况,文中分析在 peer link 参与的情况下流量的分布以及需要注意的地方,值得看看。

还有几个需要注意的地方:
1. 路由问题,原先由 eth0 单块网卡处理的现在将由 bond0 接替处理,如果是通过 ifensalve、modprobe 等方式启动的 bonding,注意也要修改对应的路由,重启不存在这类问题。
2. SNMP 问题,需要确保 bonding  这个模块在其他的网络模块之前加载,否则 SNMP 取得的数据会有错乱。
3. 在混杂(promiscuous) 模式下,balance-rr, balance-xor, broadcast 以及 802ad 这四种模式会将混杂模式的设定会传播到所有的 slave 接口;而 active-backup, balance-tlb 以及 balance-alb 这三种则只会传播到 active 的 slave 接口。
4. duplicated 包的问题,最常见的是在初次或者闲置一段时间之后 ping 某台机器的过程中发现不少 (DUP!) 表示的包,正常现象,主要在于交换机广播的机制,最简单的方式是清空一次 MAC 转发表,Nexus 上的示例:
# clear mac address-table dynamic


update: 服务器端的注意 xmit_hash_policy 这个参数,默认值为 layer2,也就是 mac 层的 hash,在某些业务下,会出现带宽跑不满,上不去的情况,可以考虑使用 xmit_has_policy=1(layer3+4) 的组合,这个还是要根据具体的业务来定。

  • ist0ne

    一台 2k 同时连接两台 5k(dual-homed )也是支持服务器做vPC的,通过EvPC支持。http://www.cisco.com/c/en/us/products/collateral/switches/nexus-2000-series-fabric-extenders/data_sheet_c78-507093.html,你文章中提到dual-homed 还有其他问题,是什么问题?
    Enhanced vPC (EvPC): In this deployment scenario, access-layer redundancy is achieved in two ways: through redundant connections between the Cisco Nexus 2000 Fabric Extenders and the Cisco Nexus parent switches using vPC, and through redundant server connections to two fabric extenders using vPC and active-active server NIC teaming. This scenario is supported only with the Cisco Nexus 5000 or 6000 Series Switches used as upstream switches. This scenario is not currently supported with the Cisco Nexus 7000 Series Switches.