问题发生，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的观测结果如下：
![""]("http://image.it168.com/cms/2007-6-26/Image/2007626101349.jpg")
四条通道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的观测结果如下：
![""]("http://image.it168.com/cms/2007-6-26/Image/2007626101554.jpg")
fcs0链路I/O不正常
大家可以看见上面的测试结果显示出fscsi0连接的链路1，才8个IO的时候，队列中就有一个等待，做文件系统测试的时候，就基本没有IO。这时候，EMC哥们儿判断：多半是其中一个链路有问题。
这里可以看到 EMC的工程师不愧是厂商级别的工程师，没有把问题定位在文件系统与裸设备的差别上，甚至都不怀疑裸设备的硬件问题，而是直接定位到了链路上面。从后面的操作看来，这个判断还是非常准确的，但我们决定通过进一步操作证实故障判断。
锁定故障链路，fcs0是害群之马
我们一起查看了这台主机连接到存储的拓扑结构图，如下：
![""]("http://image.it168.com/cms/2007-6-26/Image/200762610197.jpg")
与fcs0链接的主机端口和交换机端口
从上面的列表中看到，有问题的链路fcs0，通过光纤交换机的25/24 port，连接到存储的8b0前端口，对症下药，我们登陆到该交换机，disable这个通道：“admin>portdisable 25”，这下fcs0故障链路应该被屏蔽掉了，我们又作了个速度测试，发现一切正常，故障果然就是出在链路fcs0上。。。。
![""]("http://image.it168.com/cms/2007-6-26/Image/2007626102033.jpg")
其余三个端口通讯正常
至于为什么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，新的拓扑结构如下：
![""]("http://image.it168.com/cms/2007-6-26/Image/2007626102855.jpg")
fcs1同时与主机7b0与8b0链接
当时我们认为，如果这样速度还有问题的话，基本就可以判断是EMC前端口8b0有问题，而反之，则可以排除DMX3前端口8b0的嫌疑了。测试结果发现，速度依然还是上不去，这下，我们只好断定问题就出在EMC的前端口上了。但是这样一来，又出现了新的矛盾。。。。
事实上，这个端口还可以使用，不过是速度慢。而且EMC的哥们儿联系了他们公司的硬件工程师，远程登陆进来察看却没有发现任何硬件错误信息，而我们这边看到的结果也没有报任何错误。同时我们的测试又的确反映了问题就是出在前端口上，如果不是8b0前端口的问题，那问题究竟藏在哪里呢？
测试结果出来以后，EMC的哥们儿不再坚持他的看法，开始申请硬件配件，也就是前端卡，同时一边做测试，继续寻找故障原因，因为他们仍然不相信他们的前端卡会有问题。其实，通过我们后来的一系列测试看来，他们的看法还是正确的，的确不是硬件的问题。
好在这次是因为测试机器，所以我们有充裕的时间来慢慢研究。2天后，EMC的备件到场，这次来了一个硬件工程师，在机房负责检查硬件以及随时更换硬件，另外一个软件工程师在公司，与我一起做检测。
我们把测试环境改成单个链路，也就是主机上的fcs1端口（确定是正常的光纤卡）连接存储DMX-3的8b0端口（怀疑有问题的前端口），如：
![""]("http://image.it168.com/cms/2007-6-26/Image/2007626103119.jpg"){kind=small}
用DD测试的结果还是不行；
![""]("http://image.it168.com/cms/2007-6-26/Image/2007626103140.jpg")
我们用fcs1连接7b0
![""]("http://image.it168.com/cms/2007-6-26/Image/2007626103215.jpg"){kind=small}
DD的结果一切正常：
![""]("http://image.it168.com/cms/2007-6-26/Image/2007626103231.jpg")
看来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的工程师还一直坚持加班解决问题，相比有些厂商总是喜欢把问题推到别人身上要强多了。但是，也是因为先前的安装工程师没有把所有的线都配置完成，给我们后续的工作埋下了隐藏的故障，让我们在后续的配置过程中耗费了不少的时间。估计是因为那根线是备用线，觉得通不通关系不大，结果导致了问题的出现。
这个故事就告诉我们，在实际的运营与操作过程中，什么样的故障都可能出现，所以，解决问题的过程中，思路一定要开阔，看似最不可能发生故障的地方，往往就是故障的关键所在。
