DDR(Data Domain Restorer)上のファイルの重複排除率と圧縮率が低い場合のトラブルシューティング

DDR(Data Domain Restorer)は、最小限の物理(ポスト圧縮)ディスク領域を使用して、大量の論理(圧縮済み)データを保持するように設計されています。これは、次を使用して実現されます。

• 取り込まれたデータの重複排除により、一意のデータのみを残すDDR上のディスクにすでに保存されているデータの重複チャンクを削除
• そのデータがディスクに物理的に書き込まれる前の一意のデータの圧縮。

DDRが取得できるデータの全体的な圧縮率は、次のようないくつかの要因によって異なります。

• ユース ケース
• 取得中のデータ タイプ
• バックアップ アプリケーションの構成

最適な構成を行うと、DDRは通常、全体的な圧縮率の10~20倍を達成します(また、より高い比率を示すことがあります)。ただし、一部の環境では、全体的な圧縮率がこれに比べて低くなる可能性があります。

• 使用可能容量を迅速に使い切るDDR
• バックアップ、リストア、レプリケーションのパフォーマンスへの影響
• お客様の期待に応えるDDRの障害

この記事の目的は、次のとおりです。

• DDR上のデータの重複排除と圧縮の概要
• システムおよび個々のファイルの全体的な圧縮率を決定する方法
• 全体的な圧縮率の低下を引き起こす可能性がある要因

Data Domain Restorerはどのようにして新しいデータを取得しますか。

• バックアップ アプリケーションは、データ(つまりファイル)をDDRに送信します。
• DDRは、これらのファイルをサイズが4~12 Kbのチャンクに分割します。各チャンクは「セグメント」と見なされます。
• DDRは、セグメント内に含まれるデータに応じて、各セグメントに固有の「フィンガープリント」(チェックサムと同様)を生成します。
• 新しく到着したセグメントのフィンガープリントは、DDR上のディスク インデックスに対してチェックされ、DDRがすでに同じフィンガープリントを持つセグメントを保持しているかどうかを判断します。
• DDRがすでに同じフィンガープリントを持つセグメントを保持している場合、新しく到着したデータ内の対応するセグメントは重複しており、ドロップすることができます(重複排除されます)。
• 新しく到着したデータから重複するすべてのセグメントが削除されると、一意または新しいセグメントのみが残ります。
• これらの一意のセグメントまたは新しいセグメントは、128 Kbの「圧縮領域」にグループ化され、圧縮されます(デフォルトでは lz アルゴリズムを使用)。
• 圧縮された圧縮領域は、ハード ドライブに書き込まれる「コンテナ」と呼ばれる4.5 Mb単位のストレージにパックされます。

DDRは、特定のファイルを構成するセグメントをどのように追跡しますか?

DDRは、新しく到着したデータの重複排除/圧縮に加えて、取得された各ファイルの「セグメント ツリー」も構築します。これは基本的に、そのファイルを構成するセグメント「フィンガープリント」のリストです。DDRが後でファイルを読み取り直す必要がある場合は、次の手順を実行します。

• ファイル セグメント ツリーの場所を決定します。
• セグメント ツリーを読み取り、読み取られるファイルの領域を構成するすべてのセグメント フィンガープリントのリストを取得します。
• ディスクインデックスで を使用して、ディスク上のデータの物理的な場所(つまりコンテナ)を決定します。
• ディスク上の基盤となるコンテナーから物理セグメント データを読み取る。
• 物理セグメント データを使用してファイルを再構築します。

ファイル セグメント ツリーは、ディスク上の4.5 Mbコンテナーにも格納され、各ファイルの大部分の「メタデータ」を表します(この記事で後述します)。

DDRの全体的な圧縮率はどのように決定できますか?

DDRの全体的な使用率(および圧縮率)は、「filesys show space」コマンドを使用して確認できます。例:

