NetWorker：Data Domain間の容量モードvProxyクローン ジョブのパフォーマンスの問題

• vProxyのクローン作成速度がGB/秒から従来の現実的な速度に低下しました。
• ネットワーク帯域幅はボトルネックの原因として除外され、クローン作成中の閾値を大きく下回っています。
• メッセージはddfsにあります。次を含む影響を受けるVMのディスクについて、1つ以上の*-flat.vmdkファイルを参照する情報ログ。
  • synthesized_vbytes 0で終了し、recipe_repl FALSEで終わる
  • srepl_filecopy_recipe_validate_bf:ベース ファイルのsrepl_get_replica_attr、ファイル ハンドルが古いというエラーで終わる。
• クローン アクション ログに表示されるメッセージ(クローン デバッグ レベルが3以上の場合)は、次を含む影響を受けるVMのディスクについて、1つ以上の*-flat.vmdkファイルを参照します。
  • 合成レプリケーションは、ファイルに使用できません...path.../vm-vmnumber-disk-key-disknumber-flat.vmdk

vProxyは、仮想合成を使用してVMwareの変更ブロック追跡APIを活用し、バックアップ操作とクローン作成操作の両方に大きなメリットを提供します。これには、関連する各Data Domain上のVMファイルセットの内部関連づけのアクティブなメンテナンスが必要です。仮想合成を使用したクローン作成の準備中に問題が発生した場合は、代わりにNetWorkerとData Domainがデフォルトのレプリケーション ワークフローを使用してフェールバックします。これには、VMware APIによって提供される変更されたブロックだけでなく、変更されたブロックだけでなく、仮想ディスク ファイル全体の処理が必要です。重複排除によって送信されるデータが少ない場合でも、クローン作成ジョブの期間は複数増加する可能性があります。

仮想合成トラッキングの失敗につながる可能性がある原因は次のとおりです。

• ジョブ間でソースまたはデスティネーションのData Domainデバイスに対してNetWorkerによって解決される異なるIPアドレス-これらは、仮想合成の内部トラッキングで整合性を維持する必要があります。
• vProxyバックアップまたはクローンのソースまたはデスティネーションData Domainの変更
• vProxyバックアップまたはクローン用の複数のソースまたはデスティネーション ボリューム。これにより、チェーン内の複数のセーブセットの同時クローン作成につながる可能性がある
• 特定のVMのクローン作成を必要とする複数のvProxyセーブセットにより、チェーン内のセーブセットのクローン作成が妨害される可能性がある
• 変更なしで長期間使用されるVMディスク(特に、保存期間が30日の場合は変更のない35日間など、セーブセットの保存期間を超える期間)
• NetWorker 19.6以降を使用している場合、時系列順序アクション プロパティを使用できない

多くの潜在的な原因があるため、Data DomainとNetWorkerの構成を確認し、次のことを確認します。

• ifgroupsは、ソース(バックアップ)とデスティネーション(クローン ターゲット)の両方のData Domainに対して正しくセットアップされている
• NetWorkerサーバー、ストレージ ノード、Data Domainはすべて、Data Domainごとに適切なifgroup IPを使用してhostsファイル エントリーを持ち、クライアントに信頼できるDNSを使用します(NetWorkerクライアントは必要なファイルをホストします)。
• バックアップおよびクローン プールごとに1つのData Domain。

NetWorker 19.5以下を使用する場合:

• クローン ジョブが、バックアップの順序でシリアルに実行されていることを確認します。特定のVMの複数のクローンが同じジョブ リスト(クローン アクションまたはnsrcloneセーブセット ファイル リスト)にある場合は、これを制御できないことに注意してください。
• ソースに複数のボリュームが使用可能な場合にコンカレント クローン作成を回避するために、プールごとに単一のバックアップ ボリュームとクローン ボリュームを確保します。

NetWorker 19.6の時点では、vProxyセーブセット クローン アクションの時系列順序機能を常に有効にする必要があります。これはUIで非表示になっている可能性があります。

• nsrcloneコマンドを使用する場合は、-Oスイッチを使用して、特定のクライアント チェーン内で複数のセーブセットを含むセーブセット リストを使用する場合に、この新機能を適用します。
• ポリシーでを有効にするには、次の2つのコマンドのいずれかを使用します。

  • nsrpolicy action update clone -p policyname -w workflowname -A actionname [--chronological_order | -l] 

  • nsradminプロンプトで、次の操作を実行します。

    • . type nsr protection policy action; policy name: policy; workflow: workflow: name: action

    • update Chronological order: Yes

      
       
• これが完了すると、前述した単一のソースボリュームと宛先ボリュームの制限、およびVMクライアントごとのマルチインスタンス増分が持ち上げられ、適切に処理できます。

重要：NetWorkerとData Domainのリカバリー元となる状況によっては、セーブセットが順を追ってクローン作成される場合があります。これにより、レプリケーションにVSRを使用できないものもありますが、チェーン全体がリストアされると、VSRクローン作成が問題なく続行される可能性があります。一般的に、順序外のクローン作成、マルチボリューム、マルチセーブセットのクローン作成は、通常の操作に追いついて戻る可能性があります。

ただし、複数のData Domain IPアドレスがすでに使用されているか、Data Domainのソースまたはデスティネーションを完全に変更している場合、通常の一貫性のあるVSR最適化に戻る唯一の方法は、影響を受けるVMの新しいフル バックアップを強制的に実行して、変更されたブロック追跡をリセットし、VSR最適化をリストアすることです。これは、前のステップが完了した場合に考慮する必要がありますが、Data Domainおよび/またはNetWorkerのログ記録とクローン作成速度は、パフォーマンスの問題が残っていることを示しています。