淺談存儲重刪壓縮之三netapp的逆襲

淺談存儲重刪壓縮之三netapp的優化

摘要：上一期咱們回顧了HDS硬盤壓縮以及EMC在老架構上改進的設計，本期咱們主要來看看命運多舛的Netapp如何更新本身的重刪壓縮。

謝謝你們的關注和支持，歡迎轉載，轉載請註明出處。

歡迎你們關注「new_storage」

 

Netapp重刪壓縮的歷史

Netapp實現重刪壓縮很早，造2010年以前，netapp的NAS設備已經具有了重刪壓縮的能力。當時全球市場一直將重心放在HDD存儲，而netapp實現重刪壓縮也很能理解，當時有不少溫冷數據存儲在netapp上，因此重刪壓縮是一個增長附加值的功能。可是很遺憾，這個功能並無幫助netapp獲取多少市場，而是統一存儲這種架構在2010~2014年在全球大行其到，成爲中端存儲的標誌卻是讓人很是意外。

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不建議使用在線壓縮功能。

      後壓縮和後重刪機制對於SSD爲主的全閃存存儲來講不知道是否會帶來過量的寫入而致使SSD快速磨穿，這個問題還有待驗證。

新版本快速優化

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」