Active Tier:
Resource Size GiB Used GiB Avail GiB Use% Cleanable GiB*
---------------- -------- -------- --------- ---- --------------
/data: pre-comp - 115367.8 - - -
/data: post-comp 679 4.2 6242.4 551.8 92% 202.5
/ddvar 49.2 9.1 37.6 20% -


---------------- -------- -------- --------- ---- --------------この例では、次のことが分かります。

• DDRに保持されている圧縮済みまたは論理データ: 115367.8 Gb
• DDRで使用される圧縮後または物理スペース: 6242.4 Gb
• 全体的な圧縮率は115367.8/6242.4 = 18.48倍

「filesys show compression」コマンドの出力は、保持されているデータ、使用されているスペース、圧縮率を確認します。例：

Pre-Comp Post-Comp Global-Comp Local-Comp Total-Comp
(GiB) Factor Factor Factor
(Reduction %)
---------------- -------- --------- ----------- ---------- -------------
Currently Used:*   115367.8 6242.4 - - 18.5x(94.6) <=== メモ:
                                                                          
  過去7日間 42214.7 1863.2 11.0x 2.1x 22.7x(95.6)
過去24時間 4924.8 274.0 8.8x 2.0x 18.0x(94.4)
---------------- -------- --------- ----------- ---------- -------------

DDR上のすべての使用率の数値は次のように計算されます。

• 圧縮済みデータの合計: DDRが保持するすべてのファイルの圧縮前(論理)サイズの合計。
• 圧縮後のデータの合計: ディスク上の使用中の「コンテナ」の数に4.5 Mb(単一コンテナのサイズ)を乗算した値。
• 圧縮後の合計サイズ: システムで使用可能なディスク領域を指定して作成される「コンテナー」の最大数。

使用中のコンテナーの最大数に関する統計情報は、自動サポートで使用できます。例:

Container set 73fcacadea763b48:b66f6a65133e6c73:
...
attrs.psize = 4718592 <=== バイト単位
のコンテナ サイズ...
    attrs.max_containers = 1546057 <=== 最大コンテナ
attrs.free_containers = 125562 <=== 現在空きコンテナ
attrs.used_containers = 1420495 <=== 現在使用中のコンテナ
...

次の点を確認してください。
 
個々のファイル、ディレクトリー、またはディレクトリー ツリーの重複排除と圧縮の比率をどのように決定できますか。

ファイルが取得されると、DDRはファイルに関する次の統計情報を記録します。

• 圧縮済み(論理)バイト
• 重複排除後の一意のセグメントのサイズ
• 重複排除と圧縮後の一意のセグメントのサイズ
• ファイルのメタデータのサイズ(セグメント ツリーなど)

「filesys show compression [path]」コマンドを使用して、これらの統計情報の一部をダンプできます。たとえば、単一のファイルの統計情報をレポートする場合:

SE@DDVE60_JF## filesys show compression /data/col1/backup/testfile
Total files: 1; bytes/storage_used: 2.9
元のバイト数:        3,242,460,364
グローバル圧縮:        1,113,584,070
ローカル圧縮:        1,130,871,915
メタデータ:            4,772,672

ディレクトリー ツリー全体の統計情報をレポートするには、次の手順を実行します。 SE@DDVE60_JF## filesys show compression /data/col1/backup
Total files:

3; bytes/storage_used: 1.4 元の
バイト数:        7,554,284,280
グローバル圧縮:        5,425,407,986
ローカル圧縮:        5,510,685,100
メタデータ:           23,263,692

ただし、これらの統計情報を使用する際には、いくつかの注意事項があることに注意してください。

• 統計情報はファイルまたはデータの取得時に生成され、その後は更新されません。DDRの仕組みにより、新しいファイルの取得や同じデータを参照するファイルの削除などが原因で、ファイルが時間の経過とともに重複排除され、これらの統計情報が古くなる方法が変わる可能性があります。
• さらに、DDRの特定のユースケース(ファイルのfastcopy、元のファイルの削除など)では、これらの統計情報が誤解を招いたり、間違ったりする可能性があります。

その結果、これらの数値は推定値としてのみ考慮する必要があります。

