關於—Thin Provisioning

   一個方案設計提早完成，週四，週五就輕鬆一些，那就寫點東西吧。關於存儲精簡配置技術，算是一個古老的技術，不過仍然看到有論壇不少朋友沒有一個完整的理解，包括：目前技術程度，發展過程，用到哪些方面環境，應該注意什麼，產生的效益等等，所以我想闡述下本身一些卑微的見識；畢竟Thin Provisioning給我帶來不少利益，同時也是我比較敬重技術之一。

<之因此稱他爲古老的技術，那是由於存儲技術的發展實在太快了>

   首先，因爲一些標準協會的成立，不少技術概念已被定義，不過一些技術概念在不一樣的廠商使用不一樣的專利技術實現，所呈現的結果多是不一樣的。廠商爲了符合市場需求，產品競爭力，一般在維護這些技術概念的基礎上，進一步擴展其特性，這就比如Linux,簡單來講，最初階段只是一個內核，而現在發展成各個分支與商業版本，惟一保留的則是那幾個核心命令和系統名稱，告訴人們它是從Linux演變而來的。

    其次，我但願任何對這篇文章感興趣的朋友，可以按照文章的思路走下去，其一：可以完整的瞭解這個技術以及發展到目前的程度。其二：您可能接觸不少一線廠商的存儲中關於Thin Provisioning的技術例如：IBM，EMC等等，而這並不表明Thin Provisioning技術是他們強項，因此咱們的想象力絕對不能被他們限制。

******再次聲明下：既然標識爲原創，證實下方所闡述的所有來於我本身的觀點。個人經驗，閱歷，知識程度等方面會有不足，請把此文做爲一個參考，切勿較真。

----------------------------    

先聊一下發展歷程：

<*這不是一篇軟文，因此我儘量隱去一些公司名稱>

Thin Provisioning技術藍圖來自存儲界的前輩STK公司，由於他們早在93年提出來的，這一點能夠在Google.com.tw進行了解，只是一個藍圖或說是技術架構。而在2001年<或者以前>被一個軟件廠商「V」公司使用在存儲層並投入市場，使以前的藍圖轉爲商業技術，不過這一技術的命名並不是使用的是「Thin Provisioning」，其技術原理和結果倒是同樣的。緊接着在Gartner 02年峯會，「P」公司實現了Thin Provisioning技術，且命名爲：Thin Provisioning；在當時有趣的是，V公司和P公司在媒體，公開場合爭論的不可開交，爭論的焦點在於——Who is the first Thin Provisioning？或者Who invented the Thin Provisioning？但兩個公司還算厚道，坦誠是STK首先提出的這一理念。

精簡配置技術架構？

精簡配置技術在於把存儲內部的磁盤或者RAID進行「池」化，經過磁盤池提供LUN給應用主機，而提供LUN的體積不受實際空間的制約，經過圖釋也許可以更直觀的瞭解：

經過上圖可以看出，全部RAID容量被合併到一個大的池中，池能夠包含一個RAID或者若干個：容量和數量取決於各廠商的技術原理和指標，而這一技術發展並未中止。

隨之虛擬化技術普遍使用，一些跑在技術前沿的廠商創造了更高明的玩法，好比經過軟件，創建一套虛擬化層，整合的資源從存儲的內置RAID擴展到整合外置的資源。好比把一臺或若干臺存儲也塞到磁盤池，而且讓這些不一樣廠商的存儲相容性的工做，以下圖：

實現這一技術的過程也許至關複雜的，可是就結構來看比較簡單。

值得一提的是，任何技術都會有樂觀的一面和消極的一面，關鍵是各個廠商是否投入精力去改善這些不利的因素。若是選擇咱們運氣好選擇了一個不錯的廠商，潛在問題都已解決或規避，咱們徹底認爲這個技術是沒有反作用的，那剩下的則是潛在效益，這是明智的。固然咱們也會遇到另外一種狀況，廠商沒有投入過多的精力或技術實力因素，致使這個技術不是很完善，咱們能夠採起變通的方式解決，可是不要消極的看待某種技術，或完全的放棄。我以爲做爲技術人員，應該充分利用現有技術，由於這是用戶投入的一部分，儘量不要爲用戶作主。

