[[206711]]

對于VMware虛擬化技術，大家可能或多或少都接觸過，***印象都是上手簡單。但是真正在生產環境實施VMware虛擬化基礎架構的時候，前人通過寶貴的經驗和血淚的教訓告誡我們，千萬不要犯以下4個錯誤：

1想當然，不按流程走

案例：操作失誤導致的寫入失敗

問題描述：

有一個DataStore始終寫入失敗，報錯很簡單，就是寫入失敗。

解決過程：

***反應，先確定是宿主機問題還是存儲問題。測試其他DataStore，完全正常。那就把問題縮小到這個DataStore上來。可能是掛載或者格式化的時候出現了問題，重新來唄，結果還是一樣。

第二反應，重新掛，從存儲上把Lun抽回去然后再分配給主機。還是一個熊樣。

第三反應，查看Vmware底層日志，看似有鎖信息。

第四反應，誰加的鎖呢?為什么不釋放呢?

第五反應，仔細詢問實施工程師，原來這個DataStore并沒有從Vmwware層面進行卸載就通知存儲工程師將其重新分配了。他說這么干過很多次了，重來沒沒有出過問題。

第六反應，不用想了，Vmare對這個Datastore加了scsi鎖，這個鎖加在了Lun的盤頭。在非正常釋放Datastore的場合下，及時存儲回收了，當它再次給到Vmware的時候，盤頭信息并沒有消除。鎖依然存在，所以無法寫入。

第七反應，存儲上講該存儲回收再次分配。問題消除。

問題總結：

試想，如果當時工程師按照正常的流程，把磁盤從Vmware層面進行卸載，然后存儲再回收，那就不會有這個問題了。

999的成功不等于1000一定成功，因為我們面對的外在環境不一定相同或者相似，所以一切操作請按照正確的流程去做。

2只關注自己的一畝三分地

案例：防火墻導致的宿主機失聯

環境介紹：

多套vmware虛擬化集群組成一個VDC，分別位于不同的安全隔離區內，VC處于一個獨立的安全隔離區內，每套虛擬化集群當中有若干宿主機。也就是說宿主機和VC分別屬于不同的安全隔離區，分屬不同的網段。

問題描述：

虛擬化基礎架構部署全部完畢，運行一致良好。突然間有一天發現其中一個安全隔離區內的宿主機有一個掉線了。還沒等我來的及區調查原因，這個宿主機又恢復正常了。

解決過程：

***反應，別的先別說，不可再現的問題，先看日志吧。結果發現其中一個宿主機掉線非常頻繁，其他幾個宿主機偶爾都會發生掉線現象。而且現象只發生在其中一個安全隔離區內，其他隔離區內沒有此現象。

第二反應，問問應用那邊，看看有沒有察覺到異常。結果沒有。

第三反應，那不用多想了，這個離線一定是宿主機跟VC之間的通訊斷掉了，沒有影響到正常的業務系統。

第四反應，看看日志，***感覺沒啥有價值的線索。為啥其他集群沒事兒呢，想想這個區和其他區的區別在哪里?同一個VC，只不過分屬不同的安全隔離區而已，只不過這個區屬于互聯網區，網絡層多了幾層隔離而已。

第五反應，一方面，收集日志發給廠商。另外一方面，交叉測試，于是乎，交叉換網卡，還是一個德行。

交換換交換機，好像好一點，但是還會出現類似問題。

第六反應，那剩下的區別就在防火墻上了，防火墻這個區用的是莫某家的，跟其他不一樣。不至于吧，雖然國產，但是也經得起推敲啊。于是把網絡的運維工程師以及廠商叫過來抓包，抓了好幾天，問題沒有重現。等吧，Vmware那邊終于給回復了，說是VC和宿主機的通訊被周期性阻斷了。

第七反應，多半是防火墻上的設置，找吧。對比兩家廠商的防火墻設置，終于發現了一個配置“Keep Alive”,問網絡廠商是不是可以像別人家的防火墻把這個開關關掉?；卮鹫f不能?？?，為什么?回答說，產品默認設置。問曰，你們有沒有在別家跟虛擬化產品配合過?回答曰，配合過，沒這個問題啊。啥也別說了，升級給網絡后線吧。過了幾天，回復了，“Keep Alive”在防火墻上可以吧UDP的關掉，TCP的不能關掉。OK，要的就是這句話，把UDP關掉之后，觀察了N天，一切OK。

問題總結：

對于這個案例來講，更多的關注點是在虛擬化架構與其他廠商設備配合過程中的問題。一個很不經意的配置可能會引起很嚴重的問題。

大家多多交流，上下游交流，同游交流，不僅僅知道自己的一畝三分地，也同時知道他人的一畝三分地，對于實施來講就會帶來更大的專家價值。

3實施后不重視檢驗過程