圧縮前のバイト数は、必ずしもファイルの圧縮/論理サイズとは限りません。代わりに、有効期間内にファイルに書き込まれたバイトの合計数です。その結果、一般的に既存のファイルが上書きされる環境(仮想テープ ライブラリ機能を使用している環境など)では、この図は対応するファイルの論理サイズよりも大きくなる可能性があります。

「品質の低い」データを取得すると、全体的な圧縮率が低下する可能性がありますか?

はい - DDRが取得したデータの全体的な圧縮率を高めるためには、そのデータを重複排除して圧縮できる必要があります。次に説明するように、これを妨げるさまざまなタイプのデータがあります。

Precompressed/pre-encrypted data:

これらは、クライアント システムまたはバックアップ アプリケーションで圧縮または暗号化されるデータ タイプです。また、設計によって圧縮または暗号化されたアプリケーション固有のファイル(メディア ファイルなど)や、圧縮または暗号化されたデータベース ファイル、またはメディア ファイルなどのバイナリ オブジェクトを埋め込むデータベース ファイルも含まれます。

圧縮または暗号化アルゴリズムの仕組みにより、ファイルの基盤となるデータに対して比較的小さな変更が行われるため、ファイル全体に変更が「波及」します。たとえば、クライアントは、10Kbが変更される100Mb暗号化ファイルを保持できます。通常、結果として得られるファイルは、変更された10Kbセクションとは別に、変更前後で同一になります。暗号化が使用されている場合、変更前後に変更された暗号化されていないデータは10 Kbのみですが、暗号化アルゴリズムによってファイルの内容全体が変更されます。

このようなデータが定期的に変更され、定期的にDDRに送信される場合、この「波及効果」効果により、各世代のファイルは同じファイルの旧世代とは異なって見えます。その結果、各世代には固有のセグメント(およびセグメント フィンガープリント)のセットが含まれているため、重複排除率が低くなります。

また、事前圧縮されたファイルの代わりに 、lz アルゴリズムが構成セグメント データをさらに圧縮できない可能性が低いため、ディスクに書き込む前にデータを圧縮できないことにも注意してください。

一般的なガイドラインとして、プレ圧縮/事前暗号化は次の原因になります。

• 事前暗号化されたデータ: 重複排除率は低いが、圧縮率は許容される
• 圧縮前のデータ: 重複排除率が低く、圧縮率が低い

同じ(変更されていない)事前圧縮/事前暗号化データがDDRによって複数回取得されると、圧縮または暗号化アルゴリズムを使用しているにもかかわらず、各バックアップ中に同様のセグメント(およびセグメント フィンガープリント)のセットが見られるので、データの重複排除率が向上します。

DDRに送信される可能なデータは暗号化または圧縮しないでください。これにより、エンド クライアントまたは対応するバックアップ アプリケーション内で暗号化または圧縮を無効にする必要がある場合があります。

特定のバックアップ、クライアント アプリケーション、またはオペレーティング システム内の暗号化設定または圧縮設定の確認、変更については、該当するサポート プロバイダーにお問い合わせください。

メディア ファイル:

特定のファイル タイプには、設計上、圧縮または事前暗号化されたデータが含まれています。例：

• PDFファイル
• 特定のオーディオ ファイル(mp3、wma、oggなど)
• ビデオ ファイル(avi、mkvなど)
• イメージ ファイル(png、bmp、jpegなど)
• アプリケーション固有のファイル(Microsoft Office、Open Office、Libre Officeなど)

ファイル内のデータは、ファイルのコーデックによって圧縮または暗号化され、その結果、圧縮または暗号化されたデータについて前述のようにDDRに取り込む際に同じ問題が発生します。

「一意性」が高いファイル:

優れた重複排除率を達成できるかどうかは、同じセグメント(およびセグメント フィンガープリント)のセットが複数回表示されるDDRによって異なります。ただし、特定のデータ タイプには、設計上「一意」のデータを含む一意のトランザクション データのみが含まれています。

