Data Domain：Data Domain Restorer（DDR）における高い領域使用率または使用可能な容量不足に関する問題を解決する方法

 

• これは、新しく取得されたファイル/データが存在するディスク領域で、クライアント バックアップ アプリケーションによって失効/削除されるまで、ほとんどのDDRではファイルはここに残ります
• Extended Retention（ER）またはLong Term Retention（LTR）で構成されたDDRでは、データ移動プロセスを定期的に実行して、アクティブ階層からアーカイブ階層またはクラウド階層に古いファイルを移行することができます
• 削除/移行済みファイルによって使用されたアクティブ階層の領域を再利用する唯一の方法は、ガベージ コレクション/クリーニング プロセス（GC）を実行する方法です

• アクティブ階層で、利用可能な領域が不足し、次のようなアラート/メッセージが表示される可能性がある：

• アクティブ階層が100%フルになると、DDRに新しいデータを書き込むことができなくなり、バックアップ/レプリケーションが失敗する可能性がある - このシナリオでは、次のようなアラート/メッセージが表示される場合がある：

• 状況によっては、アクティブ階層がフルになると、Data Domainファイル システム（DDFS）が読み取り専用になり、その時点で既存のファイルを削除できなくなることがある

• アクティブ階層がフルになることがある理由
• アクティブ階層の使用率が高い原因を特定するためのシンプルなチェックリストと、対応する救済手順

• この記事は完全ではありません（つまり、この記事で説明されていない理由により、DDRのアクティブ階層の使用率が高くなる場合があります）。ただし、ここでは最も一般的な原因/問題について説明することを目的としています。
• この記事では、アーカイブ階層またはクラウド階層の高い使用率については説明しません。

  DDRのアクティブ階層は、さまざまな理由により、適切な使用率よりも高くなる可能性があります。

• 保存ポリシーまたはバックアップ アプリケーションの構成が正しくないため、クライアント バックアップ アプリケーションによりバックアップ ファイル/セーブセットが正しく失効/削除されていない
• レプリケーションの遅延により、アクティブ階層に大量の古いデータが残り、レプリカへのレプリケーションが保留の状態となる
• アクティブ階層に書き込まれるデータの圧縮比が、適切な全体の圧縮比を下回っている
• システムが正しくサイズ設定されていない。つまり、それに保存しようとしていたデータ量に対して小さすぎる
• バックアップに非常に小さなファイルが多数含まれている - これらのファイルは、最初に書き込まれたときに、適切な領域以上を消費しているが、クリーニング/ガベージ コレクション中にこの領域を再利用する必要がある
• ER/LTRで設定されたシステムでデータ移動が定期的に実行されていないため、アーカイブ/クラウド階層に移行する必要がある古いファイルがアクティブ階層に残っている
• クリーニング/ガベージ コレクションが定期的に実行されていない
• DDR上に過剰または古いMtreeスナップショットがあり、削除されたファイル/データが使用していた領域をクリーニングにより再利用できない

手順1 - アクティブ階層のクリーニングを実行する必要があるかどうかを判断する

Data Domainオペレーティング システム（DDOS）は、アクティブ階層に対して「Cleanable GiB」と呼ばれるカウンターを維持しようとします。これは、クリーニング/ガベージ コレクションを実行することによって、アクティブ階層でどの程度の物理（圧縮前）領域を再利用できるかを推定するものです。このカウンターは、「filesys show space」/「df」コマンドによって表示されます。
 
いずれかの場合：

• 「Cleanable GiB」の値が大きい
• DDFSが100%フルになった（それに伴って読み取り専用になった）

この記事の先の手順を続行する前に、クリーニングを完了するまで実行する必要があります。クリーニングを開始するには、「filesys clean start」コマンドを使用する必要があります。例：
 
クリーニングが適切に開始したことを確認するには、「filesys status」コマンドを使用します。例：
 
以下の点に注意してください。

• クリーニングを開始できない場合は、契約しているサポート プロバイダーに連絡してサポートを受けてください。これは、システムで「セグメント欠落エラー」が発生し、クリーニングが無効になっていることを示している可能性があります
• クリーニングがすでに実行されている場合、開始しようとすると、次のメッセージが表示されます：

