Sample Disaster Recovery Scenario

Here are the steps for a sample scenario for VMware Aria Operations for Networks 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 VMware Aria Operations for Networks nodes that are to be protected. While configuring the replication, provide adequate Recovery Point Objectives (RPO) time for the VMware Aria Operations for Networks instance. For example, if it is a VMware Aria Operations for Networks 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 VMware Aria Operations for Networks VMs to come up with the new IPs. Recover the VMware Aria Operations for Networks 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 VMware Aria Operations for Networks, assign new IP addresses manually to the VMware Aria Operations for Networks 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 VMware Aria Operations for Networks 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 pair-collector 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.