ここでは、vRealize Network Insight のディザスタ リカバリ (DR) に関するサンプルシナリオの手順を示します。

手順

  1. 保護サイトとリカバリ サイトの両方で SRM が設定されていることを確認します。
  2. 保護対象の各 vRealize Network Insight ノードのレプリケーションを設定します。レプリケーションの設定中に、vRealize Network Insight インスタンスの適切な目標復旧ポイント (RPO) 時間を指定します。たとえば、単一のプラットフォームとコレクタ ノード（中サイズ）で構成される vRealize Network Insight 環境の場合、45 分の目標復旧ポイントが適切です。ただし、大きなサイズのブリックを使用するノードがあるクラスタの場合は、それに合わせて適切な目標復旧ポイントを指定する必要があります。スナップショット間隔の設定は、ユーザー環境と要件によって異なります。

  3. 保護グループを作成します。保護の対象とする仮想マシンを特定の保護グループに入れます。
  4. それぞれの保護グループを含むリカバリ プランを作成します。
  5. テスト リカバリを実行します。これは、リカバリ プランが予期したとおりに機能することを確認することを目的としています。
  6. SRM では、計画した移行を一定の間隔で実行して、既存の DR プランの整合性を検証することをお勧めしています。
  7. ここで仮に、リカバリ サイトが、vRealize Network Insight 仮想マシンに強制的に新しい IP アドレスを設定するネットワーク構成になっているとします。この場合、リカバリされた仮想マシンのネットワークに変更が発生することを想定していないリカバリ プランを使用して、vRealize Network Insight 仮想マシンをリカバリします。仮想マシンのリカバリが vRealize Network Insight で成功と報告されたら、新しい IP アドレスを vRealize Network Insight ノードに手動で割り当て、新しい証明書を適用して、クラスタを再初期化します。
  8. SRM での IPv4 カスタマイズは現在サポートされていないため、回避策として、ネットワークに変更がないかのように、vRealize Network Insight で DR を実行できます。
    ネットワーク設定を手動で割り当てるには、次の手順に従います。
    1. すべてのプラットフォームノードで、change-network-settings コマンドを同時に実行します。
    2. Platform1、Platform2、および Platform3 のノードで update-IP-change コマンドを連続して実行します。
    3. コレクタ ノードで vrni-proxy set-platform --ip-or-fqdn <with-updated-ip-of-Platform1> を実行します。
    4. サービスの状態を確認します。プラットフォーム ノードの一部のサービスが実行されていない場合は、推奨されている順序でノードを再起動します。