• アクティブ階層の領域は、クリーニングがそのコピー フェーズに達するまで解放/再利用されません（デフォルトでは、DDOS 5.4.x以前のフェーズ9、DDOS 5.5.x以降のフェーズ11）。クリーニングで使用されるフェーズの詳細については、次を参照してください：https://support.emc.com/kb/446734
• 「Cleanable GiB」が示す領域の値は基本的に推定値であるため、クリーニングによって再利用できない場合があります。詳細については、次を参照してください：https://support.emc.com/kb/485637
• クリーニングは1回の実行ですべての潜在的な領域を再利用できない場合があります。これは、非常に大規模なデータセットを含むDDRでは、クリーニングが最も不要なデータを含むファイル システムの一部に対して実行されるためです（クリーニングを実行するのにかかる時間で最大の空き領域を得るため）。状況によっては、すべての潜在的な領域を再利用する前に、クリーニングを複数回実行する必要がある場合があります
• 「Cleanable GiB」の値が非常に大きい場合は、クリーニングが定期的に実行されていないことを示している可能性があります。次のようにクリーニング スケジュールが設定されていることを確認します：

クリーニングが完了したら、「filesys show space/df」コマンドを使用して、使用率の問題が解決されたかどうかを確認します。まだ使用率が高い場合は、この記事の残りの手順を実行します。

手順2 - ソース レプリケーション コンテキストに対する大量のレプリケーション遅延を確認する

ネイティブのData Domainレプリケーションは、「レプリケーション コンテキスト」の概念に基づいて設計されています。例えば、システム間でデータをレプリケートする必要がある場合：

• レプリケーション コンテキストは、ソースとターゲットのDDR上に作成される
• コンテキストが初期化される
• 初期化が完了すると、レプリケーションにより、ソースからターゲットへアップデート/デルタが定期的に送信され、システム上のデータを同期し続ける

ソース レプリケーション コンテキストが遅れると、古いデータがソース システム上のディスクに残ることがあります（遅延しているレプリケーション コンテキストにより、ターゲット システム上で過度の使用率は発生しないことに注意してください）。

• ディレクトリー レプリケーション コンテキスト（システム間で/data/col1/backup下の1つのディレクトリー ツリーをレプリケートする場合に使用）：

•  Mtreeレプリケーション コンテキスト（システム間で/data/col1/backup以外のMtreeをレプリケートする場合に使用）：

• コレクション レプリケーション コンテキスト（1つのDDRの内容全体を別のシステムにレプリケートする場合に使用）：

 レプリケーション コンテキストが遅れているかどうかを確認するには、次の手順を実行する必要があります。

• 現在のシステムのホスト名を確認します。

• 現在のシステムの日付/時刻を確認します。

• システム上で構成されたレプリケーション コンテキストと、その「synced as of time」の一覧を表示します。対象となるコンテキストは、ターゲットに現行システムのホスト名が含まれず（現在のシステムがソースであることを示す）、「synced as of time」がかなり古くなっていることに注意してください。

現在のシステムがソースであるコンテキスト、顕著な遅延が発生しているコンテキスト、または不要になったコンテキストは、中断する必要があります。これを実行するには、ソース システムとターゲット システムで次のコマンドを実行します。
 
たとえば、前述の「対象の」コンテキストを中断するには、次のコマンドをソースとターゲットで実行します。
 
以下の点に注意してください。

• コンテキストを中断したら、アクティブ階層の潜在的な領域を再利用するために、アクティブ階層のクリーニングを実行する必要があります
• Mtreeレプリケーションを使用する場合、コンテキストを中断すると、Mtreeレプリケーション スナップショットがディスクに残る場合がありますクリーニングを実行する前に、手順5に従って余分なスナップショットを失効させたことを確認します
• ソース/ターゲットのMtreeがアーカイブ階層またはクラウド階層にデータを移行するように構成されている場合は、対応するMtreeレプリケーション コンテキストを中断するときに注意が必要です。これらのコンテキストは、後で再作成/初期化することができない場合があります。その理由は、Mtreeレプリケーション コンテキストが初期化されると、ソース システム上にMtreeスナップショットが作成され、Mtree内のすべてのファイルの詳細が含まれるためです（階層に関係なく）。その後、このスナップショットは、ターゲットのアクティブ階層に完全にレプリケートされます。そのため、ターゲットのアクティブ階層に、ソースからすべてのMtreeデータを取得するために十分な空き領域がない場合は、初期化を完了できません。この問題の詳細については、契約しているサポート プロバイダーにお問い合わせください
• コレクション レプリケーション コンテキストを中断した場合は、ターゲットDDR上のDDFSのインスタンスを破棄することなく（このシステム上のすべてのデータを失うことなく）、コンテキストを再作成/初期化することはできません。したがって、その後の初期化では、ソースからのすべてのデータを再度ターゲットに物理的にレプリケートする必要があるため、かなりの時間とネットワーク帯域幅を要する可能性があります

