Data Domain：Data Domain Restorer (DDR)での長期保存/クラウド階層のクリーンアップ/ガベージ コレクションについて

Data Domain Operating System (DDOS) 6.0では、クラウド保存または長期保存(LTR)と呼ばれる新機能が導入されています。この機能を使用すると、クラウド プロバイダーによってプロビジョニングされたオブジェクト ベース ストレージの第2階層を、CLOUD_CAPACITYライセンスが関連付けられているData Domain Restorer (DDR)の特定のモデルに追加できます。

LTRを使用するシステムでは、DDRによって取り込まれたファイルは、最初にアクティブ階層（ローカルで接続されたストレージ）に書き込まれます。その後、長期保存を必要とする特定のファイルが、データ移行プロセス（定期スケジュール済みタスク）によってアクティブ階層からクラウド階層に移行されるように、mtree単位でデータ移行ポリシー/age-threshold（経過時間の閾値）が構成されます。

クラウド階層内のファイルは通常どおり削除できますが、クラウド/オブジェクト ストレージ上に関連付けられている領域はすぐには解放されません。不要なデータをクラウドから削除するには、クラウド階層をクリーンアップする必要があります。

クラウド階層の構造：

クラウド階層は「クラウド ユニット」に細分化されています。以下の点に注意してください。

• クラウド階層には、最大2つのクラウド ユニットを含めることができます
• 各クラウド ユニットは、特定のDDRモデルでサポートされているアクティブ階層の最大サイズと同じ大きさにすることができます
• 各クラウド ユニットは、異なるオブジェクト ストレージ プロバイダーからプロビジョニングできます

例：

# cloud unit list
Name                      Profile        Status
-----------------------   ------------   ------
B-unit                    LTR-ECS-Ben    Active <=== ECS provider
cloud-unit-virtustream1   virtustream1   Active <=== Virtustream provider
-----------------------   ------------   ------

クラウド クリーンアップの基本概念：

• クラウドのクリーンアップは、各実行中に1つのクラウド ユニットに対してのみ実行されます。クリーンアップ対象のクラウド ユニットを特定するには、DDFSログ(/ddr/var/log/debug/ddfs.info)で次のメッセージを確認します。この場合は、cloud-unit-virtustream1クラウド ユニットがクリーンアップされています。

• システムに複数のクラウド ユニットが構成されている場合、これらのユニットはラウンド ロビン方式でクリーンアップされ、クリーンアップを実行するたびに単一のユニットがクリーンアップされます。
• クラウドのクリーンアップは、手動で開始するか、またはスケジュールを介して自動的に開始できます。手動で開始するには、次のコマンドを使用します。

• アクティブ階層のクリーンアップとクラウドのクリーンアップを並行して実行することはできません（両方ともDDFS内で同じメモリー構造を使用しているため）。
• アクティブ階層のクリーンアップが実行中（手動またはスケジュールで開始）で、クラウドのクリーンアップを開始しようとすると、次のようなエラーが発生します。

• クラウドのクリーンアップが自動的に開始されている場合に（スケジュールを介して）、アクティブ階層のクリーンアップを開始すると、アクティブ階層のクリーンアップを実行できるように、クラウド ユニットのクリーンアップが中止されます。これは、DDFSログに次のように示されます。

• クラウドのクリーンアップが手動で開始されている場合に、アクティブ階層のクリーンアップを開始しようとすると、アクティブ階層のクリーンアップは開始に失敗します。クラウドのクリーンアップは、完了するまでそのまま実行されます。これは、次のように表示されます。

• クラウドのクリーンアップを開始するには、クラウド ユニットで少なくとも1%のデータ「チャーン」が発生している必要があります（つまり、クラウド ユニットに現存するデータの>= 1%が余剰であると判断され、削除可能である必要があります）。そうでない場合、クラウドのクリーンアップを手動で開始すると、コマンド ラインに次のように表示されます。

• システムに2つのクラウド ユニットが含まれていて、1つ目のユニットのスケジュール済みクリーンアップが何らかの理由（チャーンが不十分であるなど）で失敗した場合、2つ目のユニットに対してクリーンアップが自動的に開始されます（つまり、2つ目のユニットをクリーンアップするために次にスケジュール設定されたクラウド クリーンアップの実行を待つ必要はありません）。
• クラウドのクリーンアップは、（アクティブ階層のクリーンアップと同様に）スロットルして、システムが他の重要なワークロード（取得/リストア/レプリケーション）下にある場合に実行する必要があるアクションを決定できます。

クラウド クリーンアップのスケジュール設定：

DDOS 6.0以降では、アクティブ階層のクリーンアップをスケジュールする方法は変更されていません。デフォルトでは、アクティブ階層のクリーンアップは週に1回火曜日の0600に実行されるようにスケジュールされています。これは、次のように確認できます。

# filesys clean show schedule
Filesystem cleaning is scheduled to run "Tue" at "0600"

デフォルトでは、クラウドのクリーンアップは、アクティブ階層のスケジュール済みクリーンアップが4回呼び出されるたびに実行されるようにスケジュール設定されています。クラウドのクリーンアップ スケジュールを表示するには、次のコマンドを使用する必要があります。# cloud clean frequency show
Cloud tier cleaning frequency is set to run after every 4 active tier cleaning cycles

