【IT168 专稿】最近公司正在进行EMC DMX-3的测试，在测试过程中发生了很多有意思的事情，以后笔者会跟大家分享更多的测试细节。就在前不久，笔者和EMC工程师一起解决了一个DMX3前端口通讯故障的问题。问题本身有一定的偶然性，问题的解决也出人意料，不过解决的过程相信对大家还是有一定帮助，因此写下来与大家一起分享。
问题发生，DMX3前端口速度大失水准
问题发生在测试的EMC DMX3安装完成之后，本来安装完机器后进行端口速度测试是例行公事了，但是测试的结果却和我们的期望大相径庭，DMX-3每通道I/O速度出奇的慢，每秒不到10M，这可绝对不是DMX-3应有的速度啊？一定是什么地方出现了问题！
问题发生在测试的EMC DMX3安装完成之后，本来安装完机器后进行端口速度测试是例行公事了，但是测试的结果却和我们的期望大相径庭，DMX-3每通道I/O速度出奇的慢，每秒不到10M，这可绝对不是DMX-3应有的速度啊？一定是什么地方出现了问题！
原来，我们一般用DD命令进行连续写的速度测试，命令如下，其中rlv_test是裸设备：
#time dd if=/dev/zero of=/dev/rlv_test bs=1024k count=10000
#time dd if=/dev/zero of=/dev/rlv_test bs=1024k count=10000
这时候，通过powermt watch的观测结果如下：
四条通道I/O不正常
从上面的观测结果我们可以发现，fscsi0到fscsi3一共4个通道，每个通道每秒的IO个数才8个，写速度每秒钟不到10M。
到底什么原因让DMX3的端口速度大失水准？这下又把我的好奇心勾引起来了，下决心好好查找一下故障的原因。为了稳妥起见，解决问题的首要还是要求助厂家。一个电话打到EMC支持中心，将故障问题报上去以后，EMC工程师赶到了现场。
EMC的几个哥们儿也是通过dd命令到文件系统，做了一个类似的测试，如
#time dd if=/dev/zero of=/u01/test.dat bs=1024k count=10000
#time dd if=/dev/zero of=/u01/test.dat bs=1024k count=10000
这时通过powermt watch的观测结果如下：
fcs0链路I/O不正常
大家可以看见上面的测试结果显示出fscsi0连接的链路1，才8个IO的时候，队列中就有一个等待，做文件系统测试的时候，就基本没有IO。这时候，EMC哥们儿判断：多半是其中一个链路有问题。
这里可以看到 EMC的工程师不愧是厂商级别的工程师，没有把问题定位在文件系统与裸设备的差别上，甚至都不怀疑裸设备的硬件问题，而是直接定位到了链路上面。从后面的操作看来，这个判断还是非常准确的，但我们决定通过进一步操作证实故障判断。
锁定故障链路，fcs0是害群之马
我们一起查看了这台主机连接到存储的拓扑结构图，如下：
与fcs0链接的主机端口和交换机端口
从上面的列表中看到，有问题的链路fcs0，通过光纤交换机的25/24 port，连接到存储的8b0前端口，对症下药，我们登陆到该交换机，disable这个通道：“admin>portdisable 25”，这下fcs0故障链路应该被屏蔽掉了，我们又作了个速度测试，发现一切正常，故障果然就是出在链路fcs0上。。。。
其余三个端口通讯正常
至于为什么4个通道不正常，三个通道为什么反而正常了呢？这里还与EMC的负载均衡软件powerpath的分配策略有关系：
原来，powerpath是用于增强存储环境中开放系统的运行性能的软件，主要作用就是智能分配并均衡多个通路的I/O负载，消除I/O通路中的单点故障。powerpath尽量让每个通道的IO均衡，结果，因为fcs0的IO上不去，所以就连累了其他三条链路，把大家的速度都拖慢了。
找到了问题不代表解决了问题。我们接着一起来到机房，开始试着锁定故障关键点：
我们把光纤交换机上的25/24口换到15/14口，问题依旧，判断光纤交换机没有问题
我们把主机fcs0连接到光纤交换机的光纤线换掉，问题依旧，判断主机端的光纤线没有问题
我们把存储8b0连接到光纤交换机的光纤线换掉，问题依旧，判断存储端的光纤线没有问题
现在就只剩下主机fcs0的HBA卡，和存储前端口fa-8b0没有被骚扰过了。
这时，一个EMC的工程师甚至直接建议我找IBM换fcs0的光纤卡，自信满满的说他们的前端口基本不可能坏的。然而，后面的测试就表明，看似不可能出现问题的地方，往往就出现了问题。。。。