手順3 - 不要になったMtreeを確認する

DDFSの内容は、論理的にMtreeに分割されます。個々のバックアップ アプリケーション/クライアントが個別のMtreeに書き込まれるのは一般的なことです。バックアップ アプリケーションが破棄された場合、システム上に古い/余分なMtreeが残っている可能性のあるDDRからデータを書き込む/削除することはできなくなります。これらのMtreeのデータは、DDRのディスク上の領域を使用して無期限に存続します。そのため、このような余分なMtreeを削除する必要があります。例：

• システム上のMtreeのリストを取得します。

• 不要になったすべてのMtreeは、「mtree delete」コマンドを使用して削除する必要があります。例：

• 削除されたMtreeによってディスク上で消費された領域は、次にアクティブ階層のクリーニング/ガベージ コレクションが実行されるときに再利用されます。

以下の点に注意してください。

• MtreeレプリケーションのターゲットであるMtree（つまり、Mtreeリストの出力にRO/RDのステータスがある）は、Mtreeが削除される前に、その対応するレプリケーション コンテキストを中断する必要があります
• DDBoost論理ストレージ ユニット（LSU）、または仮想テープ ライブラリー（VTL）プールとして使用されているMtreeは、「mtree delete」コマンドを使用して削除することができない場合があります。このようなMtreeを削除する方法の詳細については、『Data Domain Administration Guide』を参照してください
• Retention Lockが構成されたMtree（つまり、RLCEまたはRLGEのステータスを持つ）を削除することはできません。代わりに、Mtree内の個々のファイルにRetention Lockを戻し、個別に削除する必要があります。詳細については、『Data Domain Administration Guide』を参照してください

手順4 - 古い/余分なMtreeスナップショットを確認する

Data Domainスナップショットは、特定の時点における対応するMtreeのスナップショットを示します。結果：

• スナップショットの作成時にMtree内に存在するすべてのファイルがスナップショットによって参照されます
• これらのファイルが消去または削除されてもスナップショットは引き続き存在しますが、クリーニングでは、ディスクで使用されている物理スペースを再利用することはできません。これは、スナップショット内のファイルのコピーに後でアクセスする場合に備えて、データをシステムに残す必要があるためです

Mtreeに古い/余分なスナップショットがあるかどうかを確認するには、次の手順を実行する必要があります。

• 手順3に示すように、「mtree list」コマンドを使用して、システム上のMtreeのリストを取得する
• 「snapshot list」コマンドを使用して、各Mtreeにあるスナップショットの一覧を表示する：

• スナップショットが存在する場合、「snapshot list mtree [mtree name]」の出力を使用して、以下のスナップショットを確認します。

• 「snapshot list」コマンドを再度実行すると、これらのスナップショットは「expired」としてリストされます。

以下の点に注意してください。

• 個別のスナップショットまたはスナップショットのセットがディスク上に保持する物理データの量を判断することはできません。スナップショットに関連づけられた「領域」を示す唯一の値は、スナップショットが作成されたときのMtreeの圧縮前の（論理的な）サイズです（上記の出力を参照）
• 「REPL-MTREE-AUTO-YYYY-MM-DD-HH-MM-SS」という名前のスナップショットは、Mtreeレプリケーションによって管理され、通常の状況では、手動で失効させる必要はありません（これらのスナップショットが不要になった場合は、レプリケーションで自動的にこれらを失効させます）。そのようなスナップショットが非常に古い場合は、対応するレプリケーション コンテキストに大きな遅延が発生している可能性が高いことを示しています（「手順2」を参照）
• Mtreeレプリケーション コンテキストが中断されたときに、「REPL-MTREE-RESYNC-RESERVE-YYYY-MM-DD-HH-MM-SS」という名前のスナップショットがMtreeレプリケーションによって作成されます。それらは、中断したコンテキストを後で再作成する場合（例えば、コンテキストがエラーで中断した場合など）、レプリケーション データの完全な再同期を回避するために使用できます。レプリケーションが再確立されない場合は、前述のように、これらのコンテキストを手動で失効させることができます
• 失効にされたスナップショットは、次回のクリーニング/ガベージ コレクションが実行されるまでシステム上に残ります。この時点では、これらは物理的に削除され、「snapshot list mtree [mtree name]」の出力から消去されます。その後、クリーニングによりこれらのスナップショットがディスク上で使用していた領域を再利用できます

