close

〈本文同步刊載於Blogger〉
狸貓先生愛廢話講堂: VMware 大哉問 - Datastore 儲存空間剩多少容量算是不夠用?

今天來回覆聽眾 Miss G 的點播。

在開始之前做個簡單快問快答,大家通常都怎麼用 Datastore 的?
切出一大塊儲存空間,然後就拼命一直塞進去,直到塞滿再找下一塊儲存空間?
還是切出多塊儲存空間,將 VM 平均分散放在各塊儲存空間內?
或是有其他更好的使用方法?

<小提醒>此篇字數較多且內容較硬,大家可斟酌觀看,或是中間自行休息片刻。

<<前情提要>>
(因為內容牽涉到環境資訊,會出現小小馬賽克,請放心觀賞。)
在備份軟體看到一個錯誤訊息:Disk space usage on datastore MGMT (95%) has grown beyond the critical threshold 95%。

實際到 MGMT datastore 查看,總容量 2.00 TB、剩餘空間 101.06 MB,換算磁碟使用率的確如告警訊息所示超過 95% [(2048-101.06)/2048 = 0.9506]。

<<推眼鏡解說>>
我們來看一下 MGMT Datastore 裡的 VM 有哪些呢?哇哩勒~不看則已,一看嚇出一身冷汗。
從上往下加,將每台 VM "佈建的空間"加總,加到紅框下一台 VM 的時候早就 2 TB 爆掉了,我沒有膽量繼續往下算。如果說這是線上環境,那我只能說當初的規劃者(或是說執行者)真是太有種,難道不擔心 Datastore 100% full 發生,所有的 VM 全部凍結停止運作的慘況?

為什麼說像這樣的作法是很不恰當的規劃,簡單說明幾個名詞及觀念:
佈建的空間 (Provisioned Space):建立 Virtual Disk 所指定的容量,例如 120 GB。
已使用空間 (Used Space):Guest OS 在 Virtual Disk 實際存放的資料,所佔掉的真實容量。

為什麼 Provisioned Spaced 會和 Used Space 不一致呢?
在建立 Virtual Disk 時,Disk Provioning 的選項:
(1) Thin Provision 格式,會讓兩個數值不一致,佈建空間為輸入的容量大小、已使用空間趨近於零
(2) Thick Provision Lazy Zeroed 格式,佈建空間、已使用空間應該都會是輸入的容量大小,兩者會是相同的。

先撇去效能的事情不考慮,通常是在實驗或測試環境中,我們才會使用 Thin Provision 格式來建立 Virtual Disk,因為需要的 VM 數量多,而實體儲存的容量少,而且在這種環境下,就算 Datastore 塞滿了,頂多也是測試 VM 群一起動不了而已,不會有什麼天大的事發生。

而在線上環境中,強烈建議要採用 Thick Provision 格式來建立 Virtual Disk,因為這樣會容易掌握 Datastore 的剩餘量,才不會有某個 VM 的存放資料突然爆量,而造成 Datastore 實際剩餘量不足。這邊所說的是針對 Guest OS 給定的範圍內爆增,例如說某個 VM 的 Virtual Disk 有 100 GB,原先資料量 20 GB,突然在半小時內新增 60 GB,這屬於合理範圍的使用,但如果因 Datastore 規劃或執行不當,很可能會因為單一 VM 內的資料量增加,影響到全體 VM 的運作情況。

想要知道 Virtual Machine 的組成元件,以及在某些動作時,有些檔案會佔用較多空間的檔案,管理者需多加注意。
詳細可看這篇:狸貓先生愛廢話講堂: VMware 豆知識 - 虛擬世界中的 Virtual Machine 是什麼?
http://mistertanuki.blogspot.com/2018/07/what-files-make-up-a-virtual-machine-in-vmware-virtualization.html

回到主題 Datastore 儲存空間的使用率,如果是在規劃階段,謹記『不能只計算 Virtual Disk 容量的總和』,必須還要考慮上面提到的幾種會大量消耗容量的檔案,否則到時候會讓 Datastore 剩餘空間進退兩難;如果是在使用階段,那就要隨時注意 Datastore 的剩餘空間 (或是說剩餘率),尤其是在進行 backup、snapshot、Guest OS 檔案增加時,更要隨時關心 Datastore 是否趨近滿載。

再來讓我們看看 vCenter Server 預設告警的臨界值:
Web Client >>> vCenter Server >>> Alarm Definitions >>> Datastore usage on disk >>> Triggers
Warning Condition: 75%、Critical Condition: 85%,預設 Actions 無任何動作。

依據 VMware vCenter Server 的預設值,剩下 25% 的時候就需要注意,開始要計劃擴充 datastore 或是刪除用不到的 VM;在剩下 15% 就要拉緊急警報,再低就有可能會影響整個系統運作。預設 Actions 無動作,在超過臨界值時,只有在使用 Web Client、vSphere Client 連上 vCenter Server 時才會看到警告訊息,強烈建議在 Actions 需要自行新增 email 或其他告警方式,需確實通知到管理員的手段才有用,不然 Datastore 爆掉就悲劇了。

在 VMware Commnities 也有討論過這個問題,Datastore 最少可用空間需要保留多少,在官方文件其實沒有特別提到建議值,但大家討論出來大約是剩下 13% - 15% 是最低限度,再低就有可能會危害系統的穩定性,這也與 vCenter Server 預設的 Critical Condition 85% 大致符合。

當然 Datastore 需保留的剩餘趴數不是絕對值,它只是個參考值,依據每個環境在不同的 Datastore 放置的 VM 數量、VM Memory 配置、backup job 備份排程執行、concurrent backup tasks executing 同時執行的備份工作數量…等各種因素影響,需考量更多的保留比例,當然建議最好是不要超過 Warning Condition 75%。

管理 IT 時斷捨離的工夫很重要,尤其是在虛擬環境!以前要新加一台機器有多困難,需要經過預算爭取的拼搏,現在建立一個 VM 卻只需要點幾下,常常很多 VM 都已經不需要,但卻還一直留著,就連 VM snapshot 也是一樣留著,放任 VM 繼續運作,但不知道這對系統會帶來多大的危害。

有空會再來談談 VM Snapshot 到底是什麼東西,不當的使用快照可能會對系統或資料造成傷害,敬請期待。


<<參考資料>>
Understanding VM snapshots in ESXi / ESX (1015180)

Virtual machine becomes unresponsive or inactive when taking a snapshot (1013163)

What Files Make Up a Virtual Machine?

Best Practice Minimum Free Space on Datastore |VMware Communities

arrow
arrow

    狸貓先生 發表在 痞客邦 留言(0) 人氣()