Data Domain 中涉及的壓縮技術使用最先進的技術來減少客戶資料所需的物理空間。因此，壓縮層級的技術與測量方法都是複雜的主題。本說明文件將討論一些術語、取捨和測量方法，以進一步解釋 Data Domain 系統中使用的壓縮類型、術語和其他壓縮特性。
適用於：
所有 Data Domain 型號
上次更新：2024
年 1 月 壓縮是一種資料減量技術，旨在使用較少的實體空間來儲存資料集。在 Data Domain 系統 （DDOS） 中，我們會執行重複資料刪除和本機壓縮來壓縮使用者資料。重復資料刪除會用於識別備援資料區段，並僅會儲存唯一的資料區段。本機壓縮會使用特定壓縮演算法進一步壓縮唯一的資料區段，例如 lz, gzfast, gz，依此類推。DDOS 中的整體使用者資料壓縮是重複資料刪除和本機壓縮的共同努力結果。DDOS 使用「壓縮率」來測量其資料壓縮的效果。通常，它是用戶數據總大小與壓縮數據總大小或已使用的物理空間大小的比率。
Data Domain 檔案系統是「記錄結構」重複資料刪除檔案系統。紀錄結構檔案系統僅會將資料附加至系統並自行刪除，無法釋放實體空間。這樣的檔案系統仰賴垃圾收集，以回收不再需要的空間。日誌結構文件系統和重複數據刪除技術的特性相結合，使得清楚地瞭解 DDOS 中壓縮的各個方面變得棘手。
對於壓縮，我們可以測量許多方面。在本說明文件中，我們將逐步詳細討論，以協助您瞭解 DDOS 壓縮。首先，我們會說明整體的系統壓縮效果，這能讓我們瞭解在 Data Domain 系統中實現的實際壓縮、使用者資料量、耗用的實體空間量，以及其比例。在本說明文件中，此比率稱為「系統有效壓縮率」。DDOS 會以內嵌方式執行重複資料刪除，並追蹤原始使用者資料區段的統計資料、刪除重復資料後的唯一資料區段，以及本機壓縮對唯一資料區段的影響。這些內嵌式壓縮統計資料可用於測量內嵌式壓縮的效果。可針對每次寫入測量內嵌式壓縮統計資料。此外，DDOS 會追蹤不同層級的統計資料;檔案、MTrees 和整個系統。
本文件的內容可套用至所有 DDOS 版本，直到本文件發佈為止，最高至 DDOS 7.13。不保證所有內容在未來的版本皆正確無誤。在 5.0 之前的版本中，整個系統只有一個 mtree，而且沒有明確指出 mtree 一詞。
系統的整體壓縮效果是以系統有效壓縮率來測量，有效壓縮率是使用者資料大小與已使用實體空間大小的比率。這是由 filesys show compression （FSC） CLI 命令所報告 （使用者介面上也會提供相對應的資訊）。 FSC 的範例輸出如下所示：
# filesys show compression
From: 2023-12-31 03:00 To: 2024-01-07 03:00
Active Tier:
Pre-Comp Post-Comp Global-Comp Local-Comp Total-Comp
(GiB) (GiB) Factor Factor Factor
(Reduction %)
---------------- -------- --------- ----------- ---------- -------------
Currently Used:* 6439.6 113.4 - - 56.8x (98.2)
Written:
Last 7 days 135421.3 1782.0 35.1x 2.2x 76.0x (98.7)
Last 24 hrs 532.5 1.5 334.3x 1.1x 356.5x (99.7)
---------------- -------- --------- ----------- ---------- -------------
* Does not include the effects of pre-comp file deletes/truncates
since the last cleaning on 2024/01/05 11:34:13.
系統有效壓縮率報告於 CLI 輸出中結果區段的第 1 列。此列會在上方反白顯示。用戶數據的總大小標記為“Pre-Comp”。耗用的總實體空間 （資料和中繼資料） 會標示為「Post-Comp」。
「Pre-Comp」和「Post-Comp」的數字皆為在執行階段時讀取。FSC 會以暗示的方法同步處理整個系統，然後查詢這兩個數字。這兩個數字的測量方式與 「filesys show space」命令
相同系統有效壓縮率 = Pre-Comp/Post-Comp
FSC 輸出的其餘部分會說明內嵌式壓縮統計資料，我們將在後面討論。
有些作業可能會影響系統有效壓縮率：
快速複製
從作用中命名空間中的檔案 （而不是快照） 完成快速複製時，即可實現完美的重複資料刪除，因為目標檔案不需要額外的實體空間。快速複製的效果是讓我們增加使用者資料大小，而不需佔用額外的實體空間。這可提高系統有效壓縮率。完成許多快速複製後，系統有效壓縮率可能會十分高。
虛擬合成作業
虛擬合成備份往往會顯示較高的系統有效壓縮率。這是因為虛擬合成會進行邏輯完整備份，但只會將變更或新資料傳輸至 Data Domain 系統。虛擬合成元件對系統有效壓縮率的影響與快速複製類似。
覆寫
覆寫會消耗更多實體空間，但不會增加資料集的邏輯大小，因此覆寫會降低系統有效壓縮率。
儲存稀疏檔案
稀疏檔案包含大型的「孔洞」，這些「孔洞」會計入邏輯大小，但不會因為壓縮而使用實體空間。因此，它們會讓系統有效壓縮率看起來很高。
儲存小型檔案
針對特定的內部中繼資料，DDOS 會為每個檔案增加近 1 KB 的額外空間。當系統儲存大量小型檔案 （小於 1 KB 或為個位數 KB） 時，中繼資料的額外空間會降低有效壓縮率。
儲存預壓縮或預先加密的檔案
壓縮和加密可以放大數據更改的級別，並降低重複數據刪除的可能性。此類檔通常無法很好地刪除重複數據，並降低系統有效壓縮率。
刪除
刪除會減少系統的邏輯大小，但系統在執行垃圾收集之前，不會取得對應的未使用空間。許多刪除的檔案會降低壓縮率，直到垃圾收集 （GC） 執行為止。
垃圾收集 （GC） 或清理
GC 會回收任何檔案不再看到資料區段所耗用的空間。如果最近刪除了許多檔案，GC 可能會降低實體空間的使用量，以提高系統壓縮率。
積極拍攝快照
當我們拍攝 Mtree 的快照時，不會變更資料集的邏輯大小。但是，即使在快照所參考的所有檔案在拍攝後皆已刪除，快照所參考的所有資料區段亦會受到鎖定。GC 無法回收快照仍需要的空間;因此，擁有大量快照可能會使系統有效壓縮率較低。但是，快照是有用的崩潰恢復功能。在需要時，我們絕對應該隨時拍攝快照，或設定適當的快照排程。
DDOS 會在資料寫入系統時進行內嵌式重複資料刪除。它會追蹤每次寫入的內嵌式重複資料刪除和本機壓縮效果，並在檔案層級累積統計資料。每個檔案的內嵌式壓縮統計資料會進一步在 mtree 層級和系統層級匯總。壓縮是根據內嵌式統計資料中的三個數字來測量：
根據上述三個數字，DDOS 可定義兩個更精細的壓縮率：
累積的內嵌式壓縮統計資料是 DDOS 內檔案中繼資料的一部分，並會儲存在檔案 inode 中。DDOS 提供的工具可檢查所有三個級別的內嵌式壓縮;檔案、MTree 和整個系統。我們將在以下各節中詳述這些內容。
3.1 檔案壓縮
您可以使用「filesys show compression <path>」CLI 命令來檢查檔案壓縮，該命令會報告儲存在檔案 inode 中的累積壓縮統計資料。指定目錄時，會加總並報告該目錄下所有檔案的內嵌壓縮統計資料。在 CLI 輸出中，raw_bytes 被標記為「原始位元組」;pre_lc_size標記為「全域壓縮」;post_lc_bytes標示為「本機壓縮」;其他開銷報告為「元數據」。這兩個範例是從實際的 DD：
Example 1 擷取而成：檔案的內嵌式壓縮統計資料
# filesys show compression /data/col1/main/dir1/file_1
Total files: 1; bytes/storage_used: 7.1
Logical Bytes: 53,687,091,200
Original Bytes: 11,463,643,380
Globally Compressed: 4,373,117,751
Locally Compressed: 1,604,726,416
Meta-data: 18,118,232
範例 2：目錄下所有檔案的內嵌式壓縮統計資料，包括所有子目錄
# filesys show compression /data/col1/main/dir1
Total files: 13; bytes/storage_used: 7.1
Logical Bytes: 53,693,219,809
Original Bytes: 11,501,978,884
Globally Compressed: 4,387,212,404
Locally Compressed: 1,608,444,046
Meta-data: 18,241,880
系統在上述 CLI 輸出中將整體內嵌式壓縮率報告為「位元組/storage_used」。 不過，解譯上述資訊時必須小心謹慎，因為它可能會因為各種原因而產生誤導。原因之一，是 pre_lc_size 和 post_lc_size 是在處理資料操作時所紀錄的。刪除原先新增這些區段的檔案時，應增加剩餘檔案中唯一資料區段的數量。
舉例來說，假設檔案 sample.file 備份至 Data Domain，在第一次備份時，檔案的壓縮資訊為 pre_lc_size=10GiB，post_lc_size=5Gib。
接下來，假設此文件的數據是唯一的，沒有與任何其他文件共享數據。在檔案的第二次備份中，會進一步假設檔案會取得理想的重複資料刪除，因此 pre_lc_size 和 post_lc_size 皆應為零，因為檔案的所有區段已存在於系統上。刪除第一個備份時，檔案的第二個備份會成為唯一參考 5 GiB 資料區段的檔案。在這種情況下，在理想情況下，第二次備份中的檔案pre_lc_size和post_lc_size應分別從 0 更新為 10 GiB 和 5 GiB。但是，無法偵測應針對哪些檔案執行，因此現有檔案的內嵌式壓縮統計資料維持不變。
影響上述數位的另一個因素是累積統計數據。當檔被大量覆蓋時，無法跟蹤累積統計資訊在多大程度上反映了引入實時數據的寫入。因此，在很長一段時間內，內嵌式壓縮統計資料只能視為一種啟發式方法，以粗略估計特定文件的壓縮程度。
另一個值得強調的事實是，無法在任意時間間隔內測量檔的內聯壓縮。檔案內嵌式壓縮統計資料是累積的結果，涵蓋了檔案所收到的所有寫入。當檔收到大量覆蓋時，raw_bytes可能遠遠大於檔的邏輯大小。對於稀疏檔，檔大小可能大於“原始位元組”。
3.2 MTree 壓縮
我們可以使用 "mtree show compression" （海珊賽）CLI 命令。內嵌式壓縮統計資料的絕對值會在 MTree 的整個生命週期中累積。考慮到 MTree 的使用壽命可能長達許多年，隨著時間的推移，這些值的資訊會變得越來越少。為了解決此問題，我們只會使用內嵌式壓縮統計資料的變更量 （delta），並且只會針對特定時間間隔進行報告壓縮。其基本方法是定期將 MTree 內嵌式壓縮統計資料傾印至記錄檔。當用戶端使用 MSC 命令查詢 MTree 壓縮時，我們會使用記錄來計算壓縮報告的數字 delta。默認情況下，MSC 報告過去 7 天和過去 24 小時的壓縮，但可以指定感興趣的任何時間段。
為了進行示範，假設 MTree A 使用下列記錄：
3:00AM, raw_bytes=11000GB, pre_lc_size=100GB, post_lc_size=50GB 4:00AM, raw_bytes=12000GB, pre_lc_size=200GB, post_lc_size=100GB
那麼此小時的 MTree A 壓縮為：
g_comp = (12000-11000)/(200-100) = 10x l_comp = (200-100)/(100-50) = 2x overall compression ratio = (12000-11000)/(100-50) = 20x
上述壓縮率計算對數據集大小沒有任何作用。例如，上述 mtree 可能只有 500 GB 的邏輯資料。
MSC 支援“每日”和“每日詳細”選項，“filesys show compression”命令也是如此。指定「每日」時，命令會以行事曆的方式報告每日壓縮。它會使用每日的 raw_bytes 和 post_lc_size 來計算每日壓縮率。指定「每日詳細」時，該命令顯示每天的所有三個增量（分別為raw_bytes、pre_lc_size和post_lc_size）;它還計算g_comp和l_comp以及總壓縮因數。
附錄中提供這些系統的範例輸出結果。
3.3 系統壓縮
瞭解 MTrees 如何報告壓縮之後，我們可以將此概念直接延伸至整個系統。全系統壓縮內嵌式統計資料的收集和報告與 MTrees 完全相同。唯一的區別是範圍，因為其中一個是特定於 MTree 中，另一個則針對整個系統。您可以使用「filesys show compression」命令來檢查結果此範例請參閱第 2 節。FSC 輸出結果區段的最後兩行會報告「過去 7 天」和「過去 24 小時」的系統壓縮。
在已實作雲端層的 DD 上，儲存裝置會分為使用中階層和雲端層，這是兩個獨立的重複資料刪除網域。使用者只能將資料注入使用中的階層。之後，DDOS 資料移動功能可用於將資料從使用中階層遷移到雲端階層。因此，空間和壓縮測量與報告會在每個層級中獨立處理。但在文件級別，我們不按層進行區分並報告內嵌壓縮統計資訊;它們與我們在第 3.1 節中描述的完全相同。
最後一個要強調的主題是重複資料刪除的一些特性，在許多 Data Domain 檔中稱為「全域壓縮」。雖然它包含“壓縮”一詞，但它與傳統的壓縮概念完全不同，DDOS 也以“本機壓縮”的名稱提供壓縮
。本地壓縮使用特定演演演算法減小數據片段的大小（某些類型的數據不可壓縮，對它們應用壓縮演演演算法可能會略微增加數據大小）。通常，一旦確定了演演演算法，數據本身就是壓縮率的唯一因素。
然而，重複資料刪除則不同，它不適用於本機概念，而是「全域」的概念。傳入的資料區段會針對重複資料刪除網域中的所有現有資料區段進行重復資料刪除，其中包括非雲端 Data Domain 系統上的所有資料。在重複資料刪除過程中，資料區段本身並不重要。
實際上，我們很少在數據集的初始備份中看到高重複資料刪除率。在初始備份中，主要的資料減量通常來自於本機壓縮。後續備份到達 Data Domain 時，重複資料刪除會展現其優勢，並成為壓縮的主力。重複資料刪除的有效性取決於資料集在備份與備份之間的變更率較低。因此，無法針對具有高變更率的資料集進行完善的重復資料刪除。當備份應用程式以高頻率將自己的中繼資料區塊 （Data Domain 稱為標記） 插入備份映像時，可能也無法取得良好的重複資料刪除率。我們的標記處理技術有時會有所説明，但並非總是如此。
鑒於這些觀察結果，我們可以期待什麼？
在重複資料刪除的檔案系統中衡量壓縮很困難，但在日誌結構的重複資料刪除文件系統中卻更難。我們必須瞭解重複數據刪除的工作原理以及如何跟蹤壓縮統計資訊。壓縮率是瞭解特定系統行為的實用資訊。系統有效壓縮率是最重要、最可靠，且可提供最多資訊的測量方法。內嵌式壓縮統計資料也很實用，但在某些情況下可能僅能視為異質。
附錄：以下項目的範例輸出： "mtree show compression" 命令
：假設有一個包含 254792.4 GiB 資料的 MTree。它在過去 7 天內收到了 4379.3 GiB 的新數據，在過去 24 小時內收到了 78.4 GiB （可以指定其他時間間隔）。「每日」選項會報告過去 33 天的內嵌式壓縮統計資料。提供「每日詳細資料」選項時，總壓縮率會進一步細化為全域和本機壓縮率。
Mtree 清單輸出：
# mtree list /data/col1/main Name Pre-Comp (GiB) Status --------------- -------------- ------ /data/col1/main 254792.4 RW --------------- -------------- ------ D : Deleted Q : Quota Defined RO : Read Only RW : Read Write RD : Replication Destination IRH : Retention-Lock Indefinite Retention Hold Enabled ARL : Automatic-Retention-Lock Enabled RLGE : Retention-Lock Governance Enabled RLGD : Retention-Lock Governance Disabled RLCE : Retention-Lock Compliance Enabled M : Mobile m : Migratable
# mtree show compression /data/col1/main
From: 2023-09-07 12:00 To: 2023-09-14 12:00
Pre-Comp Post-Comp Global-Comp Local-Comp Total-Comp
(GiB) (GiB) Factor Factor Factor
(Reduction %)
------------- -------- --------- ----------- ---------- -------------
Written:
Last 7 days 4379.3 883.2 3.4x 1.5x 5.0x (79.8)
Last 24 hrs 784.6 162.1 3.3x 1.4x 4.8x (79.3)
------------- -------- --------- ----------- ---------- -------------
使用「每日」選項：
# mtree show compression /data/col1/main daily
From: 2023-08-12 12:00 To: 2023-09-14 12:00
Sun Mon Tue Wed Thu Fri Sat Weekly
----- ----- ----- ----- ----- ----- ----- ------ -----------------
-13- -14- -15- -16- -17- -18- -19- Date
432.0 405.9 284.1 438.8 347.0 272.7 331.4 2511.8 Pre-Comp
85.5 66.2 45.3 81.9 61.4 57.4 66.3 464.1 Post-Comp
5.0x 6.1x 6.3x 5.4x 5.7x 4.7x 5.0x 5.4x Total-Comp Factor
-20- -21- -22- -23- -24- -25- -26-
478.0 387.8 450.2 533.1 386.0 258.4 393.6 2887.1
100.6 81.5 100.8 119.0 84.0 40.6 75.3 601.8
4.8x 4.8x 4.5x 4.5x 4.6x 6.4x 5.2x 4.8x
-27- -28- -29- -30- -31- -1- -2-
27.6 1.0 0.4 470.7 467.3 517.7 641.9 2126.7
4.9 0.2 0.1 83.9 92.3 89.8 140.1 411.2
5.6x 5.6x 4.3x 5.6x 5.1x 5.8x 4.6x 5.2x
-3- -4- -5- -6- -7- -8- -9-
539.6 495.0 652.8 658.7 537.1 398.7 305.5 3587.3
110.8 108.0 139.4 137.0 111.5 78.3 48.3 733.3
4.9x 4.6x 4.7x 4.8x 4.8x 5.1x 6.3x 4.9x
-10- -11- -12- -13- -14-
660.2 738.3 787.2 672.9 796.9 3655.5
143.9 152.5 167.6 126.9 163.3 754.2
4.6x 4.8x 4.7x 5.3x 4.9x 4.8x
----- ----- ----- ----- ----- ----- ----- ------ -----------------
Pre-Comp Post-Comp Global-Comp Local-Comp Total-Comp
(GiB) (GiB) Factor Factor Factor
(Reduction %)
-------------- -------- --------- ----------- ---------- -------------
Written:
Last 33 days 14768.3 2964.5 3.4x 1.5x 5.0x (79.9)
Last 24 hrs 784.6 162.1 3.3x 1.4x 4.8x (79.3)
-------------- -------- --------- ----------- ---------- -------------
Key:
Pre-Comp = Data written before compression
Post-Comp = Storage used after compression
Global-Comp Factor = Pre-Comp / (Size after de-dupe)
Local-Comp Factor = (Size after de-dupe) / Post-Comp
Total-Comp Factor = Pre-Comp / Post-Comp
Reduction % = ((Pre-Comp - Post-Comp) / Pre-Comp) * 100
使用「每日詳細資料」選項：
# mtree show compression /data/col1/main daily-detailed
From: 2023-08-12 12:00 To: 2023-09-14 12:00
Sun Mon Tue Wed Thu Fri Sat Weekly
----- ----- ----- ----- ----- ----- ----- ------ -----------------
-13- -14- -15- -16- -17- -18- -19- Date
432.0 405.9 284.1 438.8 347.0 272.7 331.4 2511.8 Pre-Comp
85.5 66.2 45.3 81.9 61.4 57.4 66.3 464.1 Post-Comp
3.5x 4.1x 4.3x 3.6x 3.8x 3.3x 3.4x 3.7x Global-Comp Factor
1.4x 1.5x 1.5x 1.5x 1.5x 1.4x 1.5x 1.5x Local-Comp Factor
5.0x 6.1x 6.3x 5.4x 5.7x 4.7x 5.0x 5.4x Total-Comp Factor
80.2 83.7 84.1 81.3 82.3 78.9 80.0 81.5 Reduction %
-20- -21- -22- -23- -24- -25- -26-
478.0 387.8 450.2 533.1 386.0 258.4 393.6 2887.1
100.6 81.5 100.8 119.0 84.0 40.6 75.3 601.8
3.3x 3.3x 3.0x 3.0x 3.3x 4.1x 3.6x 3.3x
1.4x 1.5x 1.5x 1.5x 1.4x 1.5x 1.4x 1.5x
4.8x 4.8x 4.5x 4.5x 4.6x 6.4x 5.2x 4.8x
79.0 79.0 77.6 77.7 78.2 84.3 80.9 79.2
-27- -28- -29- -30- -31- -1- -2-
27.6 1.0 0.4 470.7 467.3 517.7 641.9 2126.7
4.9 0.2 0.1 83.9 92.3 89.8 140.1 411.2
4.4x 3.7x 2.6x 3.8x 3.5x 3.9x 3.2x 3.5x
1.3x 1.5x 1.6x 1.5x 1.4x 1.5x 1.5x 1.5x
5.6x 5.6x 4.3x 5.6x 5.1x 5.8x 4.6x 5.2x
82.1 82.2 76.8 82.2 80.3 82.7 78.2 80.7
-3- -4- -5- -6- -7- -8- -9-
539.6 495.0 652.8 658.7 537.1 398.7 305.5 3587.3
110.8 108.0 139.4 137.0 111.5 78.3 48.3 733.3
3.4x 3.1x 3.2x 3.4x 3.3x 3.4x 4.1x 3.3x
1.4x 1.5x 1.5x 1.4x 1.4x 1.5x 1.6x 1.5x
4.9x 4.6x 4.7x 4.8x 4.8x 5.1x 6.3x 4.9x
79.5 78.2 78.6 79.2 79.2 80.4 84.2 79.6
-10- -11- -12- -13- -14-
660.2 738.3 787.2 672.9 796.9 3655.5
143.9 152.5 167.6 126.9 163.3 754.2
3.1x 3.4x 3.2x 3.7x 3.4x .3x
1.5x 1.4x 1.5x 1.4x 1.5x 1.5x
4.6x 4.8x 4.7x 5.3x 4.9x 4.8x
78.2 79.3 78.7 81.1 79.5 79.4
----- ----- ----- ----- ----- ----- ----- ------ -----------------
Pre-Comp Post-Comp Global-Comp Local-Comp Total-Comp
(GiB) (GiB) Factor Factor Factor
(Reduction %)
-------------- -------- --------- ----------- ---------- -------------
Written:
Last 33 days 14768.3 2964.5 3.4x 1.5x 5.0x (79.9)
Last 24 hrs 784.6 162.1 3.3x 1.4x 4.8x (79.3)
-------------- -------- --------- ----------- ---------- -------------
Key:
Pre-Comp = Data written before compression
Post-Comp = Storage used after compression
Global-Comp Factor = Pre-Comp / (Size after de-dupe)
Local-Comp Factor = (Size after de-dupe) / Post-Comp
Total-Comp Factor = Pre-Comp / Post-Comp
Reduction % = ((Pre-Comp - Post-Comp) / Pre-Comp) * 100