NetWorker：Data Domainのスペース リカバリー操作の最適化

• NetWorkerセーブセットに期限切れのマークが付けられているが削除されていない
• スペース リカバリー メッセージが1日に2回以上ログに表示される
• Data Domainの速度と負荷への影響
• 一般的なサーバー パフォーマンス インパクト

• スペース リカバリーの対象となるボリュームがExpiryアクション(ステージング、クローニング、リカバリー)中に読み取りを行っている
• 領域のリカバリーは、特定のボリュームでステージング操作が行われるたびにデフォルトで実行されます
• スペース リカバリーの実行時に、スペース リカバリーはボリューム ディレクトリー構造内の各ファイルをチェックします
• スペース リカバリー フェーズ中にサーバーの動作と応答性が低下する場合がある

NetWorkerの領域リカバリー フェーズは、サーバー バックアップ ワークフローの有効期限アクションの最終フェーズの1つとして1日に1回実行されます。これは、構成に従って安全に削除できるセーブ セット レコードを計算した後、サーバーによるセーブ セット レコードの評価、期限切れ、削除の後に、ボリューム内のセーブセット ファイル オブジェクトを削除することを目的としています。

Data DomainまたはNetWorkerサーバーの応答性に悪影響を及ぼす可能性のある要因はいくつかあります。対象のデータゾーンの要件に適合していると思われる下記のいずれかを有効にします。以下のデバッグキーファイルを使用したテストを検討する前に: 日次サーバー保護>サーバー バックアップ>有効期限アクションを無効にして、発生したパフォーマンスの問題がスペース リカバリーや有効期限アクティビティに関連していることを確認するために、1日以上のすべてのリカバリー スペースとメディア データベースの計算を無効にします

有効期限を無効にすることで日常メンテナンスに関連する問題が確認された場合は、メインnsrディレクトリーのデバッグ サブディレクトリーの下のNetWorkerサーバーまたはノードに同じ名前(拡張子なし)の空のファイルを作成することで、トラブルシューティングのために次の機能を無効にすることができます。これらのフラグ ファイルはいずれも再起動を必要とせず、それらが存在する間に起動された領域のリカバリー ジョブで有効になります

Linuxの場所: /nsr/debug
Windowsの場所: C:\Program Files\EMC NetWorker\nsr\debug (または対応するnsrインストール パス)
 

ファイル名とその機能の詳細は次のとおりです:

skip_recover_space_for_stage

• ストレージ ノード。このフラグを設定すると、NetWorkerはステージング操作の領域リカバリー フェーズ(クローン作成後のソース削除)をスキップします。ご使用の環境でステージングを使用する場合、特に同じソース ボリュームからの繰り返しステージングを使用する場合は、同じボリュームに対して複数のリカバリー領域操作が発生する可能性がなくなるため、この方法を使用することをお勧めします。このフラグを設定すると、領域のリカバリー操作は完全に延期され、有効期限の日次アクションの実行時、またはnsrimコマンドが手動で実行されたときに、システムがファイルを削除できるようになります。 

recover_space_anytime

• サーバーのみ。これにより、アクティブに読み取りを行っているボリューム上のセーブセットをリカバリー スペースが期限切れになり、削除が実行されます。これはデフォルトで延期されます。つまり、実行時間の長いクローン ジョブがあるボリュームの場合、Expirationアクション、 nsrim、またはステージング ジョブ(前項を参照)を実行すると、有効期限とスペース リカバリーを繰り返し延期できます。これにより、スペース リカバリーのバックログが大きくなり、空きスペースが徐々に減少し、実行が許可されているときにスペース リカバリー ジョブが大きくなる可能性があります。 

skip_disk_usage

• ストレージ ノード。デフォルトでは、スペース リカバリーおよびディスク ボリュームのファイル システム チェックの一環として、個々のファイルが再帰的にチェックおよびカウントされ、ボリュームの正確なデータ集計が生成されます。この精度が不可欠だと考える人もいるかもしれませんが、この手順を延期すると、ファイルとバイトの合計に関するNetWorkerのメディア データベース レコードに依存することになります。これは通常、ほとんどの用途で十分に正確であることが期待できます。Data Domainの負荷が高い場合、特にボリュームに対して多くの領域のリカバリー操作が繰り返し実行される場合、これは無駄なコストと見なすことができ、安全に無効化できます。

skip_consistency_check_in_recover_space

• ストレージ ノード。ボリュームのスペース リカバリー中に、ボリューム ファイル システムはファイルごとにチェックされ、メディア データベース間の整合性が確保されます。これにより、レイテンシーが発生する可能性もあります。このキーファイルを各ノードに追加すると、そのノードは、対応するレコードがメディア データベースに存在しないセーブセット ファイルを削除したり、ファイルが見つからないメディア データベース レコードを「要注意」としてマークしたりできなくなります。これにより通常のクリーニング操作が妨げられるため、領域のリカバリー操作に関連するレイテンシーを見極めるために使用する必要があります。長期間無効にしないでください。 

より詳細なログがデフォルトで導入されました。これにより、セーブセット パス全体がNetWorkerサーバーの data_auditログに記録されます。すでに負荷の高い、多くの/大規模なスペースのリカバリー ジョブがある場合、これは、特にNetWorkerにリモートで情報を返すストレージ ノードから応答しなくなる要因です。これを無効にするには、NetWorkerサーバーでこれらのログのログしきい値を上げます。

# nsradmin
# nsradmin> show name; auditlog severity
# print type: nsr auditlog

この変更は、必要に応じて、名前を含めて特定のインスタンスにクエリを絞り込むことで、データ監査にのみ影響するように制限します。それぞれに設定を再適用するには、この手順をスキップします。

# print type: nsr auditlog; name: servername_data_audit.raw

個々の削除のログ記録を停止するには、しきい値の一方または両方を「エラー」に変更します。削除は引き続きサーバーのdaemon.rawに記録されます。

# update auditlog severity: Error