星期一, 3月 10, 2014

在Nexenta上使用『Data Dedup/Data deduplication/重複資料刪除 』心得

去年伺服器全面虛擬化,便開始找出如何讓儲存設備使用最佳化。最常見的Data Tierring (Hierarchical storage management)成熟度沒有想像中高,看看 2010年的 自動分層儲存技術走入主流應用 ,似乎也只有EMC與HDS這種天價等級有做到。另一個對價格有直接影響的就是重複資料刪除 ( Data deduplication ,以下簡稱Dedup)。
重複資料刪除以切割的細度來說可分為File Level dedup與Block Level Dedup,當然是Block Level做到的會更小。若以處理時間來分可以即時dedup (inline dedup)與批次dedup (post dedup),其他的區法就不在此深究。

我詢問過NetApp與EMC,NetApp使用post dedup,EMC有inline dedup;但是共同點都是天價收費,而且硬碟還得向他們買。而Nexenta Community版有18TB RAW容量可用,而且Cache 與Spare不算容量。

雖然無幸使用到NetApp,幸好有高手可問,得知NetApp的長處是在NFS。所以我就用 Nexenta 模擬類似狀況,開一塊NFS Share,在其上開啟 Deduplication ,將重覆性高的 ISO與 VM Template放置其中。因為 Nexenta用的技術是ZFS Deduplication ,所以是Block Level Dedup ,缺點就是會使用較多的RAM儲存。根據這裡的說法,開1TB Dedup大概需要32GB的實體記憶體,但實際的數據與Block Size有關,可以看Oracle的How to Determine Memory Requirements for ZFS Deduplication

為何我不用 iSCSI target試呢?當然有試過,但一點意義也沒有。原因很簡單,ESXi在分割iSCSI Target時使用了固定的大小,除非刻意超量設定 iSCSI target (也就是設成thin provision,在create iSCSI target時設Initial Reservation為No),但這種狀況在Nexenta的效能並不是很好,而且很難預估量,所以後來改用NFS測試。

看一下在DataSet的使用量:
再看Share的使用量:
在DataSet看到使用146GB,但是在Share卻看到使用156GB,可能和開啟Compression有關。

至於存取速度,由於我沒有放SSD加速,所以只能說一般,但是也不會慢到無法接受,Nexenta內建的cache機制仍然存在。

但是在Summary Information裡可以看到,資料類似幅度也不小的情況,Dedup Ratio只有 1.07,除非是使用者放了完全相同的資料,否則Dedup的效率並不高。

結論是: 沒事就不需要用Deduplication,除非你可用的容量太小,而且有非常大的RAM

沒有留言: