VMware虛擬化基礎(chǔ)架構(gòu)項(xiàng)目實(shí)施問題梳理

1、 VMware 虛擬化基礎(chǔ)架構(gòu)項(xiàng)目實(shí)施問題梳理 本文結(jié)合生產(chǎn)環(huán)境實(shí)施 VMware 虛擬化基礎(chǔ)架構(gòu)實(shí)例分析，但其實(shí)這些錯(cuò)誤，在任何項(xiàng)目實(shí)施中都不應(yīng)該犯。VMware虛擬化技術(shù)很多人都覺得上手簡單，但是真正在生產(chǎn)環(huán)境實(shí)施VMware虛擬化基礎(chǔ)架構(gòu)的時(shí)候，前人通過寶貴的經(jīng)驗(yàn)和血淚的教訓(xùn)告誡我們，千萬不要犯以下4個(gè)錯(cuò)誤：1想當(dāng)然，不按流程走案例：操作失誤導(dǎo)致的寫入失敗問題描述：有一個(gè)DataStore始終寫入失敗，報(bào)錯(cuò)很簡單，就是寫入失敗。解決過程：第一反應(yīng)，先確定是宿主機(jī)問題還是存儲(chǔ)問題。測試其他DataStore，完全正常。那就把問題縮小到這個(gè)DataStore上來。可能是掛載或者格式化的時(shí)候出

2、現(xiàn)了問題，重新來唄，結(jié)果還是一樣。第二反應(yīng)，重新掛，從存儲(chǔ)上把Lun抽回去然后再分配給主機(jī)。還是一個(gè)熊樣。第三反應(yīng)，查看Vmware底層日志，看似有鎖信息。第四反應(yīng)，誰加的鎖呢？為什么不釋放呢？第五反應(yīng)，仔細(xì)詢問實(shí)施工程師，原來這個(gè)DataStore并沒有從Vmwware層面進(jìn)行卸載就通知存儲(chǔ)工程師將其重新分配了。他說這么干過很多次了，重來沒沒有出過問題。第六反應(yīng)，不用想了，Vmare對(duì)這個(gè)Datastore加了scsi鎖，這個(gè)鎖加在了Lun的盤頭。在非正常釋放Datastore的場合下，及時(shí)存儲(chǔ)回收了，當(dāng)它再次給到Vmware的時(shí)候，盤頭信息并沒有消除。鎖依然存在，所以無法寫入。第七反應(yīng)，存

3、儲(chǔ)上講該存儲(chǔ)回收再次分配。問題消除。問題總結(jié)：試想，如果當(dāng)時(shí)工程師按照正常的流程，把磁盤從Vmware層面進(jìn)行卸載，然后存儲(chǔ)再回收，那就不會(huì)有這個(gè)問題了。99.9% 的成功不等于100% 一定成功，因?yàn)槲覀兠鎸?duì)的外在環(huán)境不一定相同或者相似，所以一切操作請(qǐng)按照正確的流程去做。2只關(guān)注自己的一畝三分地案例：防火墻導(dǎo)致的宿主機(jī)失聯(lián)環(huán)境介紹：多套vmware虛擬化集群組成一個(gè)VDC，分別位于不同的安全隔離區(qū)內(nèi)，VC處于一個(gè)獨(dú)立的安全隔離區(qū)內(nèi)，每套虛擬化集群當(dāng)中有若干宿主機(jī)。也就是說宿主機(jī)和VC分別屬于不同的安全隔離區(qū)，分屬不同的網(wǎng)段。問題描述：虛擬化基礎(chǔ)架構(gòu)部署全部完畢，運(yùn)行一致良好。突然間有一天發(fā)現(xiàn)

4、其中一個(gè)安全隔離區(qū)內(nèi)的宿主機(jī)有一個(gè)掉線了。還沒等我來的及區(qū)調(diào)查原因，這個(gè)宿主機(jī)又恢復(fù)正常了。解決過程：第一反應(yīng)，別的先別說，不可再現(xiàn)的問題，先看日志吧。結(jié)果發(fā)現(xiàn)其中一個(gè)宿主機(jī)掉線非常頻繁，其他幾個(gè)宿主機(jī)偶爾都會(huì)發(fā)生掉線現(xiàn)象。而且現(xiàn)象只發(fā)生在其中一個(gè)安全隔離區(qū)內(nèi)，其他隔離區(qū)內(nèi)沒有此現(xiàn)象。第二反應(yīng)，問問應(yīng)用那邊，看看有沒有察覺到異常。結(jié)果沒有。第三反應(yīng)，那不用多想了，這個(gè)離線一定是宿主機(jī)跟VC之間的通訊斷掉了，沒有影響到正常的業(yè)務(wù)系統(tǒng)。第四反應(yīng)，看看日志，第一感覺沒啥有價(jià)值的線索。為啥其他集群沒事兒呢，想想這個(gè)區(qū)和其他區(qū)的區(qū)別在哪里？同一個(gè)VC，只不過分屬不同的安全隔離區(qū)而已，只不過這個(gè)區(qū)屬于互聯(lián)