これらのファイルがDDRに送信された場合、各世代のバックアップには固有のセグメントまたはセグメントフィンガープリントのセットが含まれるため、重複排除率が低下します。

このようなファイルの例は次のとおりです。

• データベース トランザクション ログ(Oracleアーカイブ ログなど)。
• Microsoft Exchangeトランザクション ログ

DDRに「新しい」クライアントを最初にバックアップすると、この問題が発生する可能性もあります(データはDDRによってこれまでに確認されていないため、バックアップ内の対応するセグメントまたはセグメントフィンガープリントは一意であるため)。ただし、時間の経過とともに、同じバックアップの将来の世代がDDRに送信されるため、バックアップの重複排除率は、各新しいバックアップで一意のセグメントが少なくなるにつれて向上します。このため、新しくインストールされたDDRの全体的な重複排除または圧縮率は、主に新しいバックアップを受け取った場合に縮退しますが、時間の経過とともに改善されることが予想されます。

小容量ファイル:

小容量ファイルは、DDRに書き込まれるときにさまざまな問題を引き起こします。例えば次のような場合です。

• メタデータの肥大化 - DDRは、物理データと比較して、予想よりも多くのファイル メタデータを保持し始めます。
• 低いコンテナー使用率 - 設計上(Data Domain Stream Informed Segment LayoutまたはSISLアーキテクチャにより、このドキュメントの範囲外)、ディスク上の4.5Mbコンテナーは、1つのファイルからのデータのみを保持します。その結果、たとえば、1つの10 Kbファイルをバックアップすると、少なくとも1つの4.5 Mbのフル コンテナがそのファイルに書き込まれます。これは、このようなファイルに対して、DDRがバックアップされている対応する圧縮済み(論理)データの量よりも大幅に圧縮後(物理)スペースを使用し、全体的な圧縮率が低下することを意味します。
• 低い重複排除率 :4 Kb(DDRでサポートされる最小セグメント サイズ)よりも小さいファイルは、4 Kbにパディングされた単一のセグメントで構成されます。このようなセグメントは重複排除されず、代わりにディスクに直接書き込まれます。これにより、DDRが同じセグメントの複数のコピー(重複セグメントと見なされる)を保持する可能性があります。
• バックアップ、リストア、クリーン パフォーマンスが低い:ファイルを次のファイルに移動する場合(使用されているメタデータのコンテキストを切り替える必要があるため)、バックアップ、リストア、またはクリーニング中に大きなオーバーヘッドが発生します。

次の点を確認してください。

• 小容量ファイルを使用する場合のクリーン パフォーマンスへの影響は、DDOS 5.5以降での物理クリーニングまたはガベージ コレクションの導入によって、ある程度軽減されました。
• クリーニングは、使用率の低いコンテナーのデータを、コピー フェーズ中により緊密にパックされたコンテナーに集約することで、コンテナー使用率の低下を「元に戻す」試みを行います。
• クリーニングは、コピー フェーズ中に過度に重複したセグメントを削除しようとします。

上記にもかかわらず、多数の小さなファイルや、主に小さなファイルで構成されるワークロードを使用しないようにする必要があります。ネイティブ状態で小さなファイルをDDRに送信するよりも、バックアップの前に、多数の小さなファイルを単一の非圧縮/非暗号化アーカイブに結合することをお客様に推奨します。たとえば、個々の10 Kbファイルを含む単一の10 Gbファイル1048576、すべての1048576 ファイルを個別にバックアップする方がはるかに優れています。

バックアップ アプリケーションによる過剰な多重化:

バックアップ アプリケーションは、バックアップ デバイスに送信されるストリーム間でデータの多重化を実行するように構成できます。つまり、入力ストリーム(異なるクライアント)からのデータは、単一のストリームでバックアップ デバイスに送信されます。この機能は、主に次のように物理テープ デバイスに書き込む場合に使用されます。

