IT运维管理,创造商业价值!
中国IT运维网首页 | 资讯中心 | 运维管理 | 信息安全 | CIO视界 | 云计算 | 最佳案例 | 运维资源 | 专题策划 | 知识库 | 论坛

没有不可能的故障,EMC DMX3前端口测试纪实

2007年11月01日
IT168/佚名
最近公司正在进行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的工程师不愧是厂商级别的工程师,没有把问题定位在文件系统与裸设备的差别上,甚至都不怀疑裸设备的硬件问题,而是直接定位到了链路上面。从后面的操作看来,这个判断还是非常准确的,但我们决定通过进一步操作证实故障判断。

1

锁定故障链路,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端口的问题依然存在,我们只好下决心开始更换硬件。

1

离奇的故障原因
硬件工程师先换了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的光纤线,我通知机房管理员干脆把这根线拔了,再测试,一切正常。。。。

1

后记:没有不可能的故障

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

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

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

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

发表评论请到:http://bbs.cnitom.com

相关阅读

图文热点

大佬发话 Intel为超极本制定SSD新规范
大佬发话 Intel为超极本制定SSD新规范英特尔正在为 超极本 制定SSD新规范。英特尔目前正在寻求与PC厂商和NAND公司合作...
数据治理,不仅仅是技术问题
数据治理,不仅仅是技术问题毋庸置疑,数据已成为企业的重要资产,也是企业竞争力的重要武器。企业业务的成功...

本类热点