- 論壇徽章:
- 0
|
修煉之路
最近在朋友的推薦下看了熱播劇集《prison break》，確實精彩，片中無處不在的細節(jié)讓人不得不佩服男主人公的schedule實在是做得完美。感慨之余想起到相關論壇上看看大家的評論，這才發(fā)現(xiàn)很多我捕捉到的細節(jié)和心領神會的method居然沒幾個人看懂了。不由得讓我憑空多了一層念想，是自己也能夠適應fox river那樣的牢獄生活，還是多年來AIX service的工作經(jīng)歷讓我已與往日不同。嘿嘿，我情愿相信是后者。
hacmp.棍子.靈異現(xiàn)象
hacmp是IBM在P系列服務器上使用的群集管理軟件，安裝配置很方便，在實際使用中可處理一些系統(tǒng)單點故障，從而提高整套系統(tǒng)的可用性。但是使用hacmp的環(huán)境也常常出現(xiàn)奇怪的現(xiàn)象，從而讓維護的技術人員頭疼不已,我們稱之為“靈異現(xiàn)象”……
2002年的夏天，湖南長沙，XX醫(yī)院，hacmp互備。
這個醫(yī)院的財務系統(tǒng)用的是IBM H85的雙機，hacmp互備模式，DB2數(shù)據(jù)庫，2臺機器分管住院部和門診部的財務系統(tǒng)。不知道從哪一天開始，這套系統(tǒng)也碰上了讓人頭疼的“靈異”。醫(yī)院的系統(tǒng)管理員說他們在正常使用中突然發(fā)現(xiàn)住院部的財務系統(tǒng)運行突然變慢了，經(jīng)檢查才發(fā)現(xiàn)住院部那臺機器已經(jīng)宕機，住院部業(yè)務已經(jīng)由門診部那臺順利接管，只不過由于系統(tǒng)資源緊張，所以才讓窗口的業(yè)務人員發(fā)現(xiàn)速度有異。接下來，系管重新開機，重新啟動hacmp，一套流程走下來，住院部主機重新?lián)撈鹆俗约旱娜蝿�，業(yè)務窗口速度也恢復了正常。
看上去一切都挺好，系統(tǒng)環(huán)境又恢復了正常，只不過……
三天以后，住院部主機又掛了。再來一次恢復流程，住院部主機起死回生……
三天以后，“掛”就一個字……
如此反復，這家醫(yī)院的系管已經(jīng)可以掐指算出住院部主機即將到來的“死亡時間”，誤差不超過3小時。在這家醫(yī)院信息部領導精神全面崩潰之前，他們找到了我所在的公司。
老板給我交代任務的時候，附帶告訴我在此之前已經(jīng)有資深的軟硬件工程師到現(xiàn)場全面檢查過了，每個人都是拍拍胸脯告訴可憐的系管自己這一塊絕對沒問題然后以盡可能快的速度離開了現(xiàn)場，留下系管一人絕望的面對即將到來的宕機時間……死亡無法避免。
說實話，這附帶信息對當時只有一年AIX經(jīng)驗的我來說不是什么很有用的消息，除了憑空多出許多壓力之外。
到了現(xiàn)場，我一直在想一個問題——系管的頭發(fā)是一直這么少，還是這段時間才發(fā)生了變化。問題沒有答案，我只希望能夠幫到這個可憐的同行，看上去他雖然很熱情，但是和遍訪名醫(yī)的重癥病人家屬一樣，眼神中已經(jīng)失去了“求生”的信念。
排除雜念，對著住院部的主機我砍出三板斧——df，errpt，diag。無效。一切看上去都很正常。細想想，這也正常，這三斧頭是個人就會砍。想必在我之前來的那些資深已經(jīng)都砍過三十幾斧頭了。再看看hacmp.out文件，頓時有了點不敢相信自己眼睛的感覺——已經(jīng)生成了近50MB的文本文件。原本想從里面找點信息的想法一瞬間也去了大洋對岸。難怪資深們都閃人了，我似乎有點明白了。
口中默念著高中班主任留給我的名人名言——“人啊！不能在一棵樹上吊死，讓我們一起來換棵樹吧！”——我殺向門診部主機。
系管有些驚訝，但還是盡量委婉的告訴我：“嚴工，這臺機器是好的”。
“知道”，回應：“我看看”
同樣無效的三斧頭過后，總算hacmp.out給了我一線希望，這臺機器的hacmp.out相比較而言還算正常，雖然也過分的達到了11MB的大小。
在“盡量”仔細的閱讀hacmp.out之后，我開始深刻理解資深們的難處了。巨量的事件腳本記錄給“閱讀”帶來了麻煩，2個小時的仔細閱讀之后，除了感覺眼睛有點疼，我暫時沒有別的新見解。
無奈中，我開始快速翻屏，現(xiàn)在回想起來，當時這么做可能是潛意識中的放棄。如《駭客帝國》中飛快滾動的黑底綠字由下而上的掠過屏幕，除了更加不可閱讀之外，似乎沒有別的什么好處了。
等等……這是什么……
由于快速翻屏和每個事件紀錄長度大致相等的2個重要因素，加上視覺暫留效應，我在屏幕上的特定位置看到了近乎穩(wěn)定的事件名稱fail_standby_adapter和join_standby_adapter。這兩個事件記錄名稱如此顯眼的出現(xiàn)在我面前，確實讓我精神為之一振。這樣的情況下我還能看到這兩個事件，只能說明這兩個事件出現(xiàn)的次數(shù)特別多。詳細檢查了這兩個事件發(fā)生的時間點，得到了讓我開始感覺興奮的消息——每秒鐘要發(fā)生4到5次的fail_standby和join_standby。這說明有塊standby的網(wǎng)卡不斷的退出和加入到standby狀態(tài)。順著思路往下想，如此高頻率發(fā)生的事件記錄除了要寫入本機的hacmp.out還要通過網(wǎng)絡寫入到另外節(jié)點的hacmp.out，這樣會直接導致另外節(jié)點的hacmp.out處于持續(xù)打開的狀態(tài)，同時也會占用相當大空間的file buffer且由于不斷的寫入而不會釋放。物理實存用完之后開始使用paging，加上業(yè)務壓力，paging用完之后，主機必死無疑。這樣一個內(nèi)存耗盡的過程，三天都算是撐得夠長了。
帶著激動的心情我檢查了不斷fail和join的standby網(wǎng)卡的物理位置——門診部主機的standby網(wǎng)卡，這就可以解釋為什么一旦住院部主機宕機，門診部主機可以接管住院部業(yè)務除了速度慢之外而不會再宕機。因為這個接管時間點之后，原門診部主機standby網(wǎng)卡已經(jīng)接管了住院部主機的service地址，當然也就不存在fail_standby和join_standby的事件發(fā)生了，取而代之的是住院部業(yè)務系統(tǒng)的service網(wǎng)卡有丟包——表現(xiàn)出來的現(xiàn)象就是住院部窗口業(yè)務運行慢。
因為做過diag沒有發(fā)現(xiàn)網(wǎng)卡損壞，所以問題發(fā)生的原因如果不是網(wǎng)線就是交換機端口。
等我告訴那個心灰意冷的人問題原因就在一根網(wǎng)線上時，你完全可以想象他當時的表情。而我當時腦海里出現(xiàn)的場景則是我父親當年用一根木棍就修好了我母親廠里的巨型空調(diào)并且贏得了她的芳心，他只是用棍子敲了敲那臺不肯工作的機器一切就恢復了正常。多年以后，我父親每每提起此事，總是得意地告訴我“關鍵不在用什么棍子，在于你要知道敲哪里”
微碼.警察.跑路
Oracle.球.世界杯
——————————————————
還沒寫完，，繼續(xù)中，，看到的朋友給點意見，謝謝了！
[ 本帖最后由 yanbing 于 2006-7-31 18:50 編輯 ] |
|
免費注冊
發(fā)表于 2006-07-20 02:20
