IBM存儲重刪壓縮技術分析（一）

題記：IBM雖然硬體部分持續在下滑，在項目中也很少遇到了，但是IBM的技術優勢還是依然保持著。看完IBM的壓縮實現，你真的可以感覺到一股技術力量，架構設計和代碼實現值得國內廠商學習。

在開始分析之前，我們先要隆重的介紹一下IBM的全快閃記憶體家族，他是所有存儲廠商中全快閃記憶體家族僅次與EMC的。

從中低端的V5000F、V7000F，到中高端的Flashsystem 900，V9000,A9000,A9000R一直到高端的DS8880F。全系列覆蓋。同時還具備大數據分析用的Elastic 存儲型伺服器，超融合和cisco合作的VersaStack。

IBM壓縮第一步，SVC配合實現

時針往回撥到2012年國慶節，我們正在放假，IBM在全快閃記憶體最火的年頭，收購當時比較紅火的全快閃記憶體廠商TMS（Texas Memory Systems），拉開了IBM踏入全快閃記憶體的序幕。TMS是一個製造SSD起家的廠商，所以它提供了一個低功耗、高性能的存儲系統。使用定製的PCIe SSD來對外提供業務。

TMS 2011年參加了SPC-2測試很不錯，大概是接近9GB/s的帶寬，在今天這個成績都是可以傲視一堆廠商。

不過和當時很多全快閃記憶體廠商一樣，TMS作為一個初入企業存儲領域的廠商，沒有任何的存儲功能，只有最基本的SAN功能和RAID功能。所以他們都一股腦的去提升性能想在HPC等對於可靠性和數據服務要求不高的場景發展。幸好被IBM收購了，不然今天估計早都屍骨無存。

現在還活著的那一批快閃記憶體存儲挑戰者中，沒有發展企業存儲數據服務能力只有TMS一家，其他人要麼補齊，要麼死掉。

IBM收購了TMS也面臨同樣的問題，IBM先對TMS的產品做了改造，發布了自己的第一個Flashsystem 840.這款產品性能極佳，具備了企業存儲所需的FC介面和10Ge iscsi介面，可以滿足資料庫等關鍵場景低時延高性能的要求。由於沒有任何增值，這款產品主要通過IBM的諮詢能力在全球的大型數據中心做加速，我在中國區去年還看到單獨銷售FLashsystem的案例，就是用於全快閃記憶體加速，恐怖的性能去打到別人。一個雙控的盒子要求100萬IOPS.不過這種獨立形態不是常態化的東西。

為了組合銷售FLashsystem，IBM做了很多方案，在GPFS中作為一個單獨節點，或者可以被SVC虛擬化接管，或者掛在中端存儲V7000下面，反正掙了很多的方案。但是由於一直遊離在其他軟體之外做的軟集成，客戶採購存儲又是單獨採購，所以一直很不爽。

不過作為解決方案大師，這個難不倒IBM，很快基於IBM SVC和FlashSystem的新一代900組合產品出現了。他就是Flashsystem V9000.

其中增值軟體都是由SVC軟體來進行提供，確保可以在企業存儲上被客戶接受並且接受來自於其他廠商的挑戰。

IBM V9000具備基本的企業級特性，包括Scale-out、精簡配置、在線壓縮、分級存儲、存儲虛擬化、精簡拷貝等多個功能，我們重點關注則是他的數據縮減相關。

IBM V9000對外默認承諾2：1的數據縮減，沒有超過2:1不用去進行評估，這是一個很有挑戰的評估，我們知道在很多場景其實數據縮減比根本達不到2：1，比如說文件共享、比如說伺服器虛擬化裡面一些數據類型。

當然有一個很有趣的事情，IBM的V9000具備兩個壓縮license，其中一個叫做Real-time Compression功能，用於在V9000上的FS900的存儲空間開啟壓縮，包含在基礎license裡面。另一個SVC Real-time Compression壓縮license則用於對於異構接管以後的LUN實現壓縮功能。

SVC的壓縮實現

壓縮主要都是基於滑動窗口機制，來進行壓縮，而主流的全快閃記憶體廠商在壓縮前會將數據塊切成等效大小的塊，比如說8KB、16KB，然後進行壓縮。IBM認為這種方案有個不好的地方，就是塊大小如何設置都有壞處：如果塊大小設置設置大了，每次的小塊更新會整塊解壓縮，如果設置的塊小了又會影響壓縮率。

這個問題IBM的看法也不一定對，因為一般我們讀取硬碟或者SSD的最小單位是4KB大小，其實也不見得會有問題，如果按照4KB進行對齊了。還是可以的達到一個比較好的性能，畢竟讀取2KB和讀取4KB是一樣的性能。但是對於大塊修改一個小部分卻是有這個問題。因此一般的全快閃記憶體壓縮演算法都不會把塊做的太大，防止出現小的改寫需要整塊解壓讀取再寫入的操作。EMC是個奇葩，他的設計規避了這個問題，我們不去討論他。