聊一下Thin Provisioning使用會帶來哪些潛在的問題！如何規避以及那些更完善的技術廠商所帶來的結果：

容量爆滿：

經過上面圖釋可以看到，每一個主機都得到了一個更大致積卷，這些虛擬體積容量也會呈如今每一個主機的操做系統，正常狀況下，主機會無止境的填滿被本身識別到的空間；會不會有種可能，其中一個主機把磁盤池實際容量給填滿了？答案是：默認狀況下會發生的。而且全部的主機將會出現寫入報錯的信息，如圖：

   上圖是預料中的結果，由於咱們實際的磁盤(5TB)都已經被其中一臺主機填滿了；

一些廠商比咱們更早意識到了這問題。因此，咱們選擇這項是技術要諮詢廠商如何解決這個問題。一部分廠商使用容量限制閥，也就說雖然提供了35TB-LUN給一個主機，固然主機在系統也能識別，可是咱們提早在存儲對這個LUN設置了一個Reserve值，好比是33；哈哈，這下好了，這個主機雖然識別了35TB，但只能使用到2TB；另一部廠商使用優先級的設置，好比以整個磁盤池資源爲基礎，強制多少TB只能是給哪幾個主機使用，而這幾個主機可能運行着關鍵業務。容量爆滿的問題已經解決了。對於有些存儲廠商彷佛沒有作到這麼完善，那也OK，另外建立一個LUN，這個LUN不提供任何服務，只是Standby。一旦磁盤池容量被寫爆，刪掉這個LUN，讓磁盤池多出一部分空間，而後儘快購買磁盤，而且，存儲設備一般會有豐富的預警措施，請善用這一點。

聊一下空間自動回收

   容量寫爆問題，對Thin Provisioning瞭解的工程師彷佛都比較關注，可是，如今聊得話題更應該關注，由於可以解決此問題的廠商真的不多，但不少時候咱們須要解決。

   一個有趣的回憶，在一臺手提電腦，有些時候咱們誤刪除一堆東西，也多是格式化，而文件系統也顯示了空間被釋放，可是爲何第三方軟件仍然可以恢復這些內容呢？閱歷比較豐富的技術人員明白了答案：這些被刪除的文件僅僅是從系統上，由「1」被標記爲「O」，而且告訴文件系統，「O」是可用空間，而實質來說，沒有被覆蓋以前，刪除的內容仍然存在；<固然個人措辭不太嚴謹，請參照權威的詮釋>

   這個問題映射到存儲層會是什麼結果呢？一個10TB-LUN映射給主機A，首先存儲的磁盤池被佔用的空間則是「O」，這是Thin Provisioning的特性，以數據實際佔用爲主。這時候由於某一個測試，主機A把10TB的卷塞滿，此時，磁盤池被佔用的容量是10TB。再過一會，主機A的測試結束，刪除了卷內的臨時數據9TB，而這時，磁盤池被佔用的容量則仍然是10TB，其實，不管主機刪除多少內容，只要10TB卷被填滿過，存儲層的磁盤池就沒法再釋放。問題來了，一個新主機B加入網絡中，須要2TB的容量，而磁盤池將沒法提供任何容量給主機B，而且磁盤池顯然容量可用爲「0」；若是多臺主機已經存在網絡中，那麼其它主機也沒法寫入。但是咱們很須要在磁盤池釋放這些空間，尤爲是更多臺主機。Thin Provisioning的磁盤池在於提升容量的利用率，在此時看來卻與之違背。

      一個好的消息，這個已經能夠解決。一個很差的消息，更多的廠商沒有解決。

   首先，這須要兩部分來操做，第一：在應用主機上面，對已刪除的數據作「Zeroed」—至零操做。我本身的經驗告訴我，目前市場上主流的商業操做系統都會支持。第二：須要在存儲執行「Recycle」—空間回收。兩個操做原理能夠用一個比較恰當的場景：小明向政府租借了10塊地皮蓋房子，而後以爲本身一我的不必住這麼多，就拆掉了9個房子，而後他通知政府，請把9塊地皮拿走吧，我不要了，這時政府行動，收回來了地皮共9塊，分與其它人使用。

   之因此在此前強調，這個空間回收問題重要性，緣由是不少存儲設備不支持Recycle。若是要回收這部分空間，意味必須整個刪掉了LUN；

   結論：在使用Thin Provisioning技術時，請選擇有Recycle功能的存儲，若是環境的系統是vSphere，而且存儲設備支持VAAI，那就太棒了，由於這部分空間能夠自動回收，無需繁瑣的步驟。

