Data Domain - 圧縮に関するよくある質問(FAQ)

該当製品：

• すべてのDDR
• すべてのリリース

圧縮：よくあるお問い合わせ(FAQ)：

同じディスク領域を使用することが理想的ですが、実際には次の理由により、フル バックアップは増分バックアップよりも少し多くのスペースを使用します。これらの理由により、データに変更がないフル バックアップでも、かなりの領域が消費されます。

• メタデータは、バックアップの論理サイズの約0.5%を占めます。フルの論理サイズが100GBで、増分の論理サイズが2GBであるとします。増分が1GBに圧縮されるとすると、フルには1.5GB以上必要です。
• DD圧縮エンジンは、パフォーマンス向上のため、重複するデータ セグメントを一部書き換えます。変更によりデータの局所性が低くなるほど、より多くの重複セグメントが書き込まれます。重複セグメントは、後で「ファイルシステムのクリーンアップ」によって再利用されます。論理サイズの約2%が重複として書き換えられていることが分かっています。このレベルの重複を想定すると、フル バックアップには1GB（圧縮） + 0.5GB（メタデータ） + 2GB（重複） = 3.5GBが必要になる可能性があります。書き込まれる重複の量は、システム パラメーターを使用して制御できますが、通常、このパラメーターを現場で調整することはありません。
• データのセグメント化は、NFSクライアントがデータを送信する順序に応じて、バックアップごとに多少異なる場合があります。この順序は確定的ではありません。一般に、セグメンテーション アルゴリズムはシフトと並べ替えを許容します。ただし、シフトや並べ替えが発生しやすい「強制された」セグメントも作成されます。通常、セグメントの約0.2%が強制されるため、より多くの領域が使用されることが予想されます。

「filesys show space」は、保存されたデータの論理サイズと、コマンドの実行時に使用されたディスク領域に基づいて圧縮率を表示します。

「filesys show compression」は、各ファイルが作成された時点での圧縮方法に基づいて圧縮率を表示します。

「filesys show compression」は、主にサポートとデバッグに使用されます。ファイルの削除が存在する場合、「filesys show compression」は圧縮率を多く見積もります。

例えば、最初のフル バックアップでは2xの圧縮率で、データ変更なしの後続のフル バックアップでは200xの圧縮率であるとします。最初のフル バックアップが削除されると、「filesys show space」では、2xの圧縮率が表示されます。「filesys show compression」では、200xの圧縮率が表示されます。これは、現存する唯一のファイルが作成時に200xの圧縮率であったためです。

前述の例では、2回目のバックアップの後、「filesys show space」に約4xの累積率が表示されます。累積率は、削除せずにより多くのバックアップを続けた場合、200xに向かって漸近的に増加します。

他にも次のような小さな違いがあります。

•  「filesys show compression」では、コンテナ レベルの消費が考慮されないため、圧縮率がさらに多く見積もられます。
•  「filesys show compression」では、グローバル圧縮による重複排除が考慮されないため、圧縮率が小さく見積もられます。
•  「filesys show compression」は、ファイル単位またはディレクトリー単位の情報を提供できますが、「filesys show space」はシステム全体に限定されます。
•  「filesys show compression」は、グローバル圧縮とローカル圧縮の内訳を提供しますが、「filesys show space」は提供しません。

リファレンス：

• 「filesys show space」と「vtl tape show summary」の圧縮率が異なるのはなぜですか？

「vtl tape show summary」に表示される圧縮率は、「filesys show compression /backup/vtc」と一致するように意図されています。

より一般的には、このVTLコマンドに、テープ カートリッジのサブセットを選択するオプションのフィルターを設定することができます。圧縮率はそのカートリッジのサブセットの「filesys show compression」と一致するはずです。

ただし、VTL UIコードにバグがあるため、「vtl tape show summary」で表示される圧縮率に誤りがあります。これは既知の問題で、リリース4.5.0.0で解決されています。
 

• VTLの場合、「filesys show compression last 24 hours」が期待値と一致しないのはなぜですか？

VTLの場合、「filesys show compression last 24 hours」などのコマンドの出力は、「system show performance」などの他のソースに基づいて、期待値と一致しないことがよくあります。

この問題は、「filesys show compression」(fsc)の特殊性が原因で発生します。一般に、「filesys show compression」は、選択したファイルの累積統計を表示します。修飾子「last 24 hours」は、過去24時間以内に更新されたファイルを選択します。統計情報は、ファイルが作成されてから、または最後にゼロ サイズにトランケートされてからの累積です。したがって、過去24時間以内にファイルが追加された場合、「filesys show compression last 24 hours」には過去24時間以内の累積統計情報が表示されます。

