分享

案例探索 | 千兆/万兆网卡每秒转发包数处理能力上限到底有多大?

 nanatsg 2018-03-27

“侦破”网卡传输能力的“个”案


作者:李烨楠

一个平静的下午,在某监控大厅,应急召集令发出,一时间应急电话、汇报、询问声音响成一片。这是怎么了?原来某重要+系统应用交易严重超时,业务产生大量积压,无法顺利进行。

一、问题到底出在哪里?

系统架构简单明了:后台为Oracle RAC DB数据库,前台为12台AP,AP连接到DB做业务。而业务处理响应缓慢的情况发生在所有的AP上,因此焦点集中到DB服务器、网络、存储等共用的资源及设备上。

经过各方的共同排查,存储正常、数据库正常,却发现DB与AP的网络通信存在问题,ping延时严重,AP与DB、DB与DB之间的ping延时达到十几毫秒并且一直持续(正常时的ping延时只有0.3毫秒左右)。 于是,网络与系统开始协同检查抓包,发现网络链路上未见异常,十几毫秒的延时都消耗在DB主机的响应时间上,系统上可见所有资源均正常,网卡流量远未达到瓶颈,只有网卡收发包数一直较大。

二、抽丝剥茧的分析,提出解决方案

到底是什么具体问题呢?让我们先来看看问题主机的环境:Power780物理机,生产、带管、心跳网卡均为etherchannel绑定的网卡,使用的是两块千兆网卡,由于为主备模式,实际只有一块网卡处于工作状态。

根据之前我们在PowerVM虚拟化环境应急的经验,怀疑是单块千兆网卡转发包数的处理能力达到了瓶颈。通过AIX的topas、nmon等工具都可以很方便的监控每秒网卡的接收及发送数据包数,查询结果如下:

其中的I-pkts和O-pkts即是。一提到网卡,我们通常第一想到的就是带宽处理能力,像千兆、万兆、全双工等等指标更多展示的就是带宽有多大,但很少有人关心网卡的包处理能力上限在哪儿,到底是每秒1万、10万还是100万。为什么呢?因为极少有人会遇到包数转发处理能力的瓶颈,这种情况只出现在业务压力非常大、平均网络包size非常小的系统上,否则通常包数还没达到瓶颈呢,带宽已经满了,但是这种系统恰恰被我们碰上了!而且不止一次!

发生问题的DB主机,当时单块千兆网卡的收发包总数达到了15万左右,并且现象持续存在,一直到应用进行了流控之后,ping延时才得到了缓解,业务才逐渐恢复,这会是问题的症结么?

我们据此提出了紧急的解决方案:

扩容网卡的包处理能力!一块处理不过来就增加多块,紧急改变网卡的绑定模式,改为load balance,并使并发的网卡达到三块。

问题解决:

之后业务高峰再到来后,三块网卡并发处理,收发包总数峰值达到了22万,可见之前的瓶颈限制了总转发处理能力从而造成了积压。调整之后一通百通, ping延时的现象也不复存在了。

三、小马过河的测试

千兆网卡、万兆网卡的每秒转发包数处理能力上限到底有多大的问题,引起了我们的思考,于是转而求助硬件厂商,希望得到有参考价值的技术指标,然而厂商也拿不出明确的包转发处理能力的相关指标,看来大家更关心的都是带宽处理能力。

这使我们想到了小马过河的故事,既然没有现成的指标给我们参考,我们就在自己的环境上测出一个相对可信的处理能力上限,求人不如求己。

根据我们在准生产环境上的压力测试,结论如下:

1、对于物理机:

1)千兆网卡单卡单向包的数量极限大约为每秒8 万个,收发一致,也就是说收发总处理能力上限为每秒16万左右。

2)万兆网卡单卡单向包的数量极限大约为每秒19万个,收发一致,也就是说收发总处理能力上限为每秒38万左右。

2、对于PowerVM虚拟化主机:

由于做了网卡的虚拟化,由hypervisor虚拟化层负责虚拟网卡的转发处理等,网卡的包转发处理能力较物理机有较大的损失。

两块万兆网卡做load balance绑定后提供给VIOS做成虚拟网卡映射给VIOC使用,当网卡每秒收发包总数超过10万时即可能对网络的转发造成瓶颈从而影响业务处理。

这部分内容属于少有人关注的性能瓶颈,我们通过对这个事件的处理、应急以及在这之后做的各种测试,将测试数据和总结的经验分享给大家!


扩展阅读:


Linux下多网卡绑定模式详解


作者:杜鑫

在我们日常Linux使用中,一般对于生产网都会使用双网卡或多网卡接入,这样既能添加网络带宽,同时又能做相应的冗余,可谓好处多多。而一般我们都会使用Linux操作系统下自带的网卡绑定模式。这一点不像Windows2008,操作系统没有网卡绑定功能,需要网卡产商针对windows操作系统定制网卡管理软件来做网卡绑定(windows2012操作系统中加入了网卡绑定功能)。

下面,我们来详细了解一下Linux网卡绑定的相关内容。

一、 网卡绑定的基本原理

多网卡绑定一方面能够提高网络吞吐量,另一方面也可以增强网络高可用。

从软件的角度来看,多网卡绑定实际上只需要提供一个额外的bond驱动程序即可,通过该虚拟网卡驱动程序可以将实际多块网卡屏蔽,对TCP/IP协议层而言只存在一个Bond网卡。

二、 Linux网卡绑定七种模式详解

Linux网卡绑定共七种模式,分别是如下模式:

- mode=0 round-robin轮询策略(Round-robin policy)

- mode=1 active-backup主备策略(Active-backup policy)

- mode=2 load balancing (xor)异或策略(XOR policy)