手順5 - システム上の予期しない数の古いファイルを確認する

DDRからの自動サポートには、次の例のように、DDR上のファイルの内訳を示すヒストグラム（経過時間別）が含まれています。
 
これは、クライアント バックアップ アプリケーションによって、適切に失効/削除されていないファイルがシステムに存在するかどうかを判断するのに役立ちます。例えば、1つのファイルの最大保存期間が6か月である場合に、バックアップ アプリケーションによって上記のシステムに書き込みが行われた場合、DDRに6か月より古いファイルが約8万ファイルあるため、バックアップ アプリケーションが適切にファイルを失効/削除していないことがすぐに分かります。

以下の点に注意してください。

• すべてのファイルの失効/削除を実行するのは、バックアップ アプリケーションの責任です
• DDRは、バックアップ アプリケーションによってファイルの削除を明示的に指示されている場合を除き、ファイルを自動的に削除することはありません。ファイルは、DDRで領域を使用して無期限に存続します

そのため、このような問題はまずバックアップ アプリケーション ベンダーのサポート チームが調査する必要があります。

必要に応じて、Data Domainサポートにより、次の目的で追加のレポートを提供できます。

• DDRにあるすべてのファイルの名前/変更時刻を、経過時間別に提供する（古いデータの名前/場所を判断できるように）
• ファイルの経過時間のヒストグラムを、アクティブ/アーカイブ/クラウド階層に分割する（ER/LTR機能が有効になっている）

これを実行するには、次の手順を実行します。

• この記事の「注」セクションにある「sfs_dumpの収集」の項の説明に従って、証拠を収集する
• 契約しているサポート プロバイダーでサービス リクエストを開始する

古い/余分なファイルが削除されたら、アクティブ階層のクリーニング/ガベージ コレクションを実行して、アクティブ階層の領域を物理的に再利用する必要があります。

手順6 - 大量の小さなファイルを含むバックアップを確認する

DDFSの設計により、小さなファイル（基本的におよそ10Mbよりも小さいファイル）は、最初にDDRに書き込まれるときに、余分な領域を消費することがあります。これは、「SISL」（Stream Informed Segment Layout）アーキテクチャが原因で、小さなファイルがディスク上で複数の個別の4.5Mbの領域ブロックを消費するためです。例えば、4Kbファイルは、最初に書き込みを行ったときに、実際には最大9Mbの物理ディスク領域を消費することがあります。

この過剰な領域は、あとでクリーニング/ガベージ コレクションの実行時に再利用されます（小さなファイルからのデータはより少ない数の4.5Mbブロックに集約されるため）。ただし、より小さいモデルのDDRでは、そのようなバックアップを実行すると、過剰な使用率とフィルが発生することがあります。

自動サポートには、次の例のように、サイズ別に分割されたファイルのヒストグラムが含まれます。
 
バックアップで非常に大量の小さなファイルを書き込んでいる証拠がある場合、クリーニング/ガベージ コレクションの各呼び出しの間で、使用率の一時的な急増によりシステムが影響を受ける可能性があります。このシナリオでは、すべての小さいファイルをDDRに書き込む前に単一の大規模なアーカイブ（tarファイルなど）に含むように、バックアップ方法を変更することをお勧めします。このようなアーカイブは、圧縮または暗号化してはならない点に注意してください（そのデータの圧縮比/重複排除率に悪影響があるため）。

手順7 - 予想より低い重複排除率を確認する

DDRの主な目的は、デバイスにより取得されるデータの重複排除および圧縮を行うことです。重複排除/圧縮の比率は、システムの用途やデータのタイプによって大きく異なりますが、多くの場合、概念のテストや同様の結果に基づく「適切な」全体の圧縮比があります。システムの現在の全体的な圧縮比を確認し、それに伴う適切な圧縮比の達成有無を確認するには、「filesys show compression」コマンドを使用できます。例：
 
上記の例では、システムはアクティブ階層で65.3xの全体的な圧縮比を達成しています（非常に良い）。ただし、この値が、適切な全体的な圧縮比を満たしていない場合は、さらに調査が必要になる可能性があります。予想よりも低い圧縮比の調査は、多くの根本原因を持つ可能性のある複雑なテーマであることに注意してください。さらに詳しく調査する方法の詳細については、次の記事を参照してください。https://support.emc.com/kb/487055

手順8 - システムがコレクション レプリケーションのソースであるかどうかを確認する

