ディザスタ リカバリ シナリオの例

ここでは、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 を実行して、すべてのプラットフォームで IP アドレスを同時に変更します。
   2. IP アドレスが変更されたすべてのプラットフォームごとに、他のすべてのノードから update-IP-change コマンドを実行します。

      たとえば、platform1 の IP アドレスを IP1 から IP2 に変更する場合は、IP1 と IP2 を引数として指定して platform2 および platform3 で update-IP-change コマンドを実行します。platform2 の IP アドレスを変更するには、platform1 および platform3 で update-IP-change コマンドを実行します。

   3. 手順 1 と手順 2 が完了したら、platform1 で finalize-IP-change コマンドを実行します。
   4. コレクタ ノードで vrni-proxy set-platform --ip-or-fqdn <with-updated-ip-of-Platform1> を実行します。
   5. サービスの状態を確認します。プラットフォーム ノードの一部のサービスが実行されていない場合は、推奨されている順序でノードを再起動します。