談談存儲重刪壓縮的實現-EMC,HDS篇

摘要：上一期咱們談到了重刪壓縮的基本概念以及在存儲系統中的價值，可是實現重刪壓縮是一個任重而道遠的工做，不少廠商在這條路上沒有熬到黎明。不少國際大廠也在上面載過跟頭。那麼實現重刪壓縮到底有哪些難度，又會對存儲架構帶來什麼衝擊。本期咱們淺淺的談一下。

更多內容，請關注公衆號「new_storage」

1. 從幾則八卦看重刪壓縮實現難度

 

Netapp：有一款全閃存叫作FlashRay，計劃支持重刪壓縮，並且是變長重刪，netapp歷時4年開發，結果卻遲遲沒法Ga，最終整個產品被裁，包括產品總裁也掃地出門跳槽到了Pure Storage。無奈之下，netapp只好本身在FAS上進行改造。FlashRay也成了一個活在PPT裏面的產品。

 

Cisco:思科想擁有整個數據中心架構人儘可知，存儲一直是思科最大的缺陷。2013年，全閃存最火的年代，思科終於下重手4.15億美金收購Whiptail，可是很快2年後，因爲大量的技術問題思科放棄了這款產品也退出了存儲領域。

 

EMC：xtremIo做爲2013年EMC巨資收購的產品如今已經即將銷聲匿跡，在EMC都是整盤存儲計劃裏面，它已經被邊緣化，EMC VMAX和Unity正在補齊重刪壓縮快速的崛起。

從上述幾個例子能夠看出，實現重刪壓縮同時保障性能以及穩定性有多難。仔細數一下業界的starup全閃存公司，可以作到可靠性、性能、效率三者都有所保障的只有pure一家，其他都是存儲大廠。

一個全閃存只要重刪壓縮實現了、性能衝擊小、可靠性有保證就是成功了，不能去奢求太多。這就是我對過去十年全閃存市場的認知。

重刪壓縮實現的難度

重刪壓縮實現難度很大，主要不是因爲重刪壓縮算法的問題，而是如何最小化性能損失，最大化數據縮減比的問題。時至今日，咱們看到HDS、HPE的重刪性能衝擊超過50%，EMC高端全閃存至今不具有重刪能力，足可看出難度。

因爲重刪壓縮帶來的數據長度是可變的，甚至會被重刪掉，對架構的衝擊不言而喻。之前以COW架構起家的EMC/HPE/HDS紛紛卡在這道坎上。

咱們回顧一下重刪壓縮的幾個問題

1， ROW架構相對於COW架構帶來的高級軟件移植、集羣管理等

2， 壓縮後變長的數據組合與分配的問題

3， 重刪壓縮帶來的元數據空間和指紋空間增大，從而影響性能

4， 垃圾回收問題

不用ROW，照樣實如今線壓縮，硬盤實現壓縮，HDS獨一家

在咱們悶頭尋找解決方案去實現一個新的存儲軟件架構來實現壓縮重刪的時候，咱們能夠質疑一下咱們的命題。不實現ROW架構是否能夠實現壓縮重刪。

答案是確定的。

好比說，咱們將咱們的壓縮功能在盤上實現。這就是HDS的應對之道。

 

HDS 雖然出售了硬盤業務，可是日立硬盤的部分技術仍是繼承了下來，2015年推出的FMD DC2中實現了在線壓縮功能。可是因爲壓縮後總共能夠對上層提供的容量是不肯定的，所以HDS作了以下底層改造。

1， 使用FMD的RAID組只能用於Pool一級，不能直接做爲LUN對主機提供業務。用戶來設定數據縮減比，來決定POOL能夠對外呈現的容量。通常這個比例爲1.5~2:1.

 

2， 必須實時監控數據的使用比例，一旦超出某個閾值就會進行告警。HDS默認是70%進行警告，80%啓動耗盡預警，90%啓動即將耗盡緊急預警。三級警告機制，催促客戶進行擴容或者刪除部分數據。

 

HDS的實現很是簡潔明瞭，對原有的架構幾乎 任何衝擊，帶來的性能影響也很是小。在最新一代的VSP F800存儲上，咱們能夠看到他的表現，開啓壓縮後性能降低不超過5%。真實一個很是天才的實現方案。

硬件加速減小性能損耗

HDS這種直接從盤上解決問題的方案不是誰家均可以模仿，畢竟沒家存儲廠商的能力都不同，不少廠商都沒有硬件能力，更別說本身造盤了。

  

HPE的硬件實力也是槓槓的，既然ROW我實現的比較差，我能夠用我賴以成名的ASIC來幫幫忙，HPE就採用了ASIC來進行了重刪數據計算和指紋比對。不過因爲ROW這個課題太難，即便用了ASIC HPE表現也是很艱難。