• 物理テープ デバイスは、1つの受信書き込みストリームのみをサポートできます。
• バックアップ アプリケーションは、テープの開始、停止、巻き戻しを防止するために、テープ デバイスに対して十分なスループットを維持する必要があります(別名、引き出し輝き)。 - テープ デバイスに送られるストリームに複数のクライアントから読み取られるデータが含まれている場合は、この方が簡単です。

ただし、DDRの場合は、DDR上の1つのファイルに、任意の順序またはチャンク サイズでインターリーブされた複数のクライアントからのデータが含まれます。これにより、DDRが特定のクライアント バックアップの各世代の重複セグメントを正確に認識できなくなるため、重複排除率が低下する可能性があります。一般的に、多重化の細分性が小さいと、重複排除率への影響が悪化します。

さらに、DDRが多くのファイルまたはコンテナーを読み取る必要がある特定のクライアント データをリストアする場合と同様に、リストア パフォーマンスが低下する可能性があります。この場合、ファイルまたはコンテナー内のデータのほとんどは、他のクライアント バックアップに関連しているため、非常に不要です。

DDRへの書き込みでは、DDRは物理テープ デバイスよりも多くの受信ストリーム数をサポートし、各ストリームは可変速度で書き込みできるため、バックアップ アプリケーションは多重化を使用する必要はありません。その結果、バックアップ アプリケーションによる多重化を無効にする必要があります。多重化を無効にした後にバックアップ パフォーマンスに影響する場合は、次の手順を実行します。

• CIFS、NFS、OST(DDBoost)を使用するバックアップ アプリケーションでは、書き込みストリームの数を増やす必要があります(これにより、DDR上でより多くのファイルを並列に書き込むことができます)。
• VTLを使用する環境では、各ドライブで追加の並列書き込みストリームをサポートできるため、DDRにドライブを追加する必要があります。

多重化を無効にする際にサポートが必要な場合、または特定のバックアップ アプリケーションに対して推奨されるマルチプレクシング構成について説明する場合は、契約されているサポート プロバイダーにお問い合わせください。

過剰なテープ マーカーを挿入するバックアップ アプリケーション:

一部のバックアップ アプリケーションでは、「マーカー」と呼ばれるバックアップ ストリームに繰り返しデータ構造を挿入する場合があります。マーカーは、バックアップ内の物理データを表すのではなく、バックアップ アプリケーションによってインデックス作成または位置システムとして使用されます。

状況によっては、バックアップ ストリームにマーカーを含めると、次のような重複排除率が低下する可能性があります。

• 第1世代のバックアップでは、12 Kbのデータが連続していました。これは、DDRによって単一のセグメントとして認識されました。
• ただし、第2世代のバックアップでは、同じ12 Kbのデータが、6 Kbのデータ、バックアップ マーカー、6 Kbのデータで表される可能性があるバックアップ マーカーを含めることによって分割されます。
• その結果、第2世代のバックアップ中に作成されたセグメントは、バックアップの第1世代で生成されたものと一致していないため、適切に重複排除されません。

マーカーの間隔が近いほど、重複排除率への影響が悪化します(たとえば、バックアップ アプリケーションが32 Kbごとにマーカーを挿入すると、バックアップ アプリケーションが1 Mbごとにマーカーを挿入するよりも多くの問題が発生します)。

この問題を回避するために、DDRはマーカー認識テクノロジーを使用して、次の操作を実行できます。

• バックアップの取得中にバックアップ ストリームから透過的に削除されるバックアップ マーカー。
• バックアップのリストア中にバックアップ ストリームに再挿入されるバックアップ マーカー

これにより、バックアップ マーカーによるデータまたはセグメントの断片化を防止し、対応するバックアップの重複排除率を向上させることができます。

ただし、このテクノロジーを最大限に活用するには、DDRがバックアップ ストリームに挿入されているマーカーを正しく認識できることが重要です。DDRは、「marker type」オプションの設定に応じてマーカーを探します。たとえば

、 SE@DDVE60_JF## filesys オプション show
Option Value
-------------------------------- --------
...
Marker-type auto
...