その結果、デフォルト構成のシステムでは、クラウドのクリーンアップは4週間毎に開始されます。システムに2つのクラウド ユニットがある場合、各ユニットは8週間に1回クリーンアップされます。

クラウド クリーンアップの頻度を変更するには、次のコマンドを使用できます

# cloud clean frequency set 2
Cloud tier cleaning frequency is set to run after every 2 active tier cleaning cycles

クラウドのクリーンアップをデフォルトのスケジュール（4回のアクティブ階層クリーンアップのたび）にリセットするには、次のコマンドを使用できます

# cloud clean frequency reset
Cloud tier cleaning frequency is reset to default (every 4 active tier cleaning cycles)

クラウドのクリーンアップ スケジュールには、手動で開始されたアクティブ階層のクリーンアップ サイクルは含まれないことに注意してください。その結果、上記のシステムでは、アクティブ階層のクリーンアップが毎日手動で実行された場合でも、クラウド階層のクリーンアップは4週間に1回しか開始されません。

次のコマンドを使用して、スケジュール済みクラウド クリーンアップを完全に無効にすることもできます# cloud clean frequency set never
Cloud tier cleaning frequency is set to "never".

この場合、クラウドのクリーンアップは、手動で開始した場合にのみ実行されます。

現在実行中のクラウド クリーンアップを停止するには、次のコマンドを使用できます

# cloud clean stop

クラウド クリーンアップが最後に実行された日時を確認するには、次のコマンドを使用できます。

# cloud clean status
Cloud tier cleaning finished at 2016/08/01 20:54:43.

クラウド クリーンアップのアルゴリズム：

クラウド クリーンアップでは、アクティブ階層に対して構成されているものと同じクリーンアップ アルゴリズムが使用されます。DDOS 6.0以降では、これはデフォルトで完全な物理ガベージ コレクション(PPGC)に設定されますが、システム パラメーターを介して物理ガベージ コレクション(PGC)に変更できます。

従来のフル クリーンアップ アルゴリズムを使用してクラウド ユニットをクリーンアップするとDDFSのパニック/再起動が発生する可能性があるため、物理ガベージ コレクションを無効にしないでください。

クラウド クリーンアップに使用されるアルゴリズムは、クリーンアップの開始時に、次のようにDDFSログに表示されます。

06/28 10:51:56.960 (tid 0x7fc5bccb2d50): gc: gc_start_intern: Algorithm selected: Physical Cleaning <=== PPGC or PGC
07/27 12:21:18.224 (tid 0x7f92b8cfe7e0): gc: gc_start_intern: Algorithm selected: Full Cleaning <=== Traditional GC

上記の出力からは、PPGCとPGCを区別することはできません。使用されている特定のアルゴリズムは、一般的にクリーンアップによって実行されるフェーズの数から明らかです。

従来のフルGC：10フェーズ
PGC：12フェーズ
PPGC：6フェーズ

システムで使用されるクリーンアップ アルゴリズムの変更方法に関する詳細については、契約しているサポート プロバイダーにお問い合わせください。

アクティブ階層のクリーンアップとクラウド階層のクリーンアップでのコピー フェーズの違い：

クリーンアップのコピー フェーズは、DDR上の余分なデータを物理的に削除し、領域を解放するフェーズです。アクティブ階層とクラウド階層に対するコピー フェーズの動作には違いがあることに注意してください。

アクティブ階層：

• DDRのアクティブ階層に書き込まれたデータは、4.5Mbコンテナ内に格納されます。
• デフォルトでは、コンテナに<= 92%の「ライブ」（つまり、アクティブに参照されている）データが含まれている場合にのみ、クリーンアップによって「コピー対象」と見なされます。
• ライブ データはコンテナから抽出され、ファイル システムの最後にある新しいコンテナに（コピーされた他のコンテナからのライブ データとともに）書き込まれます。
• ディスク上のインデックスは、ライブ データを保持する新しいコンテナを反映するように更新されます。
• その後、元のコンテナ（ライブ データとデッド データの両方を保持）が削除され、基盤となるディスク領域が使用可能になります。

クラウド階層：

• DDRのクラウド階層に書き込まれたデータの構造は異なります。4.5Mbのコンテナ内に個々のデータ チャンク（64Kbの圧縮領域）を配置するのではなく、クラウド ユニットに書き込まれます（メモ：DDOS 6.1.2.0以降では、クラウド ユニットに格納されるオブジェクトのサイズが大きくなります。「Data Domain：クラウド階層向けの大規模なオブジェクト サイズ（英語）」を参照してください）。
• クラウドのクリーンアップでは、既存の圧縮領域からライブ データを抽出してこれをコピー転送する代わりに、デッド データのみを含む圧縮領域だけを削除対象として考慮します。

この違いは、クラウド ストレージ上での大量データの読み取り/書き込みに固有のコストによるものですが、クラウド ユニットが人為的にいっぱいになる可能性があることを意味します（つまり、多数の圧縮領域が含まれ、それぞれにごく少量のライブ データが含まれているため、削除が妨げられます）。

この状況が発生した場合は、クラウド ユニットの「デフラグとクリーンアップ」を強制的に実行するようにシステム パラメーターを設定できます。これにより、既存の圧縮領域からライブ データがコピー転送され、ライブ データが可能な限り少ない圧縮領域に統合され、領域を解放できるようになります。

「デフラグとクリーンアップ」の実行方法に関する詳細については、契約しているサポート プロバイダーにお問い合わせください。