淺談存儲重刪壓縮之三netapp的逆襲
摘要：上一期我們回顧了HDS硬盤壓縮以及EMC在老架構上改進的設計，本期我們主要來看看命運多舛的Netapp如何更新自己的重刪壓縮。
謝謝大家的關註和支持，歡迎轉載，轉載請註明出處。
歡迎大家關註“new_storage”
Netapp重刪壓縮的歷史
Netapp實現重刪壓縮很早，造2010年之前，netapp的NAS設備已經具備了重刪壓縮的能力。當時全球市場一直將重心放在HDD存儲，而netapp實現重刪壓縮也很能理解，當時有很多溫冷數據存儲在netapp上，所以重刪壓縮是一個增加附加值的功能。但是很遺憾，這個功能並沒有幫助netapp獲取多少市場，而是統一存儲這種架構在
Netapp ONTAP 8.3之前的實現
Netapp老的壓縮實現是以壓縮率優先的原則，因此壓縮的壓縮作用域設置為32KB，然後會進行壓縮，如果壓縮率低於25%也就是壓縮出來的塊依然大於24K就會放棄壓縮。壓縮最小可以壓縮到4kB。對於不可壓縮的塊在後臺壓縮中進行繼續壓縮。對於小於32KB的IO，在線壓縮會跳過他。
同時，netapp支持後處理的壓縮。
對於重刪的實現，netapp老版本只支持後重刪，只是會在數據實時下盤時候就進行了指紋的計算，然後加入到記錄指紋的一個日誌文件。
等到後臺重刪被觸發後則啟動重刪流程。然後執行跟傳統重刪一樣的操作，指紋查找，有重復則進行逐字節比對，然後進行數據刪除的操作。
Netapp老版本限制較多：
1， 壓縮必須和重刪一起使用，不能單獨使用壓縮功能
2， 只有使用了後壓縮以及重刪，才能開啟在線壓縮。
3， 同一臺存儲內，最多8個卷同時開啟重刪或者壓縮
從這三個限制可以看出，netapp對於壓縮重刪的性能是非常保守的。而且在白皮書中也指出了這一點。
Netapp指出，在1個LUN重刪時對性能影響《15%，但是8個LUN同時開啟重刪時影響則為15%~50%。
對於在線處理的壓縮而言，如果系統負載在50%以下，開啟壓縮CPU利用率會上升約20%，對於大於50%以上業務壓力的系統，netapp不建議使用在線壓縮功能。
後壓縮和後重刪機制對於
新版本快速優化
Netapp新版本主要的優化在壓縮，拋棄了原有的壓縮架構，因為原有的壓縮主要用於文件系統，壓縮域比較大，需要多個數據塊進行合並壓縮。合並壓縮意味著每個快需要等待多個快合並在一起才能去壓縮。
Netapp的san存儲塊大小是4KB，因此在新版本netapp壓縮以4KB為單位，壓縮成1K~4KB的小塊。壓縮效果還是有個預判機制，壓縮率》50%才會壓縮，否則不壓縮。這個改動使得壓縮效率提升了很多，但是同樣的壓縮率很低。
為了改善壓縮率，netapp在該版本新增了一個功能，國內叫做壓緊。將多個小塊合並成一個4KB的塊來存儲。這個操作很有效，畢竟每個快的元數據只存儲一個地址和偏移量，壓緊不會增加任何元數據的開銷，只是需要刷新一下原來的元數據即可。
這麽簡單的一個操作解決了大量空洞的問題，同時還提升了資源利用率。但是由於netapp壓縮機制本身簡化帶來的壓縮率下降（壓縮域太小），所以netapp本身的壓縮時犧牲了壓縮率，提升了性能。可取之處就是壓緊的處理。壓緊過程還會處理一些之前沒有做壓縮處理的塊，因此壓緊還有一定性能開銷，按照netapp的說法大概在5%左右。
Netapp的重刪改動比較大，主要在於元數據指紋的存儲機制以及改成了支持在線處理和後處理兩種。
重刪的粒度和原來一樣還是4KB，但是存儲機制已經變化了。
1， 所有指紋數據僅僅在緩存中存儲一份，不做持久化，不需要考慮鏡像什麽的，在重啟和升級過程中，指紋會被丟棄。這麽做的原因就是相對於犧牲性能，我們寧願犧牲重刪率。那麽我們就可以大幅降低因為指紋和盤的交互以及指紋持久化帶來的內存開銷，鏡像開銷等等。所以對於希望實現重刪的國產廠商，我的建議是：重刪的指紋不需要持久化，不需要鏡像，如果是升級或者重啟，建議還是存到硬盤上一份，但是不需要實時下盤。只需要在掉電和重啟等操作時下盤即可。Netapp當前並未做重啟升級以及掉電時候的指紋保護，我覺得這一點並不好。
2， 指紋按照熱度進行淘汰，一旦指紋空間滿了，就采用最簡單的LRU算法進行淘汰。這也是一個保持指紋查找高效的方式，可以保證指紋全內存。這個也是值得學習的。
當然上述兩個對於指紋的改造其實還有一個提前需要解耦的東西。很多廠商在實現重刪的時候講引用計數和指紋在一起存儲，就需要進行解耦才能更好的實現。
這也讓我們需要反思後續的數據結構設計需要將數據按照持久化級別進行分離，而不是按照數據的關聯性進行合並。隨時保持架構的靈活性。
當然，netapp其實可以做的再好一點，比如說將指紋表最熱部分緩存一份到L1 Cache,並且改變數據結構為hash，對性能的影響會更小，其他的全量指紋則放在L2 Cache再用B樹存儲來節省空間。這樣可以讓重刪更加靈活，如果業務壓力大則只在L1 Cache進行查找。
題外話，當前客戶對於重刪還是有很多顧慮，很多人認為重刪會導致數據丟失的風險。所以我們不可避免的都需要做逐字節比對，在這種情況下，netapp給我們做了一個很好的表率，那就是我們使用弱哈希，節省指紋表空間，擴大指紋數。這個也是可取之處。使用強哈希不做比對的廠商未來根本沒法在市場上被接受。
Netapp全閃存卷土重來
在2015年之前在SAN領域netapp就是一個落後者，在全市場領域更完全是個失敗者。但是通過2016/2017年的持續優化，竟然翻身了，非常讓人不可思議。
其實他只做對了一件事，將壓縮重刪實現了，同時開啟後性能下降在可控範圍內（5%~20%）。就這麽一條，就讓netapp如今在全閃存市場逆勢上揚。
所以重刪壓縮不做或者做不好，未來將會走向泥潭。
重刪壓縮是個錦上添花的東西，絕對不是雪中送碳。IT市場的寫標能力是技術的天敵。此外技術的市場化也是需要很長的孕育，至少在中國區接受重刪壓縮就可以少配容量的事情還需要很長時間。
謝謝大家的關註和支持，歡迎轉載，轉載請註明出處。
歡迎大家關註“new_storage”
淺談存儲重刪壓縮之三netapp的逆襲