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

標籤：cpu   開啟   top   color   clear   關聯性   流程   yellow   處理   

淺談儲存重刪壓縮之三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”

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