摘要：上一期我們談到了重刪壓縮的基本概念以及在存儲系統中的價值，但是實現重刪壓縮是一個任重而道遠的工作，很多廠商在這條路上沒有熬到黎明。很多國際大廠也在上面載過跟頭。那麼實現重刪壓縮到底有哪些難度，又會對存儲架構帶來什麼衝擊。本期我們淺淺的談一下。
更多內容，請關注公衆號“new_storage”
從幾則八卦看重刪壓縮實現難度
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可能會很快推出，但是估計重刪比很有限，因爲每個重刪的作用域太小了。
其他廠商既然能夠在主流全閃存市場分一杯羹，也有其獨特的實現，我們下一篇再來討論其他廠商的實現方式。