-------------------------------- --------通常、DDRは最も一般的なマーカー タイプと自動的に一致するため、この設定は「auto」のままにしておく必要があります。システムがマーカーを挿入する1つのバックアップ アプリケーションからのみデータを取得している場合、特定のマーカー タイプを指定することでパフォーマンス上のメリットが得られる場合があります。つまり

、#filesysオプション set marker-type {auto | nw1 | cv1 | tsm1 | tsm2 | eti1 | fdr1 | hpdp1 | besr1 | ssrt1 | ism1 | bti1| none}

以下を参照してください。

• 特定のマーカー タイプを選択することによるパフォーマンスのメリットは最小限に抑えられます。
• 間違ったマーカー タイプを選択すると、バックアップまたはリストアのパフォーマンスと重複排除率が大幅に低下する可能性があります。

そのため、Data Domainでは通常、マーカー タイプを「auto」に設定しておくことをお勧めします。マーカー タイプの変更に関する詳細なアドバイスについては、契約しているサポート プロバイダーにお問い合わせください。

バックアップ マーカーを使用しているが、自動化されたマーカー処理テクノロジー(BridgeHeadソフトウェアの製品など)によって認識されないアプリケーションからデータを取得するシステムの場合は、契約済みのサポート プロバイダーに連絡してください。このプロバイダーは、Data Domainサポートと連携して、DDRで必要な設定を決定して非標準マーカーを検出できます。

DDRによって受信される「品質の低い」データの表示:

次の表に、前述の各種データ タイプに対して予想される重複排除率と圧縮率を示します。このリストは完全なものではなく、DDRによって取得されたワークロードまたはデータにより、特定のシステムで見られる正確な数値に明らかに何らかの変動がある可能性があります。
 

グローバル圧縮	ローカル圧縮	考えられる原因
低(1x~4倍)	低(1x~1.5x)	圧縮または暗号化されたデータ
低(1x~2x)	高(>2倍)	データベース アーカイブ ログなど、一意だが圧縮可能なデータ
低(2倍~5倍)	高(>1.5倍)	検出されないマーカー、または高いデータ変更率またはストリーム多重化。
高(>10倍)	低(<1.5倍)	同じ圧縮または暗号化されたデータのバックアップ。これは珍しいことではありません。

全体的な重複排除率に影響を与える可能性があるDDRに特定の要因はありますか?

はい - DDR上のディスクに古い/超倍のデータが保持される原因となる要因がいくつかあります。これにより、圧縮後(物理)ディスク領域が増加し、全体的な圧縮率が低下します。このような要因については、以下で説明します。

ファイル システム クリーニングを定期的に実行できない場合:

ファイル システム のクリーニングは、DDR上のファイルによって参照されなくなったディスク上の古い/超倍のデータを物理的に削除する唯一の方法です。その結果、ユーザーはシステムから複数のファイルを削除する可能性がありますが(圧縮前の使用率が低下します)、クリーンな実行は行われません(圧縮後/物理使用率が高いままになります)。これにより、全体的な圧縮率が低下します。

Data Domainでは、次のように定期的に実行するようにクリーンをスケジュールすることをお勧めします。

• 通常のDDR: 週に1回
• Extended Retentionを使用したDDR: 2週間に1回

クリーンは週に1回以上実行しないでください。これにより、ディスク上のデータの断片化に問題が発生し、リストア/レプリケーションのパフォーマンスが低下する可能性があります。

システム

上の古いスナップショットが過剰:DDRは、スナップショットが作成された時点でのmtreeの内容を表すmtreeスナップショットを作成できます。ただし、古いスナップショットをシステムに残すと、圧縮後/物理使用率が増加し、全体的な圧縮率が低下する可能性があることに注意してください。例：

• 多数のファイルを含むmtreeが存在します(圧縮前の使用率が高い)。
• mtreeのスナップショットが作成されます。
• 多くのファイルが削除されます(圧縮前の使用率が低下します)。
• ファイル システムのクリーニングが実行されます。ただし、削除されたファイルのコピーがmtreeスナップショットに残るため、最小限のハード ドライブ領域が解放されることに注意してください。つまり、これらのファイルによって参照されているデータをディスクから削除することはできません。
• その結果、圧縮後/物理使用率が高いままである