コレクション レプリケーションを使用する場合、ソース システムがターゲットよりも物理的に大きい場合は、ソース システムのサイズがターゲットと一致するように人為的に制限されます（つまり、ソース上のディスク領域の一部が使用不可としてマークされます）。その理由は、コレクション レプリケーションを使用する場合、ターゲットはソースのブロック レベルのコピーである必要がありますが、ソースがターゲットよりも物理的に大きい場合は、ソースに過剰なデータが書き込まれ、ターゲットにレプリケートできなくなる可能性があるためです（既にフルであるため）。このシナリオは、ターゲットと一致するようにソースのサイズを制限することで回避できます。

• 手順2のコマンドを使用して、システムがコレクション レプリケーションのソースであるかどうかを確認します。これを行うには、「replication status」を実行し、「col://」（コレクション レプリケーションを示す）で始まり、ターゲットのローカル システムのホスト名を含まない（このシステムがレプリケーション コンテキストのソースである必要があることを示す）、レプリケーション コンテキストがあるかどうかを確認します
• システムがコレクション レプリケーションのソースである場合は、両方にログインし、「filesys show space」コマンドを実行して、各システムのアクティブ階層のサイズをチェックします
• ソースがターゲットよりも大幅に大きい場合は、そのアクティブ階層のサイズは人為的に制限されます
• ソース上のすべての領域をデータが使用できるようにするには、次の操作を実行する必要があります。

手順9 - データ移動が定期的に実行されているかどうかを確認する

DDRがExtended Retention（ER）またはLong Term Retention（LTR）のいずれかで構成されている場合は、2つ目の階層のストレージが割り当てられます（ERにはアクティブ階層、またはLTRにはクラウド階層）。このシナリオでは、データ移動ポリシーがMtreeに対して構成されていて、長期保存を必要とする古い/未変更のデータをアクティブ階層から代替のストレージ階層に移行できる可能性が高くなります。これにより、アクティブ階層のこれらのファイルによって使用されていた領域を、クリーニング/ガベージ コレクションによって物理的に再利用できます。データ移動ポリシーが正しく構成されていない場合、またはデータ移動プロセスが定期的に実行されていない場合、古いデータは予想よりも長い間アクティブ階層に残り、ディスク上の物理的な領域を使用し続けます。

• 最初に、「filesys show space」を実行し、アーカイブまたはクラウド階層の有無を確認することにより、システムがERまたはLTRで構成されているかどうかを確認します。これを使用できるようにするには、これらの代替ストレージ階層の圧縮後サイズが0Gbより大きい(>)必要があります。

• システムがER/LTRで構成されている場合は、古いデータが代替ストレージ階層にプッシュされるようにMtreeに対するデータ移動ポリシーが適切に設定されていることを確認します。

• システムがER/LTRで構成されている場合は、定期的にアクティブ階層から代替ストレージにファイル/データが物理的に移行されるようにスケジュール設定されていることを確認します。

• システムがER/LTRで構成されている場合は、最後に実行されたデータ移動を確認します。

• データ移動が完了したら、アクティブ階層のクリーニングを実行する必要があります（データ移動が完了したときに自動的に開始するように構成されている可能性があることに注意してください）。これにより、アクティブ階層で移行されたファイルに使用されていた領域が物理的に解放されます。

手順10 - アクティブ階層にストレージを追加する

これまでの手順をすべて実行し、アクティブ階層のクリーニングが完了しても、アクティブ階層に十分な領域がない場合は、システムのサイズが受信するワークロードに対して適切に設定されていない可能性があります。この場合は、次のいずれかを実行する必要があります。

• システムにかかるワークロードを減らす - 例：

• システムのアクティブ階層にストレージを追加し、そのサイズを拡張する：

Data Domainサポートにより、次のような情報を表示する多数のレポートを生成できます。

• 特定の階層（アクティブ/アーカイブ/クラウドなど）にあるすべてのファイルのリスト（経過時間順）
• Mtree/メジャー ディレクトリー ツリーごとの推定サイズと圧縮比
• 特定のMtreeにあるすべてのファイルのリスト（経過時間順）
• など...

これを許可するには、次の情報を収集する必要があります。

• DDRからの新規サポート バンドル - 詳細については、https://support.emc.com/kb/323283を参照してください。
• 「sfs_dump」または「sfs_dump-c」の出力：

• ファイルの場所レポート（システムがERまたはLTRで設定されている場合に必要）：

上記を収集する際、またはこのアーカイブのクリーニングに関するいずれかの手順でサポートが必要な場合は、契約しているサポート プロバイダーにお問い合わせください。