彈性分配，增加儲存利用率

朱惟正 現任DataCore臺灣區業務經理，曾參予過多家企業的儲存系統建置與諮詢。

過去在儲存區域網路（SAN）下，將後端儲存設備的容量分配給前端主機時，都是採用固定的映射方式，不容易調整容量分配，以致容量利用率難以有效提高。而Thin Provisioning則改以更彈性的方式向前端主機提供容量，解決容量利用率低的問題。DataCore是Thin Provisioning技術的創始者之一，該公司臺灣區業務經理朱惟正將分析Thin Provisioning的作用方式與原理。

問：儲存容量分配缺乏彈性會有什麼後果？
答：首先是容量利用率很低。由於有的主機占用的容量很大，有的主機占用的容量很小，因此形成某些主機容量緊繃、另一些主機的空間卻閒置。據Garther的統計，一般企業的儲存空間利用率只有30～40%左右，換句話說，高達60%以上的容量都是閒置的，但因為傳統的容量分配方式是固定的，這些閒置容量也很難轉移給需要的主機使用，造成很大的浪費。

其次是重新設定容量分配既費時且麻煩，有時還需停機。

最後還有設備成本浪費的問題。由於傳統儲存分配方式缺乏彈性，為了確保重要的主機不會發生容量不夠，導致應用程式停擺的情況，用戶被迫一開始就購進很大的容量，以備不時之需。但這樣會有兩個問題：如果容量的預估不準確，購入的容量比實際需求高，那用不到的部份就浪費了。

即使預估十分準確，購入的空間最後都能利用，但以實際情況來說，任何應用程式所產生的資料量，都是從小到大逐漸增加，不可能一開始就占用到很大的容量。所以從「時間」的觀點來看，雖然這些容量最後還是會被用到，但不是「一開始」就會用到，在系統實際消耗空間還很小的時候，就購入大量容量待用，「太早購足」也是一種浪費。

問：Thin Provisioning如何解決傳統容量分配方式的種種弊端？
答：Thin Provisioning的核心觀念就是「依實際占用情況分配容量」。只有資料真正寫入時，才會把實體容量分配給前端主機，不像傳統方式一開始就把一塊固定的LUN分配給前端主機。

Thin Provisioning其實不是新技術，DataCore在2001年發表的SANSymphony 4.0上採用的Network Managed Volume（NMV），就是這種彈性容量分配技術，後來在2004年稱作Auto Provisioning，2005年又變更為Virtual Capacity，從今年起才跟隨趨勢，改稱為Thin Provisioning。

問：以DataCore產品為例，Thin Provisioning實際上是如何運作？
答：目前SANsymphony與SANmelody都內建了Thin Provisioning，用戶只要開啟授權就能啟用。啟用後，SANsymphony與SANmelody會把分配給前端主機的容量，和後端實體儲存空間彼此脫鉤：分配給前端主機的空間都是「邏輯容量」，和後端實體儲存空間無關。系統會把整個儲存設備構成一個儲存池，當前端主機寫入資料時，系統才會以Storage Allocation Unit（SAU）為單位，將儲存池的實體容量分配給前端主機，SAU的單位可在1～128MB間設定。這也是說，系統不是一次就把一塊數十或上百GB的容量分給前端主機，而是視前端主機寫入的資料量大小，將實體容量以1～128MB為單位逐次分配給主機，這也就是「按需分配」的意義，只有真的寫入了，才會分配到相對應的容量。

問：啟用Thin Provisioning後，有什麼不同？
答：在Thin Provisioning下只實際寫入的資料，才會分配到實體空間，所以不會有「有的主機容量不夠用，有的主機容量卻太多」的問題，儲存空間的利用率可從40%提高到80～90%。同樣的實體容量，用戶透過Thin Provisioning可榨出比過去多一倍以上的有效容量。

而且這對前端主機的運作完全沒有影響，前端主機看到的容量只是虛擬的邏輯容量，用戶可以為前端主機設定很大的邏輯容量，但在後端只準備很小的實體容量，所以用戶可以不用在系統建置初期就買進很大的實體容量，可等到空間真的消耗到一定量時再去採購。因為儲存設備成本必然是越來越低，越晚買，就越便宜。

問：實體容量總有耗盡的時候，即使靠Thin Provisioning也沒辦法挖出更多的容量。但由於前端伺服器分配到的是虛擬的邏輯容量，用戶很可能會忽略實體空間耗盡的問題，要怎樣避免這問題？
答：Thin Provisioning都會含有警告機制。以DataCore產品來說，用戶可為儲存池設定「水位」警示，當容量的消耗接近「水位」時，系統就會發出警告。而對分配給前端的邏輯容量亦可設定「配額」，當實體容量消耗達到配額時，即可發出警告，甚至是禁止新資料寫入。整理⊙張明德