没有不可能的故障，EMC DMX3前端口测试纪实_中国IT运维网www.cnitom.com

最近公司正在进行EMC DMX-3的测试，在测试过程中发生了很多有意思的事情，以后笔者会跟大家分享更多的测试细节。就在前不久，笔者和EMC工程师一起解决了一个DMX3前端口通讯故障的问题。问题本身有一定的偶然性，问题的解决也出人意料，不过解决的过程相信对大家还是有一定帮助，因此写下来与大家一起分享。

问题发生，DMX3前端口速度大失水准
问题发生在测试的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

这时候，通过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

这时通过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的光纤卡，自信满满的说他们的前端口基本不可能坏的。然而，后面的测试就表明，看似不可能出现问题的地方，往往就出现了问题。。。。

不可能发生的前端口故障？

本着深入钻研的精神，我们一定要找到到底谁有问题，于是我们把fcs0从通道中去掉，把fcs1接到7b0与8b0，新的拓扑结构如下：

fcs1同时与主机7b0与8b0链接

当时我们认为，如果这样速度还有问题的话，基本就可以判断是EMC前端口8b0有问题，而反之，则可以排除DMX3前端口8b0的嫌疑了。测试结果发现，速度依然还是上不去，这下，我们只好断定问题就出在EMC的前端口上了。但是这样一来，又出现了新的矛盾。。。。

事实上，这个端口还可以使用，不过是速度慢。而且EMC的哥们儿联系了他们公司的硬件工程师，远程登陆进来察看却没有发现任何硬件错误信息，而我们这边看到的结果也没有报任何错误。同时我们的测试又的确反映了问题就是出在前端口上，如果不是8b0前端口的问题，那问题究竟藏在哪里呢？

测试结果出来以后，EMC的哥们儿不再坚持他的看法，开始申请硬件配件，也就是前端卡，同时一边做测试，继续寻找故障原因，因为他们仍然不相信他们的前端卡会有问题。其实，通过我们后来的一系列测试看来，他们的看法还是正确的，的确不是硬件的问题。

好在这次是因为测试机器，所以我们有充裕的时间来慢慢研究。2天后，EMC的备件到场，这次来了一个硬件工程师，在机房负责检查硬件以及随时更换硬件，另外一个软件工程师在公司，与我一起做检测。

我们把测试环境改成单个链路，也就是主机上的fcs1端口（确定是正常的光纤卡）连接存储DMX-3的8b0端口（怀疑有问题的前端口），如：

用DD测试的结果还是不行；

我们用fcs1连接7b0

DD的结果一切正常：

看来8b0端口的问题依然存在，我们只好下决心开始更换硬件。

离奇的故障原因
硬件工程师先换了8b0的前段口，问题依旧

硬件工程师更换了8b0的所在的板卡，但是不包括cpu模块，问题依旧

硬件工程师更换了整个前端板卡，包括cpu模块，问题依旧

这下我们全部都傻眼了。其实，在更换整个前端板卡前，EMC的那个软件工程师就说过：他们最担心的问题就是更换了硬件之后，问题依然存在，因为硬件看起来确实是没有问题的。他说完这句话，我也隐约感到不妙。果然更换了前端卡问题依然没有解决，我们都晕了，问题在哪里？看起来前端卡并没有问题。

这下我们还有最后一根救命稻草：开case向EMC总部求助。工程师开case的速度还是非常快的，但是case必须要等到老美上班才能有响应，而老美上班一般都是晚上12点以后了。我于是先回家了，EMC工程师继续加班。第二天上班，EMC软件工程师也过来了，回答是，老美确认硬件没有问题，把问题丢给了操作系统，认为操作系统不兼容。

但是，连接这个存储的有多台主机，且都采用了同一版本的操作系统，为什么只有这一个主机这一个端口出现这个问题呢？不过既然老美这样说了，我决定让EMC工程师把这个8b0连接到另外一个主机上做测试。也就是拿另外一个主机的fcs1与8b0连接，把这个DMX3的硬盘认到另外一个主机上。

这时，EMC的工程师告诉我，他本来想测试一下跟8b0相同CPU接口的8b1，但是光纤交换机上没有显示8b1在线。这下，我心里仿佛开了一个小窗，一丝亮光透了进来。fa-8b1我们是接了光纤线的啊，虽然仅仅是一根备用线并没有在使用状态，但是系统上也应该显示fa-8b1的状态啊？我再次检查了一下交换机的连接信息，确认fa-8b1没有连接进来，而其它的端口都是正常的。

原来，这个光纤连接是前几天另外一个EMC安装工程师做的，但是我还没有来的及在交换机上做检测。难道当时那个工程师还没有把这跟线配通？难道这个线有故障？我隐约觉得这里肯定有蹊跷，但是也仅仅只是模模糊糊的预感。

我打电话给机房的一个管理员，让他更换一根连接8b1到光纤交换机的光纤线，与此同时，EMC的工程师也把8b0端口与另外一台主机连接上了，开始测试，正常。。。。

再把8b0端口挂回最初出错的主机端口，测试，正常。。。。

这样已经可以基本排除操作系统的问题了，问题极有可能就是那根8b1的光纤线，我通知机房管理员干脆把这根线拔了，再测试，一切正常。。。。

后记：没有不可能的故障

问题居然就这么解决了，我们也晕了。现在可以判断，问题就是出在那个出问题的光纤线上。虽然这个光纤线没有在使用，而且光纤交换机上也看不到这个线是通的，但是他就是能影响到我们，至于是如何影响到的，我也说不太清楚，只是凭着以往操作的经验和直觉解决的问题。

事后我也认真想了想，估计那根出问题的光纤线，很有可能它本身有故障，所以虽然谁都没有使用他，却导致了DMX的8b1一直在试着跟它通讯，这样就耗费了8b1端口的cpu。而8b1与8b0使用同一个cpu的，所以，8b0性能怎么也上不去，因为cpu被消耗了。不过这也仅仅是我的猜测，要知道机器内部究竟发生了什么事情，只能去问那些不会说话的冰冷的板卡和CPU了。。。

这个Case终于解决了，从这个case看来，EMC工程师解决问题的方式与速度还是不错的。在我们回家的时候，EMC的工程师还一直坚持加班解决问题，相比有些厂商总是喜欢把问题推到别人身上要强多了。但是，也是因为先前的安装工程师没有把所有的线都配置完成，给我们后续的工作埋下了隐藏的故障，让我们在后续的配置过程中耗费了不少的时间。估计是因为那根线是备用线，觉得通不通关系不大，结果导致了问题的出现。

这个故事就告诉我们，在实际的运营与操作过程中，什么样的故障都可能出现，所以，解决问题的过程中，思路一定要开阔，看似最不可能发生故障的地方，往往就是故障的关键所在。