IBM說我反其道而行之，我每次的壓縮塊都是不定的，但是我壓縮出來的塊都是固定的，這樣我就沒有這麼多的合併操作以及數據塊讀取的不便問題，未來只要有數據讀取就讀取其中的一個塊就行。還避免了垃圾回收的複雜度，到時候我只需要插空寫入即可。

對於IBM的這種操作我只能說有好處也有壞處，好處是沒有任何碎片整理問題，所有的空閑空間都是整齊的標準塊大小，壞處是，塊不一定是對其的，因此有可能我們需要對某個小IO操作，他剛好跨越兩個塊。這樣就產生了寫放大，如果我們需要對這個塊進行改寫就需要將兩個塊進行重寫。

當然我猜測：IBM肯定做了某些處理，來確保物理塊壓縮後不會跨壓縮塊，確保沒有寫放大。這個其實也比較簡單，可以一個一個的塊為單位進行滑動窗口壓縮。

傳統壓縮演算法是不管你這個塊寫的是什麼數據我就直接壓縮，有的壓縮率很大有的壓縮率很小，對於壓縮率很小的數據其實壓縮收效甚微並且需要正常的消耗CPU和內存，所以很多廠商都會做一個壓縮嘗試，比如說netapp對於壓縮率高於50%的數據不壓縮。

IBM也引入了這個機制，稱之為預判決機制（Predecide mechanism），具體的判決演算法是從一個大塊中找出一部分小塊進行壓縮嘗試，如果壓縮率過低則標記為不壓縮。這種判斷可以快速的定義一個快，減少資源消耗，但是這種判斷也有一定的概率出錯，如果剛好找到的那塊檢驗數據是不能壓縮的，而其他沒有檢驗的數據都能壓縮。不過總的從概率上說，這樣還是可以將大多數不可壓縮的場景排除掉，從而提升性能。

IBM的壓縮每個壓縮塊都是由多個獨立的寫IO組合而成。假設一個應用程序同時寫入多個數據，很大程度上這些數據之間關聯性會比較高，如果和關聯性比較高的數據一起壓縮效率更好。但是這些數據可能並不是物理上相連的數據。所以傳統的壓縮被稱之為基於地址的壓縮。

為了提升壓縮率，IBM提出了一個基於時間的壓縮法，稱之為temporal compression。假如說我們一個同樣的數據需要在應用程序多個地方被同步，在存儲上可能表現為相同或者類似的三個數據在三個不同的位置被寫入，由於地址不連續，因此他們之間的數據重複性並不會在一個壓縮塊的作用域中出現，結果就是三個塊並不能得到很好的壓縮比。如果使用IBM的機制，將時間相同（一般按照Cache中的代次）的幾個數據放在一個作用域，那麼壓縮率可能會帶來明顯的提升。

IBM的壓縮演算法模塊在SVC內部稱之為RACE（Random Access Compression Engine），是在thin provisioning層實現的一個功能。

1，他對上從的所有增值業務都沒有任何的影響，是透明的。

2，分級存儲也可以和壓縮卷同時使用，當前業界我僅僅看到個別廠商的實現了該功能。

3，還支持壓縮卷和非壓縮卷的在線轉化。

從上面這個插件式的架構讓我感受到IBM軟體在設計上的優秀，SVC軟體已經運行了這麼多年，實現一個新的模塊就可以這麼輕鬆，並且可以快速的兼容所有的增值，而且不改變主幹系統代碼架構，對中國廠商真是一個好的教育。

壓縮的處理是在Thin層做的，因此是一個非同步的處理過程，並不會影響IO對於主機的響應。其實相當於SVC內部有兩層Cache，第一層在前端收到IO後丟入一層Cache，然後返回成功。之後再經過一層Cache逐步淘汰到二層cache執行壓縮，組織元數據，然後刷盤。

IBM執行在線非壓縮LUN轉化為壓縮LUN的方案也很奇葩，他有一個在線的卷鏡像功能，並且鏡像功能支持從壓縮LUN創建一個非壓縮LUN的鏡像；或者從非壓縮LUN創建一個壓縮LUN的鏡像，等數據完全同步後再刪除掉原有的LUN，這個轉化過程就做完了。

壓縮率怎麼樣？

看了上面的實現，我理解壓縮率也不會差到那裡去，畢竟HPE實現了重刪加壓縮在虛擬化場景也只敢承諾1.5，而IBM僅僅只有壓縮功能就敢承諾2:1，確實有其過人之處。

可以看出，在很多場景壓縮率都能超過或者接近50%，當然對於Office 2007這個奇葩我回頭要好好研究一下，同樣是Office為什麼升級到了2007就壓縮率這麼差。

後記：本期先介紹了SVC上壓縮的實現方式，主要介紹了壓縮演算法的實現，沒有涉及性能優化的部分下一篇我們來講解一下性能優化的部分。

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！