摘要：在今年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所示。
blob.png
圖1 某單位虛擬化拓撲圖
在專案的初期，安裝配置esxi主機、劃分ibm v3500儲存、建立虛擬機器後，各個業務虛擬機器對外提供服務，系統一切正常。在全部業務虛擬機器正常執行兩天後，觀察到主機記憶體使用率超過60%接近70%時，我對客戶建議將每台伺服器的記憶體擴充到256gb，甲方技術主管在匯報領導後，同意了擴充記憶體的要求，但是就是在這個擴充記憶體，引起了後續一系列的故障。
說明：使用vsphere client登入vcenter server，在左側導航器中選中群集，在右側「主機」選項卡中，可以看每個主機配置的記憶體、已經使用記憶體的百分比。圖2是每台主機配置到256gb之後的截圖，當時128gb截圖沒有儲存。這是專案正常之後的截圖，從圖中可以看出，系統中所有虛擬機器使用記憶體大約170gb，在每台主機只有128gb的情況下，使用記憶體是66%，在每台主機擴充到256gb後，使用記憶體33%。
clip_image004
圖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所示。
clip_image006
圖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所示。
clip_image008
圖4 當前安裝了8條16gb記憶體截圖
但是，將4條64gb的記憶體插上之後，伺服器開機無顯示，在imm中也沒有檢測到記憶體，如圖5、圖6所示。
clip_image010
圖5 沒有檢測到記憶體
clip_image012
圖6 記憶體詳細資訊、無記憶體
後來一條一條記憶體安裝，伺服器也是檢測不到記憶體。沒有辦法，將原來的8條16gb記憶體插回主機。
聯絡記憶體經銷商之後，更換了鎂光的單條64gb的記憶體，安裝成功（記憶體往返又是
三、五天的時間），如圖7所示。說明，此次不能用的單條64gb記憶體，我在dell r720xd主機上使用是沒有問題的。
clip_image014
圖7 檢測到4條64gb的主機
但是，關鍵問題是這個「但是」。在為第1臺主機順利的安裝更換了記憶體之後，為第2臺主機安裝記憶體的時候出了大問題。在插上這4條64gb記憶體之後，主機無法開機，在imm檢測，提示系統出現嚴重故障（system critical），如圖8所示。
clip_image016
圖8 system故障
經過聯絡聯想的售後，工程師說主機板壞了，這下我們就「暈」了，這伺服器也太不「結實」了吧？沒辦法，只能等售後工程師上門更換主機板了。
所幸我們離北京較近，售後第2天上門更換新的主機板之後，故障依舊。這時大家都有點「糟」了。但是，還是工程師有經驗。工程師換上原來的16gb記憶體之後，伺服器可以開機，一切正常。但換上這4條記憶體之後還是出現圖8的故障。之後工程師，採用一條一條安裝64gb記憶體，檢測到其中的一條有問題，後來安裝了3條64gb記憶體，如圖9所示。
clip_image018
圖9 當前安裝3條記憶體
這樣我們就更鬱悶了，一條記憶體故障就能讓伺服器開不了機，以後如果記憶體萬一壞了一條是不是也會出同樣的故障呢？這些問題我們就先不考慮了。之後又等了幾天，廠商發來了新記憶體，插上之後4條記憶體全部認到。
本來以為專案進行到這就完成了（當時是9月30號），但是（該死的「但是」又來了）上班之後問題又來了……
3 客戶反應虛擬機器系統慢
10月5號該單位第一天上班，客戶反映虛擬機器erp系統慢。
我當時不在現場（更換記憶體時我不在現場，是公司其他工程師實施的）。我遠端登入，在檢查的過程中，發現其中一台esxi12主機（ip位址172.16.6.12）的儲存連線斷開，在「清單」中有乙個虛擬機器變灰，如圖10所示，但此時使用遠端桌面是可以登入這個虛擬機器的。
clip_image020
圖10 沒有檢測到共享儲存
此時在左側選中172.16.6.12這台主機（esxi12），「配置→儲存」中共享儲存已經變灰不可訪問，如圖11所示。
clip_image022
圖11 在第2臺主機儲存變灰
但另乙個主機esxi11（ip位址為172.16.6.11）儲存正常，但fc-data02顯示的可用容量為0，如圖12所示。
clip_image024
圖12 第1臺主機儲存正常
登入ibm v3500儲存，在儲存中檢查到一切正常，如圖13所示。
clip_image026
圖13 儲存中檢測到正常
在重新掃瞄儲存沒有反應之後，我重新啟動故障主機。正常情況下，主機在5～8分鐘之後會上線，但等了有30分鐘，這台重新啟動的主機也沒有上線，ping這台主機的ip位址也不通，這時候我就有點著急了，壞了，這台沒出現問題的伺服器也出問題了（換主機板的是另一台伺服器）。
這時我還在家，我馬上聯絡公司的人、聯絡客戶，說伺服器出了問題，需要馬上趕過去。
4 解決問題一波三折
一路無話，下午趕到現場之後，發現我遠端重新啟動、出問題的那台那台伺服器已經「正常」了。但感覺虛擬機器系統還是有點慢。之後我重新啟動這台主機，終於發現了問題，就是這台伺服器啟動特別慢。bios自檢到系統啟動這一環節還算正常，但從出現esxi的介面之後到進入系統，時間非常的長。
在進入esxi介面之後，分別在「nfs41client loaded successfully」（如圖14所示）、「running sfcbd-watchdog start」（如圖15所示）各停留大約30多分鐘。
clip_image028
圖14 在此停留半小時
clip_image030
圖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這台伺服器的光纖，導致光纖出故障，但光纖又沒有完全斷，可能處於「時通時斷」的狀況，這樣伺服器在連線到儲存時，會反覆嘗試，或者有錯誤的資料報需要糾錯。如果光纖完全斷開，伺服器檢測不到就會跳過連線儲存，反而是這種「時通時斷」的連線，導致伺服器反覆嘗試，增加了伺服器的啟動時間。
一條clickhouse SQL語句引發的問題思考
前段時間在實際工作中，使用者的一條sql引發了我一些思考。寫一篇簡單的博文來記錄下。實際表的列名等已替換。select from db1.table1 as t1 left join db2.table2 as t2 on t1.col1 t2.col2 where t1.time 2020 01 ...
一條命令引發的思考
背景 要求把 user目錄裡31乙個省份資料夾許可權全部更改為700許可權，並給在群裡貼出修改的命令如下 hadoop fs chmod r 700 user 操作 這個還不簡單，就是手敲下各個身份嘛，頗為簡單，直接開工如下 hadoop fs chmod r 700 user hadoop fs ...
一條cltq指令引發的血案
文章 我的個人部落格上了 但是很久沒有維護已經被關掉了。現在重新將裡面的東西移到csdn上了。兩個 a.c b.c，a.c裡實現了乙個函式 void malloc2d 返回乙個void型的二級指標，然後b.c裡會呼叫這個malloc2d的函式，但是在除錯的時候始終得不到正確的值，遂用gdb進行除錯一...