vRealize Automation 7 – Part 2, Deployment Architectures

Automation, Cloud, Management, VMware, vRA6 Comments

VMware has been tackling several customer pain points when it comes to deploying and configuring vRA (6.x). But let’s get this out of the way — the ratio of level of effort vs. product capabilities make the time investment quite worth it at the end of the day (at least i think so!).  In the overview post (Part 1), I mentioned the massive focus on overall UX improvements in vRA 7. While the new deployment wizard absolutely changes the perception of complexity and takes all the work out of the admin’s hands, the reduced deployment footprint is equally important and will drastically reduce operational overhead and time to implementation. That is especially the case for distributed architectures that can grow upwards of 20+ machines. Let’s change that, shall we?…

vRA 6.x Deployment Architecture

In addition to several external dependancies, vRA 6.x requires various internal/embedded services to be taken externally for high availability. The services embedded in the virtual appliance include vRealize Orchestrator, the vPostgres DB, and the vRA framework services themselves. An external Identity Appliance (SSO) is required for authentication (vCenter SSO also an option). And, finally, the optional App Services VA for app authoring.

For distributed architectures, the components include at least 2 load-balanced vRA VA’s, an external pair of clustered vPostgres DB’s, external clustered vRO pair, a pair of [vCenter] SSO’s (the Identity Appliance does not support an HA configuration), and a single ill-fated App Services VA, which also does not support an HA setup.…