Disaster Recovery and RE-IP of VMware Aria Automation
book
Article ID: 378106
calendar_today
Updated On:
Products
VMware Aria Suite
Issue/Introduction
This article aims to provide the outline of DR plan for Aria Automation set up.
Environment
VMware Aria Automation 8.x
Resolution
Note: Aria Automation needs to be the first product to be powered off on the source site prior to initiating the failover and the last Product to be powered on in the destination site post failing over due to dependency of the vIDM for being its authentication provider and vASL for managing this configuration.
For details on procedure for DR and Re-IP of VMware Aria Suite Lifecycle (vASL), Click here.
For details on procedure for DR and Re-IP of VMware Identity Manager (vIDM), Click here.
DR and RE-IP of Aria Automation Standard Deployment
Failover of Aria Automation Standard Deployment:
Prior to initiating the DR open an SSH session to the Aria Automation node with root credentials.
Update the DNS mappings for New IP in DNS servers to the existing Hostname:
From the existing name server mapping we need to remove the old IP and add the new IP against the existing product hostname.
Update the network configurations on the Aria Automation Node. Execute the following command on the Aria Automation node:
Where, <DNSIPaddress1,DNSIPaddress2> are the addresses of the DNS servers on the fail-over site. <IPV4 address> is the IP address on the fail-over site. <Gateway IPV4 address> is the IP address of the Gateway on the failover site.
Go to Site Recover Manager or DR tool of choice and for the Aria Automation node, configure Post Power On Steps command that would be started after the Virtual Machine is recovered on the disaster recovery site.
If using SRM: Navigate to: Recovery Plans → Virtual Machines → select Virtual Machine → Configure Recovery→ Post Power On Steps → Command on Recovered VM. Set the following command:
By this stage the Aria Automation should be ready to run the recovery plan. Run the recovery Plan. If you're not using SRM and your DR tool of choice doesn't permit you to add the above ruleset from Step 4, you may need to manually run this when powering ON the node post failover.
Post failing over vASL and vIDM, Run Inventory Sync in vASL for Aria Automation to update the new IP address in the vASL inventory
If a failure occurs at the snapshot update task skip the task in the request and proceed.
Trigger Inventory Sync again to make sure there are no failures.
Initiate a Re-trust with the identity manager for Aria Automation from vASL.
Access the Aria Automation VM with new IP (Try SSH or launch the UI)
Failback of Aria Automation Standard Deployment:
Re-protect (SRM option) or reverse the direction of the failover and Run the disaster recovery of the Aria Automation instance using SRM or DR tool of choice.
Check if all the changes are reverted back to the original. if not, follow the below steps and update the configurations.
Update the DNS mappings in DNS servers for Original IP's to existing Hostnames.
Remove the new IP to Hostname Mappings and add the old IP against the mapping.
Update the IP, gateway, DNS, and netmask Execute the following command:
Where, <DNSIPaddress1,DNSIPaddress2> are the addresses of the DNS servers on the fail-over site. <IPV4 address> is the IP address on the fail-over site. <Gateway IPV4 address> is the IP address of the Gateway on the failover site.
Go to Site Recover Manager or DR tool of choice and for the Aria Automation node, configure Post Power On Steps command that would be started after the Virtual Machine is recovered on the disaster recovery site.
If using SRM: Navigate to: Recovery Plans → Virtual Machines → select Virtual Machine → Configure Recovery→ Post Power On Steps → Command on Recovered VM. Set the following command:
Post Failback of vASL and vIDM, Run Inventory Sync in vASL for Aria Automation to update the new IP address in the vASL inventory Initiate a Re-trust with the identity manager for Aria Automation from vASL.
If a failure occurs at the snapshot update task skip the task in the request and proceed.
Trigger Inventory Sync again to make sure there are no failures.
Initiate a Re-trust with the identity manager for Aria Automation from vASL.
Access the Aria Automation VM with new IP (Try SSH or launch the UI)
DR and RE-IP of Aria Automation Clustered Deployment
Failover of Aria Automation Clustered Deployment :
Prior to initiating the DR open an SSH session to each node of the Aria Automation with root credentials.
Update the DNS mappings for New IP in DNS servers to the existing Hostname:
From the existing name server mapping we need to remove the old IP and add the new IP against the existing product hostname.
Update the Load Balancer with new IP's.
Virtual Server and Pool entries of IP addresses should be updated to new IP's
Update the network configurations on each Aria Automation Node. Execute the following command on the Aria Automation node
Where, <DNSIPaddress1,DNSIPaddress2> are the addresses of the DNS servers on the fail-over site. <IPV4 address> is the IP address on the fail-over site. <Gateway IPV4 address> is the IP address of the Gateway on the failover site.
Go to Site Recover Manager or DR tool of choice and for each Aria Automation node, configure Post Power On Steps command that would be started after the Virtual Machine is recovered on the disaster recovery site.
If using SRM: Navigate to: Recovery Plans → Virtual Machines → select Virtual Machine → Configure Recovery→ Post Power On Steps → Command on Recovered VM. Set the following command:
By this stage the Aria Automation should be ready to run the recovery plan.
Post failing over vASL and vIDM, Run Inventory Sync in vASL fro Aria Automation to update the new IP address in the vASL inventory
If a failure occurs at the snapshot update task skip the task in the request and proceed.
Trigger Inventory Sync again to make sure there are no failures.
Initiate a Re-trust with the identity manager for Aria Automation from vASL.
Access the Aria Automation VM with new IP (Try SSH or launch the UI)
Failback of Aria Automation Clustered Deployment :
Re-protect (SRM option) or reverse the direction of the failover and Run the disaster recovery of the Aria Automation instance using SRM or DR tool of choice.
Check if all the changes are reverted back to the original. if not, follow the below steps and update the configurations. The below needs to be done on each node of the Aria Automation Cluster
Update the DNS mappings in DNS servers for Original IP's to existing Hostnames.
Remove the new IP to Hostname Mappings and add the old IP against the mapping.
Update the Load Balancer with new IP's.
Virtual Server and Pool entries of IP addresses should be updated to new IP's
Update the IP, gateway, DNS, and netmask Execute the following command:
Where, <DNSIPaddress1,DNSIPaddress2> are the addresses of the DNS servers on the fail-over site. <IPV4 address> is the IP address on the fail-over site. <Gateway IPV4 address> is the IP address of the Gateway on the failover site.
Go to Site Recover Manager or DR tool of choice and for each Aria Automation node, configure Post Power On Steps command that would be started after the Virtual Machine is recovered on the disaster recovery site.
If using SRM: Navigate to: Recovery Plans → Virtual Machines → select Virtual Machine → Configure Recovery→ Post Power On Steps → Command on Recovered VM. Set the following command:
Post Failback of vASL and vIDM, Run Inventory Sync in vASL for Aria Automation to update the new IP address in the vASL inventory Initiate a Re-trust with the identity manager for Aria Automation from vASL.
If a failure occurs at the snapshot update task skip the task in the request and proceed.
Trigger Inventory Sync again to make sure there are no failures.
Initiate a Re-trust with the identity manager for Aria Automation from vASL.
Access the Aria Automation VM with new IP (Try SSH or launch the UI)
Additional Information
Please refer to the following document for further details on Aria Automation using SRM: Click here.
Please refer to the following document for further details on Aria Automation outside of SRM: Click here.