VTL以外の環境では、バックアップ ファイルは一度だけ書き込まれるため、更新されたファイルと作成されたファイルの間に大きな不一致が生じることはありません。VTLを使用すると、バックアップを既存のテープ ファイルに追加できます。例えば、容量100GBのテープが50GBまで使用されているとします。過去24時間以内にこのテープに10GBのデータが追加された場合、「filesys show compression last 24 hours」には、60GBで書き込まれたファイルの「元のバイト数」が表示されます。
 

• 累積圧縮率はどのように計算されますか？

個々の圧縮率は直線的には加算されません。

例えば、1回目のフル バックアップの圧縮率が2xで、2回目のフル バックアップの圧縮率が20xだとします。累積圧縮は、(2+20)/2または11xではなく、2/(1/2+1/20)または3.64xです。

一般に、圧縮率が低いほど、圧縮率が高い場合よりも累積圧縮率に大きな影響を与えます。

例えば、i番目のバックアップに論理サイズsiと圧縮率ciがあるとします。この場合、k個のバックアップの累積圧縮率は、次のように計算できます。

C = （合計論理サイズ）/（使用済み合計領域）
合計論理サイズ = s1 + s2 + ..+ sk
使用済み合計領域 = s1/c1 + s2/c2 + ...+ sk/ck

多くの場合、論理サイズはほぼ同じです。その場合、上記の計算は次のように簡略化されます。

例えば、最初のフル バックアップが3xの圧縮率、それ以降の各フル バックアップが30xの圧縮率で、保存期間が30日の場合、累積圧縮率は30/(1/3+29/30)または23xになります。
 

• Data Domainの圧縮の仕組みを教えてください。

この質問については、別のKB記事：「Data Domain：Data Domainの圧縮について」で詳しく回答しています。
 

• Data Domainはマルチプレクシングをサポートしていますか？​​​​​​​

バックアップ アプリケーションからのデータをマルチプレックス化すると、グローバルな重複排除が非常に貧弱になります。詳細については、関連記事：「Data Domain：バックアップ ソフトウェアでのマルチプレクシング（英語）」を参照してください。 
 

• 1対1のディレクトリー レプリケーションで、レプリカのグローバル圧縮率が高いのはなぜですか？​​​​​​​

これは通常、システムに書き込まれる重複セグメントのレベルにばらつきがあるためです。

• ソースに格納されているデータは、ソースに格納されている以前のデータに対して1回重複排除されています。
• ネットワークを介して送信されたデータは、レプリカに格納されているデータに対して1回重複排除されています。
• レプリカに格納されているデータは、データがネットワーク経由で送信されたときと、受信したデータがレプリカに書き込まれたときの2回重複排除されています。

重複排除プロセスでは一部の重複が残るため、重複排除が複数回行われたデータには重複が少なくなります。ソースに格納され、ネットワーク経由で送信されたデータは1回重複排除されるため、ソースとレプリカに格納されたデータが類似していると仮定すると、ほぼ同じになります。レプリカに格納されたデータは2回重複排除されるため、圧縮率が向上します。

ファイルシステムのクリーンアップでは、重複のほとんどが削除されます。したがって、ソースとレプリカでクリーンアップを実行した後、そこに格納されるデータの量はほぼ同じになります。

• lz、gzfast、gzのローカル圧縮設定を使用した場合、圧縮の変更点は何ですか？

filesys option set compression {none | lz | gzfast | gz}
 

Warning: ローカル圧縮タイプを変更する前に、ファイル システムをシャットダウンする必要があります。その後、圧縮オプションが設定された後に再起動できます。

一般的に、圧縮の順序は次のとおりです。

大まかな違いは次のとおりです。

• lzからgzfastでは、圧縮率が～15%向上し、CPUが2倍消費されます。
• lzからgzでは、圧縮率が～30%向上し、CPUが5倍消費されます。
• gzfastからgzでは、圧縮率が～10-15%向上します。

ローカル圧縮を変更するとまず、変更後にData Domain Restorerに書き込まれた新しいデータに影響することに注意してください。古いデータは、次のクリーンアップ サイクルまで以前の圧縮形式を保持します。次のクリーンアップ サイクルでは、すべての古いデータが新しい圧縮形式にコピーされます。これにより、クリーンアップの実行にはるかに時間がかかり、より多くのCPUを消費します。

お客様のシステムのCPUがすでに不足している場合、特にお客様がバックアップとレプリケーションを同時に実行している場合は、バックアップ/レプリケーションの速度が低下する可能性があります。お客様は、この変更を行う時間を明示的にスケジュールすることができます。

ナレッジ リファレンス：

• 「移行の問題を解決する方法（英語）」
• Data Domain：Data Domainの圧縮について