Sample Disaster Recovery Scenario

Here are the steps for a sample scenario for vRealize Network Insight Disaster Recovery (DR):

Procedure

1. Ensure that SRM is configured and up in both the protected and the recovery sites.
2. Configure replication for each of the vRealize Network Insight nodes that are to be protected. While configuring the replication, provide adequate Recovery Point Objectives (RPO) time for the vRealize Network Insight instance. For example, if it is a vRealize Network Insight deployment with a single platform and collector nodes (medium size), then RPO of 45 minutes is good. But if it is a cluster with nodes having bricks of large size, then the adequate RPO should be provided. The snapshot interval configuration is specific to the user environment and requirement.
   
3. Create protection group. Include the VMs that you want to protect under a specific protection group.
4. Create the recovery plan where you include the respective protection groups.
5. Perform test recovery. This is to ensure that your recovery plan works as expected.
6. SRM recommends that users perform planned migration at regular intervals to validate the integrity of the existingDR plan.
7. Suppose the recovery site has a network configuration that forces the vRealize Network Insight VMs to come up with the new IPs. Recover the vRealize Network Insight VMs with a recovery plan that assumes no network change for the recovered VMs. Once the recovery of the VMs is reported as a success in vRealize Network Insight, assign new IP addresses manually to the vRealize Network Insight nodes, apply new certificates, and re-initialize the cluster.
8. As IPv4 customization with SRM is not supported currently, as a work around you can perform DR with vRealize Network Insight assuming as if there is no network change.
   To manually assign the network settings:

   1. Run the change-network-settings to change the IP simultaneously on all platforms.
   2. For every platform whose IP is changed, run update-IP-change command on all the other nodes.

      For example, for the IP change of platform1 from IP1 to IP2, run the update-IP-change command on platform2 and platform3 with IP1 and IP2 as the arguments. For the IP change of platform2, run the update-IP-change command on platform1 and platform3.

   3. Run finalize-IP-change command once on platform1 after step1 and step 2 are completed.
   4. Run vrni-proxy set-platform --ip-or-fqdn <with-updated-ip-of-Platform1> on the collector node.
   5. Check the service status. If some of the services on the platform nodes are not running, reboot the nodes in the recommended order.