1. 程式人生 > >某虛擬化項目總結:一條光纖引發的故障

某虛擬化項目總結:一條光纖引發的故障

雲計算 虛擬化 光纖 VMware

摘要:在今年9月份的一個虛擬化項目中,項目前期一切正常。在為服務器添加、更換內存之後,出現ESXi主機存儲斷開、虛擬機系統慢、ESXi主機啟動慢的故障,經過多方檢查,終於排查了故障。最終故障的原因很簡單:ESXi主機與存儲的連接光纖出現問題導致了故障的產生。但整個項目過程中涉及到了更換內存、更換主板、升級固件等一系列事件,所以前期故障分析中沒有正確的定位故障點,導致事情越來越復雜。下面我把整個過程還原一次,希望此事對其他經常做項目的朋友有所幫助。

1 項目實施初期一切正常

這個項目比較簡單:2臺聯想3650 M5的主機(每主機配置1個CPU、128GB內存、單口8GB FC HBA接口卡)、1臺IBM V3500存儲,每臺主機安裝了VMware ESXi 6.0.0 U2的版本,有6個業務虛擬機、1個vCenter Server虛擬機用於管理。拓撲如圖1所示。

技術分享圖片

圖1 某單位虛擬化拓撲圖

在項目的初期,安裝配置ESXi主機、劃分IBM V3500存儲、創建虛擬機後,各個業務虛擬機對外提供服務,系統一切正常。在全部業務虛擬機正常運行兩天後,觀察到主機內存使用率超過60%接近70%時,我對客戶建議將每臺服務器的內存擴充到256GB,甲方技術主管在匯報領導後,同意了擴充內存的要求,但是就是在這個擴充內存,引起了後續一系列的故障。

說明:使用vSphere Client登錄vCenter Server,在左側導航器中選中群集,在右側“主機”選項卡中,可以看每個主機配置的內存、已經使用內存的百分比。圖2是每臺主機配置到256GB之後的截圖,當時128GB截圖沒有保存。這是項目正常之後的截圖,從圖中可以看出,系統中所有虛擬機使用內存大約170GB,在每臺主機只有128GB的情況下,使用內存是66%,在每臺主機擴充到256GB後,使用內存33%。

技術分享圖片

圖2 主機內存、CPU使用率

聯想3650 M5服務器,支持2個CPU,每個CPU有12個內存插槽,每個內存插槽最大支持單條64GB內存。故每個CPU最大支持64×12=768GB內存。

在這個項目中,每臺聯想3650 M5配置了8條16GB的內存,只剩余4個插槽(當前主機只配置了一個CPU),如果要擴充到256GB內存,可以再購買4條32GB或2條64GB內存,進行“混插”。但這樣客戶後期將不能繼續進行內存擴充,這樣不是好的升級方案。我給出的方案是,建議為每臺服務器配置4條64GB的內存,拆下的內存折舊或內存置換。聯系了長期為我們提供內存的公司,對方答應可以4條16GB換成1條64GB的內存,這樣對三方有利。

2 更換內存一波三折

8條64GB的內存到位之後,為每臺服務器更換內存。內存更換過程中,可以將所有虛擬機暫時遷移到另一臺主機,這樣業務不會中斷。

服務器安裝內存是有“講究”的,必須按照指定的位置進行安裝。每臺服務器的蓋板上都有內存的安裝順序,例如聯想3650 M5內存安裝順序如圖3所示。

技術分享圖片

圖3 聯想3650 M5內存安裝順序

即:單個CPU的內存安裝順序是1,4,9,12,2,5,8,11,3,6,7,10;雙CPU的安裝順序依次是1,13,4,16,9,21,12,24,2,14,5,17,8,20,11,23,3,15,6,18,7,19,10,22。例如當前主機安裝了8條16GB內存,則需要安裝在1,4,9,12,2,5,8,11位置。安裝之後,在開機之前可以在IMM中看到安裝的內存信息、內存是否正常,如圖4所示。

技術分享圖片

圖4 當前安裝了8條16GB內存截圖

但是,將4條64GB的內存插上之後,服務器開機無顯示,在IMM中也沒有檢測到內存,如圖5、圖6所示。

技術分享圖片

圖5 沒有檢測到內存

技術分享圖片

圖6 內存詳細信息、無內存

後來一條一條內存安裝,服務器也是檢測不到內存。沒有辦法,將原來的8條16GB內存插回主機。

聯系內存經銷商之後,更換了鎂光的單條64GB的內存,安裝成功(內存往返又是三、五天的時間),如圖7所示。說明,此次不能用的單條64GB內存,我在DELL R720XD主機上使用是沒有問題的。

技術分享圖片

圖7 檢測到4條64GB的主機

但是,關鍵問題是這個“但是”。在為第1臺主機順利的安裝更換了內存之後,為第2臺主機安裝內存的時候出了大問題。在插上這4條64GB內存之後,主機無法開機,在IMM檢測,提示系統出現嚴重故障(System Critical),如圖8所示。

技術分享圖片

圖8 System故障

經過聯系聯想的售後,工程師說主板壞了,這下我們就“暈”了,這服務器也太不“結實”了吧?沒辦法,只能等售後工程師上門更換主板了。

所幸我們離北京較近,售後第2天上門更換新的主板之後,故障依舊。這時大家都有點“糟”了。但是,還是工程師有經驗。工程師換上原來的16GB內存之後,服務器可以開機,一切正常。但換上這4條內存之後還是出現圖8的故障。之後工程師,采用一條一條安裝64GB內存,檢測到其中的一條有問題,後來安裝了3條64GB內存,如圖9所示。