那關於空間回收的問題也解決了，除此以外還沒想到Thin Provisioning帶來的其餘問題。

在最後這一部分，我想稱讚Thin Provisioning來了的利益！

   在技術上：早期的文件系統沒法提供更多的便捷性，假如一個卷寫滿了，管理員只能依靠堆積更大的卷組。沒法保證1個TB卷，寫滿後擴容到2TB以此類推，像NTFS的擴展卷同樣來的方便。而龐大的卷組會致使更多的隱患。好比存儲陣列可以對磁盤進行更高級別的保護，那若是卷組下面有的5個卷，其中一個卷產生邏輯錯誤，存儲陣列都沒法幫助管理員。依靠快照技術，可以對每一個捲進行數據回退，可是，對於一個卷組依靠的是5個LUN來說，必須在同一時刻對5個LUN同時執行快照，我嘗試過，若是存儲陣列沒法把5個LUN組合成LUN Group進行快照，而是單獨爲每個LUN作5個快照，不少時候卷組上面的數據庫沒法啓動，可幾乎就是一致性所致使的問題。

   經過Thin Provisioning技術，管理員在第一期規劃就給主機映射一個10TB，或者100TB空間，而無需關心實際容量是否知足？其它主機是否夠用？，在從此容量擴展中，主機管理員不作任何操做，容量自動上浮，更不會產生由於卷擴容帶來的停機。

   不少用戶厭倦了傳統的存儲方式，一個RAID 2TB的空間，若是劃分一顆1TB LUN給主機，那下一個主機接入，只能映射一顆等於或者小於1TB的LUN，而不考慮第一個主機使用率是多少，Thin Provisioning則完美的解決了這個問題。

Thin Provisioning技術使用，磁盤池下面的RAID或者LUN採用最多的則是Striping技術，這無疑爲每一個卷的IO增長了Spindle's，主機的應用程序會直接獲益，減小IO隊列，提升性能。

   提供利用率，資源靈活分配，動態遷移等等好處還真是很多，關鍵在於除去節省用戶的投資，沒有用戶規劃週期是當前到下一個季度，一般是2年，3年，或是5年。爲了後期兼容性及平滑融入環境，用戶一般會一次性投入，好比年數據量增加是100TB，那麼3年的規劃就300TB的一次性投入。經過Thin Provisioning技術能夠先投入100或50TB，而每一個主機早早的得到了一個300TB的空間，受益於虛擬化技術，後期可以平滑的接入存儲設備，無需考慮兼容性，磁盤池屏蔽了主機與存儲子系統的交互，擴展變得更隨意。還記得最先說起的「V」公司嗎？IBM早在01年，經過Resell<轉售>「V」公司的產品，使數以萬計的IBM存儲用戶下降採購成本，提升購買力。HDS公司則是直接採用OEM合做方式，讓用戶直接獲益................

    由此看來，Thin Provisioning是存儲界偉大的技術發明之一！