5、網(wǎng)區(qū)，網(wǎng)絡(luò)層多了幾層隔離而已。第五反應(yīng)，一方面，收集日志發(fā)給廠商。另外一方面，交叉測試，于是乎，交叉換網(wǎng)卡，還是一個(gè)德行。交換換交換機(jī)，好像好一點(diǎn)，但是還會(huì)出現(xiàn)類似問題。第六反應(yīng)，那剩下的區(qū)別就在防火墻上了，防火墻這個(gè)區(qū)用的是莫某家的，跟其他不一樣。不至于吧，雖然國產(chǎn)，但是也經(jīng)得起推敲啊。于是把網(wǎng)絡(luò)的運(yùn)維工程師以及廠商叫過來抓包，抓了好幾天，問題沒有重現(xiàn)。等吧，Vmware那邊終于給回復(fù)了，說是VC和宿主機(jī)的通訊被周期性阻斷了。第七反應(yīng)，多半是防火墻上的設(shè)置，找吧。對(duì)比兩家廠商的防火墻設(shè)置，終于發(fā)現(xiàn)了一個(gè)配置“Keep Alive”,問網(wǎng)絡(luò)廠商是不是可以像別人家的防火墻把這個(gè)開關(guān)關(guān)掉?；卮鹫f不

6、能?？?，為什么？回答說，產(chǎn)品默認(rèn)設(shè)置。問曰，你們有沒有在別家跟虛擬化產(chǎn)品配合過？回答曰，配合過，沒這個(gè)問題啊。啥也別說了，升級(jí)給網(wǎng)絡(luò)后線吧。過了幾天，回復(fù)了，“Keep Alive”在防火墻上可以吧UDP的關(guān)掉，TCP的不能關(guān)掉。OK，要的就是這句話，把UDP關(guān)掉之后，觀察了N天，一切OK。問題總結(jié)：對(duì)于這個(gè)案例來講，更多的關(guān)注點(diǎn)是在虛擬化架構(gòu)與其他廠商設(shè)備配合過程中的問題。一個(gè)很不經(jīng)意的配置可能會(huì)引起很嚴(yán)重的問題。大家多多交流，上下游交流，同游交流，不僅僅知道自己的一畝三分地，也同時(shí)知道他人的一畝三分地，對(duì)于實(shí)施來講就會(huì)帶來更大的專家價(jià)值。3實(shí)施后不重視檢驗(yàn)過程案例：網(wǎng)卡綁定失誤導(dǎo)致的業(yè)務(wù)中

7、斷案例環(huán)境介紹：宿主機(jī)四臺(tái)，每臺(tái)配置兩塊雙口萬兆網(wǎng)卡；接入交換機(jī)兩臺(tái)。網(wǎng)絡(luò)分管理網(wǎng)段和業(yè)務(wù)網(wǎng)段，每一個(gè)網(wǎng)卡上的雙口分別上聯(lián)兩個(gè)不同交換機(jī)，交換機(jī)對(duì)端口設(shè)置Trunk模式，允許任何網(wǎng)段通過，不需要做綁定。網(wǎng)卡側(cè)需要按照交叉方式綁定四個(gè)端口為兩組，分別走業(yè)務(wù)和管理，交換機(jī)不需要綁定。問題描述：所有虛擬化環(huán)境部署完畢，在結(jié)合業(yè)務(wù)做切換測試的過程中，開發(fā)人員報(bào)告部分業(yè)務(wù)系統(tǒng)不可訪問。解決過程：第一反應(yīng)，先做客戶端到應(yīng)用系統(tǒng)的Ping測試。DNS解析沒有問題，但是網(wǎng)絡(luò)不可達(dá)。第二反應(yīng)，網(wǎng)絡(luò)可能有問題，檢查客戶端到目標(biāo)網(wǎng)段的網(wǎng)關(guān)可達(dá)性。網(wǎng)關(guān)全部可達(dá)。第三反應(yīng)，問題出在接入交換機(jī)和宿主機(jī)鏈接上，難道發(fā)生了雙

