/ 中存储网

EMC Data Domain网络性能调优案例

2012-08-28 17:52:00 来源:博客

网络分析真有这么神奇?抓个包就能看到服务器,客户机甚至网络设备的性能瓶颈?事实的确如此,而且不仅能解决性能问题,连Kerberos验证出错,NFS挂载失败,NDMP备份中断等棘手问题都能够找出原因。更重要的是,无论你从事哪个行业,只要涉及网络,抓包分析都非常有用。上篇文章介绍的Isilon案例还属于NAS范畴,算是阿满的主业。今天要分享的是DataDomain的案例,这是以前从来没接触过的领域。

来找我的还是上篇文章中那位要帮我搬家的老板(我下个月还要再搬家,这次一定要叫他扛家具)。问题大概是这样的。客户有好几台AIX往DataDomain读写数据。写性能很好,能超过100MB/s。但读性能特别差,在20MB/s以下。网络拓扑不明,但知道一个小细节:AIX的网卡是千兆的,而DataDomain用的是万兆卡:

从五角场打车到唐镇花了好长时间。我得以在路上分析这个问题的成因:

1.一般存储都是读比写快,DataDomain应该也不例外。当前现象是读比写慢得多,那这个问题的原因应该不在DataDomain上。

2.网络很值得怀疑。写操作时数据从1G网络流向10G网络,如同小河水流入大河,自然是非常通畅。读操作时数据从10G网络流向1G网络,如同大河水流入小河,很可能导致拥塞,从而带来严重的性能下降。

中午11点多,终于见到了客户的网络管理员。我们打开在DataDomain和AIX上分别抓到的网络包,看到很多类似下图(图里只显示从DataDomain到AIX的包,另一个方向的被过滤了)的现象:DataDomain发送一系列包给AIX,但是其中的一些包在路上丢了,没有到达AIX,如图中的Seq No.=0,从而导致重传。这说明之前在路上的猜测是正确的,根本原因是网络上的拥塞。要彻底解决这个问题,能够把AIX端的网络升级到10G。但是客户明确表示,路由器和交换机已经没法动了,只能从DataDomain和AIX的配置上想办法。

明知问题出在网络上,却要到服务器和客户端去解决问题。是不是很有头痛医脚的感觉?但的确是可行的:

1.把DataDomain的发送窗口强制定义成一个很小的值。就像大河里流的水很少,到了小河也不会漫出来。问题是我们不知道多小的发送窗口最合适,因为多台AIX与此同时在读写,拥塞点很不稳定。我们一般不采用这个方法。

2. 仔细分析上图,其实丢掉的包只有Seq No.=0(因为AIX收到了1460-8760),但实际上1460-8760也重传了(相当于增加了6倍的重传率)。这是因为发送方发现某个包丢失后,无法确定(该包之后的)其他包是否也丢了,只好选择全部重传。接收方虽然有这些信息,但是没有办法告诉发送方。其实RFC2018在1996年已经给出了解决方案,就是Selective Acknowledgment,简称SACK。在接收方和发送方都启用SACK的情况下,接受方能够告诉发送方“我没受到0,但是收到了1460-8760”。这样发送方只要重传Seq=0即可。在启用SACK的情况下,我们看到的情况应该如下图所示:

检查发现AIX上果然没有启用SACK,所以我们只需要运行“no -p -o sack=1”打开就行了。效果和我预测的一样,读性能立即飙升到100MB/s以上。客户连声说,“这样算很好了!”

在他们询问我的名字前,我已经关上车门,只留下一个伟岸的背影,深藏功与名。心里只有一个怨念:下次再借我去现场,能不能把项目利润的1/10分给我?!!