問題發生，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的工程師還一直堅持加班解決問題，相比有些廠商總是喜歡把問題推到別人身上要強多了。但是，也是因為先前的安裝工程師沒有把所有的線都配置完成，給我們后續的工作埋下了隱藏的故障，讓我們在后續的配置過程中耗費了不少的時間。估計是因為那根線是備用線，覺得通不通關系不大，結果導致了問題的出現。
這個故事就告訴我們，在實際的運營與操作過程中，什么樣的故障都可能出現，所以，解決問題的過程中，思路一定要開闊，看似最不可能發生故障的地方，往往就是故障的關鍵所在。
