Data Domain:クリーニング可能なサイズは推定値です
Summary: Data Domainシステムに表示される「Cleanable GiB」の値についてしばしば混乱が生じ、クリーニングの実行時にリカバリーされるスペースの量が誤って期待されます
Instructions
Data Domainシステムに表示される「Cleanable GiB」の値についてしばしば混乱が生じ、クリーニングの実行時にリカバリーされるスペースの量について誤った期待が生じます。
表示されている「クリーニング可能なGiB」の数値は純粋に推定値であり、Data Domainファイルシステムの開発時に行った技術的な選択により、クリーニングを実行することによってリカバリーされるスペースの量を正確に算出することはできません。
クリーニング可能なスペースの推定値が、実際に回収されたスペースと大きく異なる理由について、以下に簡潔に説明します。ただし、ここでは考慮されていない他の要因があるため、推定値とクリーン実行時に実際に解放されるディスク領域の量は大幅に異なる場合があります
データがData Domainシステムによって取得されると、圧縮後の値が計算され、すべてのファイルの静的データとして格納されます。「Cleanable」値は、DD Cleanが最後に実行されて完了してから削除されたすべてのファイルの圧縮後の値の合計です。
削除されていない他のファイルのデータの重複排除に、削除されたファイルのファイル セグメントが使用されている場合、[Cleanable]の値は不正確になります。既存の一意のセグメントを参照しているファイルが1つある限り、DDクリーニング プロセスでは、これらのセグメントが再利用されたとは見なされません。そのため、ファイルのポストコンポジションが「Cleanable GiB」カウンターに追加され、その一意のセグメントがすべて破棄されようとしているかのように追加された場合でも、一部(または多数)は他のファイルによって再利用されていない可能性があります。
この効果を示すより詳細な例は次のとおりです。
Data Domainシステムに1つずつ追加された5つのファイルがあり、以前は他のデータがなかったとします。
最初の 100 GB のファイルにはすべての一意のデータが含まれているため、圧縮比は 1 倍になります (最初のファイルにファイル自体に冗長性がなかったと仮定します)。2番目から5番目のファイルは、1番目のファイルのデータと、追加される古い各ファイルに対して重複排除することができました。重複排除の対象となるファイルが増えているため、それぞれの重複除外率が向上しています。
File 1: precomp: 100 GB postcomp: 100 GB compression ratio: 1x File 2: precomp: 100 GB postcomp: 50 GB compression ratio: 2x File 3: precomp: 100 GB postcomp: 25 GB compression ratio: 4x File 4: precomp: 100 GB postcomp: 25 GB compression ratio: 4x File 5: precomp: 100 GB postcomp: 1 GB compression ratio: 100x Resource Size GiB Used GiB Avail GiB Use% Cleanable GiB* ---------------- --------- --------- --------- ---- -------------- /backup: pre-comp - 500 - - - /backup: post-comp 1000 201 799 20% 0 ---------------- --------- --------- --------- ---- --------------
例 1./backup から最初の 3 つのファイルを削除した後のステータス:
Resource Size GiB Used GiB Avail GiB Use% Cleanable GiB* ---------------- --------- --------- --------- ---- -------------- /backup: pre-comp - 200 - - - /backup: post-comp 1000 201 799 20% 175 ---------------- --------- --------- --------- ---- --------------
この後にクリーニングを実行すると、175個のクリーニング可能ファイル全体ではなく、125個を再利用できる場合があります。これは、最後の 2 つのファイルがファイル 1 から 3 とセグメントを共有しているためです。 残りの 50 GB の領域は、ファイル3-5 によってまだ使用されているため、クリーニングしても回復されません。
例 2:例1と同じ開始点を使用して、ファイル1が削除され、/backupフォルダー全体(つまり、5つのファイルすべて)でfastcopyが実行され、ファイル2-4が削除されたとします。
Resource Size GiB Used GiB Avail GiB Use% Cleanable GiB* ---------------- --------- --------- --------- ---- -------------- /backup: pre-comp - 800 - - - /backup: post-comp 1000 201 799 20% 200 ---------------- --------- --------- --------- ---- --------------
事前圧縮の「サイズGiB」の数値は、(500-100)=400*2=800から得られ、5個のオリジナルファイルに対して500を与え、ファイル1の削除に対して100を引くと400 GiBを与えます。 次に、残りの4つのファイルすべてでfastcopyが実行されたため、400 GiBが2倍になりました。
ファイルコピーでは、元のデータへのメタデータ ポインタで構成されるわずかな容量しか追加されないため、圧縮後に使用される容量は変わりません。(クリーニングを開始するための)「filesys clean start」が実行されていないため、ファイル1を削除してもスペース使用量は変わりません。
クリーンアップ後、次のように表示されます。
Resource Size GiB Used GiB Avail GiB Use% Cleanable GiB* ---------------- --------- --------- --------- ---- -------------- /backup: pre-comp - 800 - - - /backup: post-comp 1000 176 824 18% 0 ---------------- --------- --------- --------- ---- --------------
200GBがクリーニング可能と表示されていても、実際にクリーニングされたのは25GBのみであることに注意してください。ファイル 1 から 4 の「圧縮後」のファイル サイズが合計で 200 GB になったため、[Cleanable GiB] が 200 と表示されました。 100 GBの「ファイル1」のみが削除されましたが、そのうちの75 GBは他の4つのファイルで使用中でした(重複排除のため)。
「ファイル2」から「ファイル4」も削除されているため、奇妙に思えるかもしれませんが、「ファイル2」から「ファイル4」は削除済みと表示されますが、これらのファイルは別のフォルダーに高速コピーされていたため、これらのファイルの実際のデータ セグメントを削除できませんでした。 すべてのfastcopyバージョンも削除された後にのみ、クリーニングによってスペースを完全に回復できます。
クリーニング可能なGiBは単なる「推定値」であり、正確ではない可能性があるため、Data Domainの物理容量と同じまたは大きいサイズを反映している場合があります。
これにより、Cleanable GiBの値が"/data: post-comp"に近いか同じ値を表示するためにDDFSスペースの使用率が100%に近づいている場合に、スケジュール設定されたDDFSクリーニングの実行を許可するか、手動で実行するかが混乱する可能性があります
実行時に再利用されるクリーンなディスク領域の量を、より適切で信頼性の高い方法で見積もるために、DDOS 7.7.x以降では、アクティブ階層の次のGCで再利用できる実際の「クリーニング可能な領域の合計」をCLIから判断できるようになりました。次に、CLIの概要を示します。
# filesys cleanable-space calculate Cleanable space calculation started. Use 'filesys cleanable-space watch' to monitor progress.
プロセスは通常のGCと同様に、フェーズ1から4に進みますが、フェーズ5(コピー)はスキップされます。フェーズ5(コピー)では、コンテナを効果的にコピーしてデッド ディスク領域を再利用します。そのため、通常の GC がクリーン フェーズ 1 から 4 を完了して値を返すのと同じくらい時間がかかるため、これは更新された見積もりを取得するために定期的に実行するものではなく、必要な場合にのみ実行する必要があります。つまり、「filesys cleanable-space calculate」は、アクティブ階層でGCを実行し、スペースを再利用する部分をスキップします。
プロセスは次のように監視できます。
# filesys cleanable-space watch Beginning 'filesys cleanable-space calculation' monitoring. Use Control-C to stop monitoring. Cleaning: phase 1 of 4 (pre-merge) 100.0% complete, 96233 GiB free; time: phase 0:02:07, total 0:02:07 Cleaning: phase 2 of 4 (pre-analysis) 100.0% complete, 96233 GiB free; time: phase 0:06:51, total 0:08:59 Cleaning: phase 3 of 4 (pre-enumeration) 100.0% complete, 96233 GiB free; time: phase 0:00:20, total 0:09:20 Cleaning: phase 4 of 4 (pre-select) 100.0% complete, 96233 GiB free; time: phase 0:00:25, total 0:09:46
完了すると、洗浄可能な測定結果にアクセスできます。
# filesys cleanable-space status Cleanable space on active tier is 94649698202 bytes. Last calculated on 2023/08/25 03:29:51 Cleanable space calculation finished at 2023/08/25 03:29:51.
上記のテスト例では、DD GCを今すぐ実行すると、94649698202バイトが解放されます。これは88.1 GiBです。計算の時点では、ラボのDDで「df」によって報告された推定値は41.9 GiBでした。当然ながら、FSに変更が加えられると(新しいバックアップ、より多くの削除、スナップショットが作成されて期限切れになるなど)、計算は停止します。
必要に応じて、上記のプロセスを停止するには、次のコマンドを使用できます。
# filesys cleanable-space stop The 'filesys cleanable-space stop' command stops calculating cleanable space in the system. Are you sure? (yes|no) [no]: yes ok, proceeding. # filesys cleanable-space status Cleanable space on active tier is 2607064 bytes. Last calculated on 2021/06/27 23:23:05 Cleanable space calculation started at 2021/06/27 23:27:58 and was aborted at 2021/06/27 23:28:19. Cleaning was aborted by user.
このCLIは、DDアクティブ階層にのみ適用されることに注意してください。DDクラウド ユニットのクリーニング可能量を計算するための同等のプロセスはありません。DDクラウド ユニットには独自の推定値があり、前述のような不確実性の影響を受けます。