案例：網卡綁定失誤導致的業務中斷案例

環境介紹：

宿主機四臺，每臺配置兩塊雙口萬兆網卡;接入交換機兩臺。

網絡分管理網段和業務網段，每一個網卡上的雙口分別上聯兩個不同交換機，交換機對端口設置Trunk模式，允許任何網段通過，不需要做綁定。網卡側需要按照交叉方式綁定四個端口為兩組，分別走業務和管理，交換機不需要綁定。

問題描述：

所有虛擬化環境部署完畢，在結合業務做切換測試的過程中，開發人員報告部分業務系統不可訪問。

解決過程：

***反應，先做客戶端到應用系統的Ping測試。DNS解析沒有問題，但是網絡不可達。

第二反應，網絡可能有問題，檢查客戶端到目標網段的網關可達性。網關全部可達。

第三反應，問題出在接入交換機和宿主機鏈接上，難道發生了雙點故障?于是詢問運維人員設備監控情況如何?運維人員說一切正常，沒有發現異常。

第四反應，什么情況?監控一點直覺沒有么?再問。

問：某某機柜某某交換機有沒有問題?某某機柜某某服務器有沒有報警?

答：回答說，沒有報警，不過....不過什么?有一個交換機在升級firmware，屬于正常停機，不在異常范圍之內。

問：就一個?

答：對，就一個。

第五反應，不對啊，任何單點都不可能影響到架構的高可用啊。VC登錄上去查具體的機器狀態，結果所有機器處于運行狀態。再次確認問題出在接入交換機和宿主機之間的鏈接上。于是讓運維人員進入機房再查網卡以及交換機狀態。報告說有一臺機器的其中一個網卡的兩個口全部沒有上聯信號。

第六反應，網卡幫錯了。再查，網卡綁定順序與其他同類型的機器順序一樣啊。查MAC對應關系，結果發現這臺機器的Vmware顯示的網卡順序確實與其他機器識別達到的網卡設備名順序不一樣。當初實施工程師僅僅靠著一個樣本機的網卡設備文件名與物理網口的對應關系就按照一個標準實施了。

問題總結：

對于這個案例來講，其實高可用的設計也好，網卡綁定技術也好都不是問題。問題的關鍵是工程師想當然認為一種型號的機器對于IO設備文件名的識別順序是完全一致的。其實不然，不同場合下可能設備文件名的順序會產生不一致。幸虧這個問題是在測試階段發生。

***個案例已經說過不要想當然，此處更要強調實施后的檢驗過程非常重要，可以救你一條命。

4不能未雨綢繆、防微杜漸

案例：VMware虛擬機響應異常故障排查案例

問題描述：

某日，根據運維同事反映，在VMware虛擬化平臺上的某系統出現嚴重的延遲現象，在通過操作系統登陸后，進行操作的響應時間特別長，且較之前有明顯的卡頓現象。針對此問題，針對該虛擬機的運行情況進行了分析。

解決過程：

首先，想到的是排查該虛擬機所在的Esxi主機的性能，發現該主機CPU利用率在20%左右，內存利用率在40%左右，IO讀寫延遲不超過1ms，且該Esxi主機上面的其他虛擬機都運行正常，所以基本排除了該物理主機的問題。

接著，便在Vcenter中重點對該虛擬機的配置及日志進行檢查，通過登陸Vcenter管理控制臺查看該虛擬機的配置，發現該虛擬機的磁盤文件下面存在大量的-delta.vmdk文件，不同于其他普通的.vmdk文件。初步將該問題定位于此，并將該問題發送給VMware工程師，經過分析，確認是過多的delta文件直接導致了系統響應異常。

那么為什么會產生這么多delta文件?一般而言，虛擬機快照會產生delta文件，VDP備份軟件也會在備份之前進行虛擬機快照從而產生delta文件。而當客戶操作系統內執行一個磁盤操作時，磁盤I / O重新解析磁盤文件鏈中的每個delta文件。這將產生額外的主機磁盤開銷，從而導致性能問題。而該虛擬機的應用系統因平時變更頻繁，所以運維同時在變更前都要執行快照，且長時間沒有將快照刪除。

問題總結：

經過該問題的出現，日后在VMware化平臺的維護中特別注意將重復快照的刪除，否則時間久了，且存在大量的快照會影響虛擬機的性能。同時，要定期通過SSH登陸到ESXi服務器，查找是否有delta文件產生。如果文件數量過多的話可能導致更為嚴重的無法連接的錯誤，需要及時解決。

本例中分享者做到了一旦發現問題，就要考慮將來要未雨綢繆、防微杜漸，及時和定期操作。

本文結合生產環境實施 VMware 虛擬化基礎架構實例分析，但其實以上錯誤，在任何項目實施中都不應該犯。