IBM收購TMS後苦於他沒有重刪壓縮功能，採用本身的SVC存儲虛擬化網關做爲機頭來組合成的產品Flashsystem V9000,可是很遺憾SVC的壓縮繼承自HDD時代，IBM的SVC CPU能力也有限，開啓壓縮後性能降低極大。IBM所以加入了壓縮加速卡，大幅減小了CPU損耗。

EMC VMAX秉承的理念一直是老樹發新芽，將原來用於遠程複製鏈路傳輸時壓縮的硬件加速卡用於當前的存儲數據壓縮，也算髮揮餘熱了。

EMC VMAX軟件巧手設計

EMC VMAX的傳統資源分配方案是基於HyperVolume,在十幾年前已經實現了RAID2.0架構，良好數據管理結構爲不少功能實現打好了良好的架構基礎。

 

先將物理硬盤切成多個小disk，稱之爲Hyper Volumes，而後再用Hyper Volumes組成RAID，建立主機可見的LUN。

 

在傳統VMAX上，全部的LUN默認的track size都是128KB，就是說最小的資源分配單元是128KB。

在壓縮需求須要實現後，EMC只作了一個很小的改動就搞定了。

1， 將之前的一個盤切成16個hyper volume的模式作了改變，改爲了切分爲64個，而後針對每一個hypervolume組設置不一樣的track size，16K、32K\48K一直到72K不等，每一個不一樣的track size默認準備一個hypervolume的LUN組，64K默認準備2個，其餘的都設置爲128KB。

2， 因爲軟件架構設計的下盤IO大小爲128K,因此數據在壓縮後只會比128k小，從8KB到128K不等，大多數都是在72K如下。按照壓縮後的塊大小挑選對應的hypervolume組進行下盤。若是某個規格的hypervolume用完了，就從默認的剩餘hypervolume組裏面取一個出來，將track size改爲對應的塊大小便可。

 

這個兩個動做執行後，超級完美的避免了壓縮後塊大小不一致帶來的數據拼接問題，由於數據拼接帶來的性能損耗在容量增加之後很是可怕，可能會帶來50%以上的額外cpu消耗和時延成倍的增長。

到此還不算完，EMC更精巧的還在後面。因爲VMAX主要承載客戶關鍵業務，性能的穩定性是第一須要保障的，所以EMC推出了Activity Based Compression (ABC) 機制。簡單來講就是熱數據不壓縮，直接下盤，直接讀取，不用通過壓縮和解壓縮流程。這個思路咱們你們都能想到，可是EMC不同得是，將本身分層存儲（FAST）的熱點計算功能直接完徹底全的繼承了過來，根本不用添加額外的大的改動。

 

業務開始運行的時候全部數據都被壓縮，在運行一段時間後，啓動熱點識別和標記熱點，今後以後凡是熱數據的寫入和讀取將不會通過壓縮和解壓縮流程。同時按照最著名的28原則，熱數據量被強制鎖定爲LUN空間的20%。對總體的數據縮減率沒有太大的影響。這個就意味着在很長一段時間內大部分的數據讀寫都是不壓縮的。性能獲得了大大的保障。根據EMC的最佳實踐顯示，開啓壓縮在數據庫場景IOPS降低大概只有10%左右，CPU利用率也僅僅多耗了7%，固然CPU消耗主要是因爲硬件壓縮的卸載緣由。

 

因爲EMC的壓縮熱點識別須要一個過程，而且熱數據被設定爲LUN的20%，因此使用EMC的壓縮功能壓縮率會從一開始持續的降低。由於一開始全部數據都會被壓縮，後續不少數據被標記爲熱數據，不斷地從壓縮區釋放出來變成非壓縮數據。因此買了EMC VMAX存儲的客戶要作好壓縮率持續降低的苦。

 

不過總的來講EMC的架構師很是的牛逼，在不推翻原有架構的狀況下，快速簡單的實現了一個性能良好，壓縮比不錯的在線壓縮功能，而且規避了大量壓縮的性能陷阱（容量增加、數據合併），是很值得咱們中國存儲廠商學習的。

可是EMC的方案也有缺點，那就是實現全局重刪很差實現，由於當前數據按照壓縮後的數據塊大小進行分離，後續若是想實現全局重刪則須要進行頻繁的數據搬移。若是僅僅實現LUN級別的重刪，EMC可能會很快推出，可是估計重刪比頗有限，由於每一個重刪的做用域過小了。

其餘廠商既然可以在主流全閃存市場分一杯羹，也有其獨特的實現，咱們下一篇再來討論其餘廠商的實現方式。