Data Domainでは、mtreeスナップショットを使用する場合(不慮のデータ削除からのリカバリなど)、自動スナップショット スケジュールを使用して管理し、定義された有効期限(スナップショットが自動的に削除されるまでの時間)でスナップショットを定期的に作成することを推奨します。さらに、有効期限はできるだけ短くする必要があります(ただし、スナップショットのユースケースや、これらのスナップショットが提供する保護レベルによって明らかに異なる場合があります)。これにより、有効期限が長い古いスナップショットが蓄積されるのを防ぐことができます。

スナップショットとスナップショット スケジュールの操作の詳細については、次の記事を参照してください。Data Domain :スナップショット スケジュールの

管理過剰なレプリケーションラグ:

ネイティブData Domainレプリケーションでは、レプリケーション ログまたはmtreeスナップショット(レプリケーション タイプに応じて)のいずれかを使用して、リモートDDRへのレプリケーションを保留中のファイルまたはデータを追跡します。レプリケーション遅延は、レプリカがソースDDRに対する変更に後れを取る概念です。これは、次のようなさまざまな要因によって発生する可能性があります。

• レプリケーション コンテキストが無効になっている
• DDR間のネットワーク帯域幅が不足している
• 頻繁なネットワーク切断。

レプリケーション遅延が大きいと、ソースDDRまたはソースDDRおよびデスティネーションDDR上の古いまたは古いMTreeスナップショットで削除されたファイルへの参照がレプリケーション ログに引き続き含まれる可能性があります。前述のように、これらのスナップショット(またはレプリケーション ログ)によって参照されるデータは、対応するファイルがシステムから削除されている場合でも、DDR上のディスクから物理的に削除することはできません。これにより、圧縮後またはDDRの物理的な使用率が増加し、その後重複排除率が低下する可能性があります。

DDRの使用率が高く、レプリケーション遅延が原因であると考えられる場合は、契約しているサポート プロバイダーにお問い合わせください。

DDRに構成の変更や特定の要因があり、全体的な圧縮率を高めることができますか?

はい - このドキュメントですでに説明した問題を削除または対処することで、DDRは時間の経過とともに全体的な圧縮率を向上させることができます。また、DDRにはさまざまな要因やワークロードがあり、重複排除率の向上につながる可能性があります。一般的に、以下が含まれます。

• DDR上のファイルによって使用されるハード ドライブ領域の量を削減する(たとえば、DDRで使用される圧縮アルゴリズムの積極性を高める)
• 圧縮後/物理使用率が増加することなく、DDR上の圧縮前(論理)データの量が突然増加する

圧縮アルゴリズムの変更:

デフォルトでは、DDRは 、ディスク に書き込まれるデータをlzアルゴリズムで圧縮します。前述のように、 lz は圧縮または解凍に必要なCPUの点でオーバーヘッドが比較的低いため使用されますが、データ サイズの削減には妥当な有効性が示されています。

圧縮アルゴリズムの積極性を高めて、圧縮後またはハード ドライブの使用率をさらに削減できます(その結果、全体的な圧縮率が向上します)。有効性の高い順(低から高)でサポートされる圧縮アルゴリズムは次のとおりです。

• Lz
• gzfast
• Gz

各アルゴリズムの一般的な比較は次のとおりです。

• lzは gzfast と比較して圧縮率が最大15%向上し、2倍のCPUを消費します。
• lzはgzと比較して圧縮率が最大30%向上し、5倍のCPUを消費します。
• gzfastはgzと比較して、圧縮率が10~15%向上します。

圧縮を完全に無効にすることもできます(アルゴリズムを指定しません)。ただし、これはお客様のシステムでの使用にはサポートされておらず、内部テスト専用です。