- mode=3 fault-tolerance (broadcast)广播策略(Broadcast policy)

- mode=4 lacp IEEE 802.3ad 动态链路聚合(IEEE 802.3ad Dynamic link aggregation)

- mode=5 transmit load balancing适配器传输负载均衡(Adaptive transmit load balancing) 

- mode=6 adaptive load balancing适配器负载均衡(Adaptive load balancing)

接下来,我们一一来看每种模式的含义。

1. round-robin轮询策略

cat /proc/net/bonding/bond0
Bonding Mode: load balancing (round-robin)

该模式下,链路处于负载均衡状态,数据以轮询方式向每条链路发送报文,基于per packet方式发送。即每条链路各一个数据包。这模式好处在于增加了带宽,同时支持容错能力,当有链路出问题,会把流量切换到正常的链路上。该模式下,交换机端需要配置聚合口,在cisco交换机上叫port channel

2.active-backup主备策略

该模式拓扑图与上图相同

cat /proc/net/bonding/bond0
Bonding Mode: fault-tolerance (active-backup) 

在该模式下,一个端口处于主状态,一个处于备状态,所有流量都在主链路上发出和接收,备链路不会有任何流量。当主端口down掉时,备端口接管主状态。同时可以设置primary网卡,若primary网卡出现故障,切换至备网卡,primary网卡回复后,流量自动回切。这种模式接入不需要交换机端支持。

3.load balancing (xor)异或策略

该模式拓扑图与上图相同

cat /proc/net/bonding/bond0
Bonding Mode: load balancing (xor) 

在该模式下,通过源和目标mac做hash因子来做xor算法来选择链路,这样就使得到达特定对端的流量总是从同一个接口上发出。和balance-rr一样,交换机端口需要能配置为“port channel”。

值得注意的是,若选择这种模式,如果所有流量源和目标mac都固定了,例如使用“网关模式”,即所有对外的数据传输均固定走一个网关,那么根据该模式的描述,分发算法算出的线路就一直是同一条,另外一条链路不会有任何数据流,那么这种模式就没有多少意义了。

4.fault-tolerance (broadcast)广播策略

cat /proc/net/bonding/bond0
Bonding Mode: fault-tolerance (broadcast)

这种模式的特点是一个报文会复制两份往bond下的两个接口分别发送出去。当有对端交换机失效,我们感觉不到任何丢包。这个模式也需要交换机配置聚合口。

拓扑图如下所示:

当一条链路出现故障是不会影响服务器另一条链路正常工作的。而且故障过程是0丢包。下面展示了这种模式下ping信息:

从这个ping信息可以看到,这种模式的特点是,同一个报文服务器会复制两份分别往两条线路发送,导致回复两份重复报文,虽然这种模式不能起到增加网络带宽的效果,反而给网络增加负担,但对于一些需要高可用的环境下,例如RAC的心跳网络,还是有一定价值的。

5.lacp IEEE 802.3ad 动态链路聚合

该模式拓扑结构与主备模式相同

cat /proc/net/bonding/bond0
Bonding Mode: IEEE 802.3ad Dynamic link aggregation

该模式是基于IEEE 802.3ad Dynamic link aggregation(动态链接聚合)协议,针对该协议的介绍,在公众号之前的文章中有所涉及。

在该模式下,操作系统和交换机都会创建一个聚合组,在同一聚合组下的网口共享同样的速率和双工设定。操作系统根据802.3ad 协议将多个slave 网卡绑定在一个聚合组下。聚合组向外发送数据选择哪一块儿网卡是基于传输hash 策略,该策略可以通过xmit_hash_policy 选项从缺省的XOR 策略改变到其他策略。

该模式的必要条件:

- ethtool 支持获取每个slave 的速率和双工设定;

- 交换机支持IEEE 802.3ad Dynamic link aggregation。

大多数交换机需要经过特定配置才能支持802.3ad 模式。

6.transmit load balancing适配器传输负载均衡

cat /proc/net/bonding/bond0
Bonding Mode: transmit load balancing

这种模式相较load balancing (xor)异或策略及LACP模式的hash策略相对智能,会主动根据对端的MAC地址上的流量,智能的分配流量从哪个网卡发出。但不足之处在于,仍使用一块网卡接收数据。存在的问题与load balancing (xor)也是一样的一样,如果对端MAC地址是唯一的,那么策略就会失效。这个模式下bond成员使用各自的mac,而不是上面几种模式是使用bond0接口的mac。无需交换机支持

该模式拓扑图如下:

7.adaptive load balancing适配器负载均衡

该模式拓扑结构与上图一致。

cat /proc/net/bonding/bond0
Bonding Mode: adaptive load balancing

该模式除了balance-tlb适配器传输负载均衡模式的功能外,同时加上针对IPV4流量接收的负载均衡。接收负载均衡是通过ARP协商实现的。在进行ARP协商的过程中,bond模块将对端和本地的mac地址进行绑定,这样从同一端发出的数据,在本地也会一直使用同一块网卡来接收。若是网络上发出的广播包,则由不同网卡轮询的方式来进行接收。通过这种方式实现了接收的负载均衡。该模式同样无需交换机支持。

三、小结

在网卡绑定的七种模式下,其中mode=0、2、3、4需要交换机支持,mode=1、5、6不需要交换机配置支持。

    本站是提供个人知识管理的网络存储空间,所有内容均由用户发布,不代表本站观点。请注意甄别内容中的联系方式、诱导购买等信息,谨防诈骗。如发现有害或侵权内容,请点击一键举报。
    转藏 分享 献花(0

    0条评论

    发表

    请遵守用户 评论公约

    类似文章 更多