凌晨一點手機連著震了三下。打開監(jiān)控一看vCenter里那個存儲告警已經(jīng)變成了紅色高亮——ESXi主機上的一個VMFS數(shù)據(jù)存儲容量使用率飆到了97%狀態(tài)直接掛上了“緊急”。再切到DELL存儲管理端一看后端存儲池的剩余空間也只剩不到5%。那一瞬間大家都是同一個感覺完蛋今天是別想睡了。這種“VMware ESXi DELL虛擬化存儲磁盤容量處于緊急狀態(tài)”的問題我在過去十年里處理過不下二十次。有自己環(huán)境里踩雷也有幫朋友遠程救火。每次情況都差不多告警郵件半夜發(fā)出來虛擬機還在跑但心里清楚這種狀態(tài)撐不了太久。一旦數(shù)據(jù)存儲寫滿虛擬機的磁盤IO會直接凍結(jié)所有落盤操作全部掛起整個業(yè)務(wù)庫等于一次性停擺。所以這篇東西不聊理論只聊處理思路和落地操作。如果你是剛接手虛擬化環(huán)境的新人或者正在面對一臺容量爆紅的ESXi主機按我這個排查和處理順序走一遍大概率能把這顆雷拆掉。1. 先把“容量緊急”這件事拆清楚拿到告警第一反應(yīng)別急著刪文件。虛擬化存儲的容量問題往往不是“某個文件太大”這么簡單而是多層結(jié)構(gòu)疊加導(dǎo)致的。ESXi數(shù)據(jù)存儲是跑在物理存儲之上的一個邏輯層你的DELL存儲可能是MD系列、PowerVault系列或者SC系列也可以是戴爾服務(wù)器內(nèi)置的PERC陣列外加DAS存儲。無論哪種物理層是存儲池和RAID組邏輯層才是你在vCenter里看到的一個個Datastore。1.1 “緊急狀態(tài)”到底是什么意思VMware的告警閾值一般分兩檔默認情況下數(shù)據(jù)存儲使用率達到85%時觸發(fā)“警告”Warning使用率達到95%或者更高時觸發(fā)“緊急”Critical。而在DELL OpenManage Storage Management或者Unisphere的管理界面里存儲池容量也有類似的閾值比如池使用率超過95%會標記為嚴重。這套告警機制本身是保護性質(zhì)的但問題在于你不可能在告警發(fā)生的那一瞬間才去處理因為從“緊急”到“徹底寫滿”往往只有一個晚上的時間差。我就見過一臺跑著數(shù)據(jù)庫的虛擬機白天看還有3%剩余夜里一個備份任務(wù)跑起來日志唰唰漲第二天早上數(shù)據(jù)存儲徹底滿了所有Windows Server虛擬機里的系統(tǒng)日志全部報錯數(shù)據(jù)庫進程直接hang住。所以在動手之前你需要先回答三個問題告警發(fā)生的是哪一層是ESXi的數(shù)據(jù)存儲還是DELL存儲后端池告警是持續(xù)性的還是突發(fā)的持續(xù)性的多半是容量規(guī)劃問題突發(fā)的通常是快照、日志、備份文件惹的禍。當(dāng)前業(yè)務(wù)能承受多久的停機這個決定了你是走在線處理流程還是需要約維護窗口停業(yè)務(wù)處理。1.2 容量爆紅的四個常見根因我遇到的容量緊急問題九成以上都能歸到以下四類快照積壓這是最大概率的元兇。虛擬機打了快照之后增量數(shù)據(jù)全部寫在快照文件里快照越積越大原來的VMDK基礎(chǔ)盤反而成了“只讀層”。有些環(huán)境里的虛擬機開了快照之后忘了合并一個快照跑了幾個月文件大得嚇人。日志和臨時文件膨脹Windows的C盤滿了會直接影響虛擬機系統(tǒng)但更隱蔽的是應(yīng)用生成的日志文件比如IIS日志、SQL Server的errorlog、Java應(yīng)用堆棧日志它們體積變大之后直接把整個Datastore吃掉。模板和ISO鏡像殘留很多運維人員習(xí)慣把安裝鏡像、操作系統(tǒng)模板直接放在數(shù)據(jù)存儲里一個Windows Server ISO 5到8GB模板幾十GB幾年下來全是看不見的“存儲黑洞”。Thin Provisioning的誤判ESXi層面的精簡磁盤其實際占用會隨著寫入增長而變大。如果當(dāng)初所有虛擬機都是Thick置備那空間占用在創(chuàng)建時就已經(jīng)鎖定了反倒不容易爆用了精簡置備之后每臺機器都覺得自己“用的不多”但加起來可能遠超物理容量。搞清楚根因處理才有方向。下面是詳細的排查和操作流程。2. 診斷三步走從vCenter到DELL存儲管理端處理容量問題最忌諱的就是憑感覺。沒有查清楚問題出在哪一層之前任何刪除操作都是拿生產(chǎn)環(huán)境冒險。我常用的診斷路徑是“先看ESXi數(shù)據(jù)存儲再看虛擬機內(nèi)部最后查DELL后端”。2.1 第一站vCenter里的Datastore狀態(tài)用vSphere Client登錄到vCenter點擊存儲視圖按使用率排序一眼就能看到哪些數(shù)據(jù)存儲處于“緊急”狀態(tài)。這時候先記錄幾個關(guān)鍵數(shù)據(jù)總?cè)萘渴嵌嗌僖咽褂枚嗌偈Ｓ喽嗌龠@個數(shù)據(jù)存儲上跑著幾臺虛擬機然后點進數(shù)據(jù)存儲的“文件”標簽頁把所有文件按大小排序。這一步能幫你快速判斷是不是有某個“巨無霸”文件把空間吃了。正常情況下一個數(shù)據(jù)存儲里應(yīng)該只有虛擬機目錄和必要的模板文件如果看到幾十GB的vswp文件或者快照文件問題基本就鎖定了。提示vCenter里的容量數(shù)字是按“文件占用”來統(tǒng)計的它無法反映底層存儲池的真實狀態(tài)。也就是說哪怕ESXi數(shù)據(jù)存儲顯示有10%剩余DELL存儲池可能已經(jīng)快滿了兩者必須一起看。2.2 第二站ESXi主機命令行核實底層數(shù)字有時候vCenter界面會卡或者性能數(shù)據(jù)會延遲直接SSH登錄到ESXi主機上用命令行核實一下更靠譜。這里有幾個我必須推薦的基礎(chǔ)命令df -h這個命令可以從ESXi的視角看每個VMFS卷的使用率。再看一下數(shù)據(jù)存儲的文件列表ls -lh /vmfs/volumes/datastore1/如果想要找一個目錄里的大文件可以用du命令du -sh /vmfs/volumes/datastore1/*/用du排一遍那些幾十GB的快照目錄、備份目錄就全暴露出來了。還需要注意一點vSphere Client里顯示的使用率有時候會忽略一些系統(tǒng)預(yù)留空間但df和du是比較底層的統(tǒng)計更接近真實情況。2.3 第三站DELL存儲管理端查物理池ESXi數(shù)據(jù)存儲層面看完了再回頭看DELL的存儲管理界面。不同型號的DELL存儲操作界面不一樣MD系列用MD Storage ManagerPowerVault ME系列用PowerVault ManagerSC系列用Dell Storage Manager如果是PowerEdge服務(wù)器內(nèi)置的PERC陣列則用OpenManage Server AdministratorOMSA查看這些工具的共同作用是看清楚物理硬盤組成了幾個RAID組或存儲池每個池的理論容量是多少熱備盤狀態(tài)如何池實際使用率是多少。如果這里的池使用率已經(jīng)超過90%那么就算ESXi數(shù)據(jù)存儲還有空間物理層也已經(jīng)是“肚子快撐破”的狀態(tài)必須優(yōu)先處理。實際操作中我習(xí)慣把三層數(shù)據(jù)記錄在一張表里對比層級總?cè)萘恳咽褂檬Ｓ嗍褂寐蔞Mware數(shù)據(jù)存儲2.0TB1.94TB60GB97%DELL存儲池20TB19TB1TB95%虛擬機內(nèi)部C盤200GB198GB2GB99%哪一層最先爆掉就從哪一層開始處理。但要注意三層往往是連動的只有同時做清理和擴容才能根治。3. 緊急處置實戰(zhàn)從止損到擴容的完整流程診斷結(jié)束之后就進入處理階段。我的處理順序固定為四步止損、清理、擴容、恢復(fù)冗余。順序不能亂因為如果你先刪文件再擴容發(fā)現(xiàn)空間還是不夠虛擬機可能已經(jīng)因為IO持續(xù)寫入而出問題了。3.1 立即止損別讓數(shù)據(jù)存儲徹底寫滿當(dāng)數(shù)據(jù)存儲使用率超過95%時最先要做的事情是踩剎車。這里的“剎車”有兩層含義一是告訴所有同事暫時不要在緊急狀態(tài)的數(shù)據(jù)存儲上創(chuàng)建新虛擬機、做快照、復(fù)制大文件二是檢查那些正在高速寫入日志的虛擬機必要時暫停它們的日志備份任務(wù)我在一次事故處理中就是因為沒有第一時間停止某臺SQL服務(wù)器的凌晨維護作業(yè)導(dǎo)致一個晚上時間數(shù)據(jù)存儲從93%直接干到100%最后虛擬機直接IO凍結(jié)。所以止損動作一定要快哪怕只是口頭通知也比什么都不做好。如果環(huán)境里配置了vSphere High AvailabilityHA或者Storage DRS這時候也要檢查一下這些自動化功能是否還在正常工作。數(shù)據(jù)存儲空間低于一定閾值時Storage DRS可能會觸發(fā)遷移操作但如果目標數(shù)據(jù)存儲空間也不足遷移會失敗反而增加額外負載。3.2 空間清理實戰(zhàn)快照、日志、臨時文件逐個擊破止損之后開始搶空間。按優(yōu)先級順序執(zhí)行第一步處理虛擬機的快照。用vSphere Client查看每臺虛擬機是否有快照。如果有先確認這個快照是最近幾小時內(nèi)創(chuàng)建的比如升級前的備份如果是右鍵虛擬機→快照→刪除快照等待合并完成。這里的“刪除快照”不是刪除數(shù)據(jù)而是把快照的增量變化合并回原始VMDK。注意刪除快照的操作時間取決于快照文件的大小幾十GB的快照可能要等半小時以上。千萬不能中途取消否則可能導(dǎo)致虛擬磁盤損壞。對于已經(jīng)無用的老舊快照刪除之后也要確認空間釋放情況。我處理過一個案例快照文件顯示有120GB但刪除之后數(shù)據(jù)存儲只釋放了80GB剩下的空間被其他文件占著不得不再做下一步。第二步清理虛擬機內(nèi)部的大文件。如果快照清理后空間依然緊張接著做虛擬機內(nèi)部清理。通過vSphere控制臺登錄到每臺虛擬機檢查以下幾個方面Windows系統(tǒng)的C盤剩余空間清理臨時文件夾%TEMP%C:\Windows\TempWindows更新的緩存文件C:\Windows\SoftwareDistribution\Download各數(shù)據(jù)庫日志文件和歷史備份文件應(yīng)用程序日志目錄這里的常用工具是Windows自帶的“磁盤清理”或者cleanmgr也可以用PowerShell把可執(zhí)行文件、垃圾緩存一并處理。第三步清理數(shù)據(jù)存儲里的冗余文件。打開vSphere的數(shù)據(jù)存儲瀏覽器找到那些明顯不需要的文件。常見的有過去的舊系統(tǒng)ISO安裝鏡像長期不用的虛擬機模板備份留下的VMDK副本孤兒vswp文件即虛擬機已關(guān)閉但vswp沒被清理的殘留在刪除這些文件之前先確認它們確實沒有業(yè)務(wù)用途。我一般會把疑似不需要的文件先移動到一個“待刪除”文件夾觀察一周確認沒有問題再徹底清理。3.3 擴容操作全解VMFS在線擴容和新增LUN清理只能解決“燃眉之急”如果虛擬機長期增長擴容永遠是終局方案。擴容有兩個方向給現(xiàn)有數(shù)據(jù)存儲擴容或者新建一個更大的數(shù)據(jù)存儲。方向一給現(xiàn)有VMFS數(shù)據(jù)存儲在線擴容這個過程是在VMware層面完成的。前提是底層的DELL存儲還有未分配的空間并且你的LUN已經(jīng)映射到ESXi主機。操作路徑為在vSphere Client中選擇目標ESXi主機點擊“存儲”→ 選擇要擴容的VMFS數(shù)據(jù)存儲點擊“增加容量”Increase Capacity選擇“擴大現(xiàn)有VMFS數(shù)據(jù)存儲”選擇空余的存儲設(shè)備或者擴展設(shè)備設(shè)置擴容大小點擊“確定”整個擴容過程可以在線完成虛擬機不需要停機。擴容完成后數(shù)據(jù)存儲的總?cè)萘繒⒓丛黾印７较蚨略鯨UN并創(chuàng)建新數(shù)據(jù)存儲這是更常用也更安全的做法。在DELL存儲管理端從存儲池中劃分出一個新的LUN映射給ESXi主機然后在ESXi里執(zhí)行“新建數(shù)據(jù)存儲”操作選擇這個新LUN并格式化為VMFS文件系統(tǒng)。創(chuàng)建完成后需要把這臺數(shù)據(jù)存儲上的部分虛擬機遷移過去以此平衡容量壓力。遷移方式用Storage vMotion可以在線遷移虛擬機不用停機。3.4 收尾調(diào)整告警閾值和存儲推薦處理完容量之后必做的收尾工作是調(diào)整閾值否則下次告警還會以同樣方式提醒你。VMware里可以自定義數(shù)據(jù)存儲的使用率告警閾值比如把“警告”調(diào)整到80%“緊急”調(diào)整到90%這是給自己留出更充足的反應(yīng)時間。另外一個重要操作是在DELL存儲管理端如果存儲池支持自動分級或者分層存儲可以根據(jù)熱點數(shù)據(jù)情況啟用相關(guān)功能讓熱數(shù)據(jù)放到高性能盤上冷數(shù)據(jù)下沉到大容量盤上從而減少整體池容量的壓力。4. 實操中常見的坑與排查技巧容量處理流程寫起來順實際操作中全是坑。下面這幾個問題我在不同環(huán)境里反復(fù)遇到過單獨列出來給大家避雷。4.1 刪除快照之后空間沒有立即釋放最常見的問題。刪除快照后vSphere界面顯示的數(shù)據(jù)存儲使用率可能半小時都不掉。這不一定代表沒釋放而是VMFS卷的空間統(tǒng)計有延遲。經(jīng)驗做法是等10到15分鐘然后SSH登錄ESXi用df -h看實際空間。esxi對VMFS卷的空間管理是延遲回收的這一點不是故障是正常機制。如果過了很久空間確實沒有釋放需要確認是否還有另一個快照存在或者虛擬機本身處于“已暫?？煺铡钡臓顟B(tài)。另外如果虛擬機磁盤是精簡置備刪除快照后還會有一個“空間重新認領(lǐng)”的過程需要執(zhí)行esxcli storage vmfs unmap來讓底層存儲真正回收空間。esxcli storage vmfs unmap --volume-labeldatastore1 --reclaim-unit20484.2 明明刪掉了一個大文件但是使用率沒變化這種情況大概率是因為刪除操作是在Windows虛擬機內(nèi)部做的而ESXi層面的VMDK文件大小并沒有變化。原因在于VMDK是虛擬磁盤文件刪除虛擬機內(nèi)部的文件只會在VMDK內(nèi)部進行文件空洞不會自動從VMDK釋放回數(shù)據(jù)存儲。解決辦法是使用esxcli storage vmfs unmap命令執(zhí)行UNMAP操作讓精簡置備的VMDK把未使用的塊歸還給數(shù)據(jù)存儲。前提是底層的DELL存儲支持自動精簡回收。如果不支持可以考慮定期整理比如每個季度做一次全量UNMAP。4.3 精簡置備的“容量幻覺”這是一個非常隱蔽的坑。ESXi用Thin Provisioning創(chuàng)建虛擬磁盤時初始文件很小只有幾GB但它會隨著虛擬機內(nèi)部寫入逐漸增長。你把一個500GB的精簡盤給了一臺虛擬機實際復(fù)制300GB數(shù)據(jù)進去VMDK文件就增長到了300GB。如果你給二十臺虛擬機都做了500GB精簡盤實際每臺只用100GB那么總占用是2TB看起來不多。但由于虛擬化環(huán)境是多層共享的這2TB的占用已經(jīng)算進了數(shù)據(jù)存儲容量。如果再疊加快照和系統(tǒng)日志容量爆得比誰都快。應(yīng)對方案在新環(huán)境里盡量合理評估虛擬機真實容量需求重要數(shù)據(jù)庫用Thick置備或者Eager Zeroed Thick普通應(yīng)用用Thin置備但定期檢查增長趨勢。4.4 Storage DRS閾值設(shè)置不當(dāng)引發(fā)的“假緊急”有集群環(huán)境的朋友如果開了Storage DRS會發(fā)現(xiàn)數(shù)據(jù)存儲的使用率一直徘徊在85%左右但偶爾會跳到“緊急”狀態(tài)。這有可能是Storage DRS的I/O負載均衡閾值太敏感導(dǎo)致的I/O平衡建議和容量本身沒關(guān)系。檢查方法是在vSphere Client里看Storage DRS的推薦報告區(qū)分是I/O負載遷移還是空間容量遷移。I/O負載遷移只影響性能不影響可用性但如果你把I/O和空間閾值都設(shè)置得比較激進會頻繁產(chǎn)生遷移動作徒增壓力。4.5 擴容后DELL存儲LUN映射不對給ESXi擴容時最容易出現(xiàn)的操作失誤是在DELL存儲上劃分了新LUN卻沒有正確映射給ESXi主機或者映射了但主機沒重新掃描。處理方式是在vCenter里選擇對應(yīng)的ESXi主機點擊“存儲”→“重新掃描存儲”讓主機重新掃描所有的存儲適配器、存儲設(shè)備然后新LUN才會出現(xiàn)在可用設(shè)備列表里。DELL存儲上的映射一般有三種方式LUN映射到主機組、LUN映射到主機、LUN映射到端口組。如果之前已經(jīng)建好了主機組新LUN加入時記得同時加入對應(yīng)主機否則主機掃描不到設(shè)備。4.6 別忘了一個很小的點vSphere HA的心跳數(shù)據(jù)存儲如果集群開啟了vSphere HA系統(tǒng)會選擇一個數(shù)據(jù)存儲存放心跳文件這個文件非常小只有幾MB不會占用太多空間。但問題是如果這個數(shù)據(jù)存儲滿了HA可能會失去心跳觸發(fā)虛擬機在另一臺主機上重啟造成宕機。所以容量緊急時要特別留意當(dāng)前告警的數(shù)據(jù)存儲是否就是HA心跳所在的數(shù)據(jù)存儲。如果是清理時的首選遷移目標要避開這臺防止HA誤判。5. 關(guān)于處理優(yōu)先級的兩點心得處理容量緊急問題我踩過不少坑之后總結(jié)出兩個很重要的原則寫在這里供大家參考。第一永遠先保數(shù)據(jù)再保業(yè)務(wù)。如果數(shù)據(jù)存儲真的滿了虛擬機已經(jīng)IO凍結(jié)千萬不要強行做快照刪除。正確的操作是先給虛擬機關(guān)機或掛起再處理否則可能導(dǎo)致虛擬機文件系統(tǒng)損壞甚至整塊虛擬磁盤無法掛載。有一次我就遇到虛擬機在滿盤狀態(tài)下直接崩潰結(jié)果VMDK的文件系統(tǒng)部分區(qū)域損壞被迫用快照文件恢復(fù)整個過程折騰了四個小時。第二容量告警類問題能立刻處理的立刻處理不能立刻處理的也要留下一臺維護窗口。很多人看到“緊急”兩個字覺得很嚴重但其實如果你每天都有固定的巡檢習(xí)慣這種問題是可以避免的。我現(xiàn)在每周一都會寫一個腳本巡檢所有數(shù)據(jù)存儲和DELL存儲池的使用率超過80%就在群里發(fā)預(yù)警。這樣發(fā)現(xiàn)問題的時候基本不會走到“緊急”這一步。容量管理本質(zhì)上就是一層窗戶紙捅破了之后你會發(fā)現(xiàn)處理流程無非就是查、清、擴、防四個字。真正難的是平時有沒有養(yǎng)成習(xí)慣以及告警真正來臨的時候能不能冷靜地按順序操作。希望這篇東西對你有用。