技術分享圖片

圖9 當前安裝3條內存

這樣我們就更郁悶了,一條內存故障就能讓服務器開不了機,以後如果內存萬一壞了一條是不是也會出同樣的故障呢?這些問題我們就先不考慮了。之後又等了幾天,廠商發來了新內存,插上之後4條內存全部認到。

本來以為項目進行到這就完成了(當時是9月30號),但是(該死的“但是”又來了)上班之後問題又來了……

3 客戶反應虛擬機系統慢

10月5號該單位第一天上班,客戶反映虛擬機ERP系統慢。

我當時不在現場(更換內存時我不在現場,是公司其他工程師實施的)。我遠程登錄,在檢查的過程中,發現其中一臺ESXi12主機(IP地址172.16.6.12)的存儲連接斷開,在“清單”中有一個虛擬機變灰,如圖10所示,但此時使用遠程桌面是可以登錄這個虛擬機的。

技術分享圖片

圖10 沒有檢測到共享存儲

此時在左側選中172.16.6.12這臺主機(ESXi12),“配置→存儲”中共享存儲已經變灰不可訪問,如圖11所示。

技術分享圖片

圖11 在第2臺主機存儲變灰

但另一個主機ESXi11(IP地址為172.16.6.11)存儲正常,但fc-data02顯示的可用容量為0,如圖12所示。

技術分享圖片

圖12 第1臺主機存儲正常

登錄IBM V3500存儲,在存儲中檢查到一切正常,如圖13所示。

技術分享圖片

圖13 存儲中檢測到正常

在重新掃描存儲沒有反應之後,我重新啟動故障主機。正常情況下,主機在5~8分鐘之後會上線,但等了有30分鐘,這臺重新啟動的主機也沒有上線,PING這臺主機的IP地址也不通,這時候我就有點著急了,壞了,這臺沒出現問題的服務器也出問題了(換主板的是另一臺服務器)。

這時我還在家,我馬上聯系公司的人、聯系客戶,說服務器出了問題,需要馬上趕過去。

4 解決問題一波三折

一路無話,下午趕到現場之後,發現我遠程重新啟動、出問題的那臺那臺服務器已經“正常”了。但感覺虛擬機系統還是有點慢。之後我重新啟動這臺主機,終於發現了問題,就是這臺服務器啟動特別慢。BIOS自檢到系統啟動這一環節還算正常,但從出現ESXi的界面之後到進入系統,時間非常的長。

在進入ESXi界面之後,分別在“nfs41client loaded successfully”(如圖14所示)、“Running sfcbd-watchdog start”(如圖15所示)各停留大約30多分鐘。

技術分享圖片

圖14 在此停留半小時

技術分享圖片

圖15 在此停留半小時

因為另一臺主機更換過主板與內存,這臺主機只更換過內存。而在換內存之前系統正常。初步判斷可能是更換單條64GB內存引起的,但網絡中另一臺服務器也是安裝了4條64GB的內存,這臺主機正常,忘記說了,另一臺正常的主機更換過主板。檢查這兩個主機,發現正常運行的主機的固件比較新(ESXi11的主機),因為這臺主機換了一塊新主板。之後我為出故障的主機(ESXi12)刷新固件到同版本,系統啟動變快了一點,但仍然沒有解決問題(還是在圖14、圖15停留很長時間)。這時已經是晚上8點多了,先暫時不解決了,回去換個思路。

第二天一早來到客戶現場,我參考聯想工程師的方法,一條一條的“試”內存。在一條一條“試”內存的過程中,插上每條內存啟動速度都很快,從出現圖14、圖15所示的ESXi的啟動界面,幾分鐘就進入系統出現ESXi的控制臺頁面(出現IP地址等信息),但試過內存沒問題之後,將所有內存都插上,系統啟動就又變慢了。

之後,換上原來拆下來的單條16GB的內存(當時內存還沒有發回廠家),ESXi啟動時間變為半小時,但ESXi主機反應仍然較慢。

這樣時間就又過去了2個多小時,問題還沒有解決,能想的都想過了,能嘗試的都嘗試過了,那麽問題出在那呢?

我思考,為什麽插上單條64GB內存很快,內存全部插上就變慢呢?這時我註意到了一個“細節”,在插單條64GB內存的時候,為了加快測試速度,我沒有插網線和存儲光纖(每次關機拔內存都要斷電,要把服務器從機櫃中拉出來,後面的網線、光纖也是拔下的)。然後我思考,網絡問題不會引起ESXi啟動慢,那麽問題就可能出在服務器與存儲的連接光纖上!因為每臺服務器只配了一塊單口的FC-HBA接口卡,服務器與存儲只有一條光纖連接,沒有冗余。將出問題的這臺服務器更換光纖之後,重新啟動服務器,啟動速度正常(大約不到5分鐘就進入了ESXi的控制臺界面),至此問題解決。

總結

事後分析,因為前幾天反復更換內存、為服務器更換主板,反復為服務器加電、斷開、從機櫃中拉出服務器,可能碰到了ESXi12這臺服務器的光纖,導致光纖出故障,但光纖又沒有完全斷,可能處於“時通時斷”的狀況,這樣服務器在連接到存儲時,會反復嘗試,或者有錯誤的數據包需要糾錯。如果光纖完全斷開,服務器檢測不到就會跳過連接存儲,反而是這種“時通時斷”的連接,導致服務器反復嘗試,增加了服務器的啟動時間。

更多虛擬化課程及視頻,請單擊“VMware系統集成工程師”專題。

http://edu.51cto.com/topic/1308.html

某虛擬化項目總結:一條光纖引發的故障