[[206711]]

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

1想當(dāng)然，不按流程走

案例：操作失誤導(dǎo)致的寫入失敗

問題描述：

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

解決過程：

***反應(yīng)，先確定是宿主機問題還是存儲問題。測試其他DataStore，完全正常。那就把問題縮小到這個DataStore上來?？赡苁菕燧d或者格式化的時候出現(xiàn)了問題，重新來唄，結(jié)果還是一樣。

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

第三反應(yīng)，查看Vmware底層日志，看似有鎖信息。

第四反應(yīng)，誰加的鎖呢?為什么不釋放呢?

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

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

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

問題總結(jié)：

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

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

2只關(guān)注自己的一畝三分地

案例：防火墻導(dǎo)致的宿主機失聯(lián)

環(huán)境介紹：

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

問題描述：

虛擬化基礎(chǔ)架構(gòu)部署全部完畢，運行一致良好。突然間有一天發(fā)現(xiàn)其中一個安全隔離區(qū)內(nèi)的宿主機有一個掉線了。還沒等我來的及區(qū)調(diào)查原因，這個宿主機又恢復(fù)正常了。

解決過程：

***反應(yīng)，別的先別說，不可再現(xiàn)的問題，先看日志吧。結(jié)果發(fā)現(xiàn)其中一個宿主機掉線非常頻繁，其他幾個宿主機偶爾都會發(fā)生掉線現(xiàn)象。而且現(xiàn)象只發(fā)生在其中一個安全隔離區(qū)內(nèi)，其他隔離區(qū)內(nèi)沒有此現(xiàn)象。

第二反應(yīng)，問問應(yīng)用那邊，看看有沒有察覺到異常。結(jié)果沒有。

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

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

第五反應(yīng)，一方面，收集日志發(fā)給廠商。另外一方面，交叉測試，于是乎，交叉換網(wǎng)卡，還是一個德行。

交換換交換機，好像好一點，但是還會出現(xiàn)類似問題。

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

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

問題總結(jié)：

對于這個案例來講，更多的關(guān)注點是在虛擬化架構(gòu)與其他廠商設(shè)備配合過程中的問題。一個很不經(jīng)意的配置可能會引起很嚴(yán)重的問題。

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

3實施后不重視檢驗過程

案例：網(wǎng)卡綁定失誤導(dǎo)致的業(yè)務(wù)中斷案例

環(huán)境介紹：

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

網(wǎng)絡(luò)分管理網(wǎng)段和業(yè)務(wù)網(wǎng)段，每一個網(wǎng)卡上的雙口分別上聯(lián)兩個不同交換機，交換機對端口設(shè)置Trunk模式，允許任何網(wǎng)段通過，不需要做綁定。網(wǎng)卡側(cè)需要按照交叉方式綁定四個端口為兩組，分別走業(yè)務(wù)和管理，交換機不需要綁定。

問題描述：

所有虛擬化環(huán)境部署完畢，在結(jié)合業(yè)務(wù)做切換測試的過程中，開發(fā)人員報告部分業(yè)務(wù)系統(tǒng)不可訪問。

解決過程：

***反應(yīng)，先做客戶端到應(yīng)用系統(tǒng)的Ping測試。DNS解析沒有問題，但是網(wǎng)絡(luò)不可達。

第二反應(yīng)，網(wǎng)絡(luò)可能有問題，檢查客戶端到目標(biāo)網(wǎng)段的網(wǎng)關(guān)可達性。網(wǎng)關(guān)全部可達。

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

第四反應(yīng)，什么情況?監(jiān)控一點直覺沒有么?再問。

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

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

問：就一個?

答：對，就一個。

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

第六反應(yīng)，網(wǎng)卡幫錯了。再查，網(wǎng)卡綁定順序與其他同類型的機器順序一樣啊。查MAC對應(yīng)關(guān)系，結(jié)果發(fā)現(xiàn)這臺機器的Vmware顯示的網(wǎng)卡順序確實與其他機器識別達到的網(wǎng)卡設(shè)備名順序不一樣。當(dāng)初實施工程師僅僅靠著一個樣本機的網(wǎng)卡設(shè)備文件名與物理網(wǎng)口的對應(yīng)關(guān)系就按照一個標(biāo)準(zhǔn)實施了。

問題總結(jié)：

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

***個案例已經(jīng)說過不要想當(dāng)然，此處更要強調(diào)實施后的檢驗過程非常重要，可以救你一條命。

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

案例：VMware虛擬機響應(yīng)異常故障排查案例

問題描述：

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

解決過程：

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

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

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

問題總結(jié)：

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

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

本文結(jié)合生產(chǎn)環(huán)境實施 VMware 虛擬化基礎(chǔ)架構(gòu)實例分析，但其實以上錯誤，在任何項目實施中都不應(yīng)該犯。