8、點(diǎn)故障？于是詢問運(yùn)維人員設(shè)備監(jiān)控情況如何？運(yùn)維人員說一切正常，沒有發(fā)現(xiàn)異常。第四反應(yīng)，什么情況？監(jiān)控一點(diǎn)直覺沒有么？再問。問：某某機(jī)柜某某交換機(jī)有沒有問題？某某機(jī)柜某某服務(wù)器有沒有報(bào)警？答：回答說，沒有報(bào)警，不過.不過什么？有一個(gè)交換機(jī)在升級(jí)firmware，屬于正常停機(jī)，不在異常范圍之內(nèi)。問：就一個(gè)？答：對(duì)，就一個(gè)。第五反應(yīng)，不對(duì)啊，任何單點(diǎn)都不可能影響到架構(gòu)的高可用啊。VC登錄上去查具體的機(jī)器狀態(tài)，結(jié)果所有機(jī)器處于運(yùn)行狀態(tài)。再次確認(rèn)問題出在接入交換機(jī)和宿主機(jī)之間的鏈接上。于是讓運(yùn)維人員進(jìn)入機(jī)房再查網(wǎng)卡以及交換機(jī)狀態(tài)。報(bào)告說有一臺(tái)機(jī)器的其中一個(gè)網(wǎng)卡的兩個(gè)口全部沒有上聯(lián)信號(hào)。第六反應(yīng)，網(wǎng)卡幫錯(cuò)

9、了。再查，網(wǎng)卡綁定順序與其他同類型的機(jī)器順序一樣啊。查MAC對(duì)應(yīng)關(guān)系，結(jié)果發(fā)現(xiàn)這臺(tái)機(jī)器的Vmware顯示的網(wǎng)卡順序確實(shí)與其他機(jī)器識(shí)別達(dá)到的網(wǎng)卡設(shè)備名順序不一樣。當(dāng)初實(shí)施工程師僅僅靠著一個(gè)樣本機(jī)的網(wǎng)卡設(shè)備文件名與物理網(wǎng)口的對(duì)應(yīng)關(guān)系就按照一個(gè)標(biāo)準(zhǔn)實(shí)施了。問題總結(jié)：對(duì)于這個(gè)案例來講，其實(shí)高可用的設(shè)計(jì)也好，網(wǎng)卡綁定技術(shù)也好都不是問題。問題的關(guān)鍵是工程師想當(dāng)然認(rèn)為一種型號(hào)的機(jī)器對(duì)于IO設(shè)備文件名的識(shí)別順序是完全一致的。其實(shí)不然，不同場合下可能設(shè)備文件名的順序會(huì)產(chǎn)生不一致。幸虧這個(gè)問題是在測試階段發(fā)生。第一個(gè)案例已經(jīng)說過不要想當(dāng)然，此處更要強(qiáng)調(diào)實(shí)施后的檢驗(yàn)過程非常重要，可以救你一條命。4不能未雨綢繆、防微

10、杜漸案例：VMware虛擬機(jī)響應(yīng)異常故障排查案例問題描述：某日，根據(jù)運(yùn)維同事反映，在VMware虛擬化平臺(tái)上的某系統(tǒng)出現(xiàn)嚴(yán)重的延遲現(xiàn)象，在通過操作系統(tǒng)登陸后，進(jìn)行操作的響應(yīng)時(shí)間特別長，且較之前有明顯的卡頓現(xiàn)象。針對(duì)此問題，針對(duì)該虛擬機(jī)的運(yùn)行情況進(jìn)行了分析。解決過程：首先，想到的是排查該虛擬機(jī)所在的Esxi主機(jī)的性能，發(fā)現(xiàn)該主機(jī)CPU利用率在20%左右，內(nèi)存利用率在40%左右，IO讀寫延遲不超過1ms，且該Esxi主機(jī)上面的其他虛擬機(jī)都運(yùn)行正常，所以基本排除了該物理主機(jī)的問題。接著，便在Vcenter中重點(diǎn)對(duì)該虛擬機(jī)的配置及日志進(jìn)行檢查，通過登陸Vcenter管理控制臺(tái)查看該虛擬機(jī)的配置，發(fā)現(xiàn)該

11、虛擬機(jī)的磁盤文件下面存在大量的-delta.vmdk文件，不同于其他普通的.vmdk文件。初步將該問題定位于此，并將該問題發(fā)送給VMware工程師，經(jīng)過分析，確認(rèn)是過多的delta文件直接導(dǎo)致了系統(tǒng)響應(yīng)異常。那么為什么會(huì)產(chǎn)生這么多delta文件？一般而言，虛擬機(jī)快照會(huì)產(chǎn)生delta文件，VDP備份軟件也會(huì)在備份之前進(jìn)行虛擬機(jī)快照從而產(chǎn)生delta文件。而當(dāng)客戶操作系統(tǒng)內(nèi)執(zhí)行一個(gè)磁盤操作時(shí)，磁盤I / O重新解析磁盤文件鏈中的每個(gè)delta文件。這將產(chǎn)生額外的主機(jī)磁盤開銷，從而導(dǎo)致性能問題。而該虛擬機(jī)的應(yīng)用系統(tǒng)因平時(shí)變更頻繁，所以運(yùn)維同時(shí)在變更前都要執(zhí)行快照，且長時(shí)間沒有將快照刪除。問題總結(jié)：經(jīng)過