Skip to main content

Disaster Recovery and RE-IP of VMware Aria Automation

https://knowledge.broadcom.com/external/article?articleNumber=378106


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:

    1. Prior to initiating the DR open an SSH session to the Aria Automation node with root credentials.
    2. 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.
    3. Update the network configurations on the Aria Automation Node.
      Execute the following command on the Aria Automation node: 

      • vracli network alternative-ip set --dns <DNSIPaddress1,DNSIPaddress2> <IPV4 address> <Gateway IPV4 address>

        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.

    4. 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:
        • /bin/bash -c "/usr/sbin/vracli network alternative-ip swap --force"

    5. 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.
    6. 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.
    7. Initiate a Re-trust with the identity manager for Aria Automation from vASL.
    8. Access the Aria Automation VM with new IP (Try SSH or launch the UI)

Failback of Aria Automation Standard Deployment:

    1. 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.
    2. Check if all the changes are reverted back to the original. if not, follow the below steps and update the configurations.
      1. 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.
      2. Update the IP, gateway, DNS, and netmask
        Execute the following command: 

        • vracli network alternative-ip set --dns <DNSIPaddress1,DNSIPaddress2> <IPV4 address> <Gateway IPV4 address>

          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.

    3. 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:
        • /bin/bash -c "/usr/sbin/vracli network alternative-ip swap --force"

    4. Reboot the VM
    5. 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.
    6. Initiate a Re-trust with the identity manager for Aria Automation from vASL.
    7. 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 :

    1. Prior to initiating the DR open an SSH session to each node of the Aria Automation with root credentials.
    2. 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.
    3. Update the Load Balancer with new IP's.
      • Virtual Server and Pool entries of IP addresses should be updated to new IP's
    4. Update the network configurations on each Aria Automation Node.
      Execute the following command on the Aria Automation node 

      • vracli network alternative-ip set --dns <DNSIPaddress1,DNSIPaddress2> <IPV4 address> <Gateway IPV4 address>

        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.

    5. 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:
        • /bin/bash -c "/usr/sbin/vracli network alternative-ip swap --force"

    6. By this stage the Aria Automation should be ready to run the recovery plan.
    7. 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.
    8. Initiate a Re-trust with the identity manager for Aria Automation from vASL.
    9. Access the Aria Automation VM with new IP (Try SSH or launch the UI)

Failback of Aria Automation Clustered Deployment :

    1. 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.
    2. 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
      1. 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. 
      2. Update the Load Balancer with new IP's.
        • Virtual Server and Pool entries of IP addresses should be updated to new IP's
      3. Update the IP, gateway, DNS, and netmask
        Execute the following command: 

        • vracli network alternative-ip set --dns <DNSIPaddress1,DNSIPaddress2> <IPV4 address> <Gateway IPV4 address>

          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.

    3. 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:
        • /bin/bash -c "/usr/sbin/vracli network alternative-ip swap --force"

    4. Reboot the VMs
    5. 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.
    6. Initiate a Re-trust with the identity manager for Aria Automation from vASL.
    7. Access the Aria Automation VM with new IP (Try SSH or launch the UI)

Comments

Post a Comment

Popular posts from this blog

  Issue with Aria Automation Custom form Multi Value Picker and Data Grid https://knowledge.broadcom.com/external/article?articleNumber=345960 Products VMware Aria Suite Issue/Introduction Symptoms: Getting  error " Expected Type String but was Object ", w hen trying to use Complex Types in MultiValue Picker on the Aria for Automation Custom Form. Environment VMware vRealize Automation 8.x Cause This issue has been identified where the problem appears when a single column Multi Value Picker or Data Grid is used. Resolution This is a known issue. There is a workaround.  Workaround: As a workaround, try adding one empty column in the Multivalue picker without filling the options. So we can add one more column without filling the value which will be hidden(there is a button in the designer page that will hide the column). This way the end user will receive the same view.  
Post a Comment
Read more

57 Tips Every Admin Should Know

Active Directory 1. To quickly list all the groups in your domain, with members, run this command: dsquery group -limit 0 | dsget group -members –expand 2. To find all users whose accounts are set to have a non-expiring password, run this command: dsquery * domainroot -filter “(&(objectcategory=person)(objectclass=user)(lockoutTime=*))” -limit 0 3. To list all the FSMO role holders in your forest, run this command: netdom query fsmo 4. To refresh group policy settings, run this command: gpupdate 5. To check Active Directory replication on a domain controller, run this command: repadmin /replsummary 6. To force replication from a domain controller without having to go through to Active Directory Sites and Services, run this command: repadmin /syncall 7. To see what server authenticated you (or if you logged on with cached credentials) you can run either of these commands: set l echo %logonserver% 8. To see what account you are logged on as, run this command: ...
Post a Comment
Read more
  The Guardrails of Automation VMware Cloud Foundation (VCF) 9.0 has redefined private cloud automation. With full-stack automation powered by Ansible and orchestrated through vRealize Orchestrator (vRO), and version-controlled deployments driven by GitOps and CI/CD pipelines, teams can build infrastructure faster than ever. But automation without guardrails is a recipe for risk Enter RBAC and policy enforcement. This third and final installment in our automation series focuses on how to secure and govern multi-tenant environments in VCF 9.0 with role-based access control (RBAC) and layered identity management. VCF’s IAM Foundation VCF 9.x integrates tightly with enterprise identity providers, enabling organizations to define and assign roles using existing Active Directory (AD) groups. With its persona-based access model, administrators can enforce strict boundaries across compute, storage, and networking resources: Personas : Global Admin, Tenant Admin, Contributor, Viewer Projec...
Post a Comment
Read more