SRM - vRealize/Aria Automation appliance recovery with ip change

Previous article I was checking on the vRealize components recovery without changing IP over stretched network.

The vRealize Automation IP can be changed from vRA version 8.6 but it doesn’t allow to change the hostname name, here i did test with recovering vRealize automation appliance in different network on recovery Site . While recovering we have to update the DNS record to new IP and VIP IP’s. The alternate IP must be set in vRA nodes, It's a one time setup to prepare vRA nodes for the IP swap when recovering.

Fig 1

Fig 1, I have vRLCM, single node vIDM and single node vRA are connected in primary site Local segment named Site-A-Local-Segment on the network 10.10.10.0/24.

Fig 2

Fig 2, The VM’s will be recovered on the Site B recovery site in the network Site-B-Local-Recovery-Segment on the network 10.10.20.0/24.

Fig 3

Fig 4

Fig 3,Fig 4, SRM paired with Primary Site-A and the recovery Site-B with vSphere Replication.

Fig 5

Fig 5, Network mapping created to use the Site-B-Local-Recovery-Segment when the VM’s recovered on Site-B.

Fig 6

Fig 6, Protection group named vRA-PG created and included vRLCM, vIDM and vRA appliances.

Fig 7

Recovery plan vRA-Recovery has been created to recover. Then the IP customisation to be include in the recovery plan.

VM Recovery Priority Order

vIDM - Power On priority 1

vRLCM - Power On Priority 2

vRA - Power On Priority 3

Fig 8

Fig 8, IP customisation command has been included in the vIDM post power on Step with the IP 10.10.20.6 in network 10.10.20.0/24.

Fig 9

Fig 9, IP customisation command has been included in the vRLCM VM post power on Step with the IP 10.10.20.5 in network 10.10.20.0/24

Fig 10

Fig 10, IP swap command has been included in the vRA post power on Step to assign the alternate IP assigned to the vRA appliance.

Fig 11

Fig 12

Fig 13

Fig 11,12,23, Current IP address of vRLCM, vIDM and vRA appliances.

Fig 14

Fig 14, We need to assign the alternate IP to vRA appliance before the recovery so the vRA nodes will be prepared for IP swap. This is one time assignment no need to assign alternate IP every time. If we run vRA cluster then the alternate IP needs to be assigned to all nodes.

Fig 15

Fig 15, Verify alternate IP assignment.

Execute Recovery

Now let’s execute the recovery plan vRA-Recovery.

Fig 16

Fig 16, running recovery plan vRA-Recovery

Fig 17

Fig 17, I have included a user prompt to notify DNS record change to the recovery IP, if we have vRA/vIDM cluster then we have to update dns record for the VIP also. Please note if the certificate included with the IP then the certificate must included with the alternate IP as well, in my case i used a wildcard certificate.

Fig 18

Fig 18, if we use vIDM cluster then the floating IP will get lost, assign the floating IP from the recovery network as mentioned in the KB.

Fig 19

Fig 19, after the vidm and vrlcm appliance recovered I have included a step to run the inventory sync to import the vIDM to vRLCM with new IP address from recovery site vCenter.

Fig 20

Fig 20, triggered inventory sync to import the vIDM to vRLCM.

Fig 21

Fig 21, vIDM inventory sync will fail in first time because it was trying to import from primary site, now we have to mention recovery site vCenter and then retry.

Fig 22

Fig 22, provided recover site vCenter information then submit.

Fig 23

Fig 23, Received one more error due to snapshot inventory sync, I did skipTask true then it’s get completed and imported to vRLCM.

Fig 24

Fig 24, vRA VM’s get powered on now let’s wait until the vRA service are up it may take 15 min, we can check the status by taking ssh into vRA appliance.

Fig 25

Fig 25, now let’s run inventory sync for vRA in vRLCM.

Fig 26

Fig 27

Fig 26, 27 same error like vIDM import, did updated recovery site vCenter and skipped snapshot inventory task.

Fig 28

Fig 28, import completed and i can access the vRA self service console from Site B with different network IP mapped with same fqdn.