上の表に示すように、圧縮アルゴリズムが積極的であるほど、データの圧縮または解凍時に必要なCPUが増えます。このため、より積極的なアルゴリズムへの変更は、通常のワークロードで軽くロードされているシステムでのみ行う必要があります。負荷の高いシステムでアルゴリズムを変更すると、バックアップまたはリストアのパフォーマンスが大幅に低下し、ファイル システムのパニックや再起動(DDRの停止)が発生する可能性があります。

圧縮タイプの変更の詳細については、次の記事を参照してください。Data DomainシステムとGZ圧縮

への変換によるクリーニング パフォーマンスインパクト圧縮アルゴリズムの変更による潜在的な影響により、これを行うことに関心があるお客様は、契約したサポート プロバイダーに連絡して変更についてさらに話し合ってから続行することをお勧めします。

ファイル システムのfastcopyの使用:

DDRでは、「file system fastcopy」コマンドを使用して、ファイル(またはディレクトリー ツリー)を迅速にコピーできます。この機能は、既存のファイル(またはファイルのグループ)のメタデータをクローン作成することによってファイルを作成します。これにより、新しいファイルは元のファイルに物理的に接続されず、元のファイルとまったく同じディスク上のデータを参照します。つまり、元のファイルのサイズに関係なく、新しいファイルはディスク上のスペースをほとんど消費していない(既存のデータに対して完全に重複排除されるため)。

この動作の結果、ファイル システムのfastcopyを使用すると、DDR上のデータの圧縮済み(論理)サイズは急速に増加しますが、圧縮後/物理使用率は静的のままになります。

たとえば、次のDDRの使用率は次のとおりです(1.8倍以下の全体的な圧縮率を示します)。

アクティブ階層:
リソース サイズGiB Used GiB Avail GiB Use% Cleanable GiB*
---------------- -------- -------- --------- ---- --------------
/data: pre-comp - 12.0 - - -
/data: post-comp 71.5 6.8 64.7 10% 0.0
/ddvar 49.2 1.1 45.6 2% -
/ddvar/core 158.5 0.2 150.2 0% -
---------------- -------- -------- --------- ---- --------------

大容量ファイル(/data/col1/backup/testfile):

!!! データが危険にさらDDVE60_JF!!! # ls -al /data/col1/backup/testfile-rw-r
--r-- 1 root root 3221225472 7月29日 04:20 /data/col1/backup/testfile

ファイルは数回高速にコピーされます。

sysadmin@DDVE60_JF# filesys fastcopy source /data/col1/backup/testfile destination /data/col1/backup/testfile_copy1
sysadmin@DDVE60_JF# filesys fastcopy source /data /col1/backup/testfile destination /data/col1/backup/testfile_copy2
sysadmin@DDVE60_JF# filesys fastcopy source /data/col1/backup/testfile destination /data/col1/backup/testfile_copy3

これにより、圧縮後の使用率が少し変化するため、圧縮前の使用率が増加します。

Active Tier:
Resource Size GiB Used GiB Avail GiB Use% Cleanable GiB*
---------------- -------- -------- --------- ---- --------------
/data: pre-comp - 21.0 - - -
/data: post-comp 71.5 6.8 64.7 10% 0.0
/ddvar 49.2 1.1 45.6 2% -
/ddvar/core 158.5 0.2 150.2 0% -
---------------- -------- -------- --------- ---- --------------

その結果、DDRの全体的な圧縮率は約3.1倍になりました。

前述のように、コピーの圧縮統計は完全に重複排除されることを示しています。sysadmin@DDVE60_JF#filesysは圧縮/data/col1/backup/testfile_copy1
Totalファイルを示します。

1; bytes/storage_used: 21331976.1
元のバイト数:        3,242,460,364
グローバル圧縮:                    0
ローカル圧縮:                    0
メタデータ:                  152

Fastcopy機能は、DDRの物理的使用率を減らすことによって全体的な圧縮率を向上させるために使用することはできませんが、全体的な圧縮率が高い原因である可能性があります(特にAvamar 6.xなどのfastcopyを広範に使用している環境)。