vRealize Automation 7 – Part 2, Deployment Architectures

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. That’s a minimum of 8-9 VA’s just to support core services in an HA configuration. More importantly, that’s 8-9 VAMI UI’s that need to be logged into, integrated, configured for clustering, etc. In some cases (e.g. PostgresDB) the HA configuration itself can be unnecessarily complex, not to mention the added risk introduced by the IDVA and App Services for their single point of failure. This also means 3-4 Load Balancer VIP’s and several SSL certs to manage.

While the new deployment wizard would take a lot of these painstaking steps out of the equation — even if all these externals stuck around — VMware was also quite obsessed with reducing the overall footprint and post-deployment management complexities. So that’s exactly what they did.

vRA 7 Deployment Architecture

In contrast, vRA 7’s deployment architecture brings that all down to a single pair of VA’s for all the core services mentioned above, and then some. Once deployed, just 2 load-balanced VA’s will deliver vRA’s framework services, Identity Manager (SSO/vIDM), vPostgres DB, vRO, and RabbitMQ — all clustered and nested behind a single load balance VIP and a single SSL cert. All done automatically thanks to the deployment wizard. All that goodness, now down to 2 VA’s. The impact is significant for any enterprise.

For POC’s or small environments where HA is not important, the entire solution, including all the external IaaS components, can be delivered in a pair of machines — the vRA VA and a single Windows IaaS machine…

For distributed architecture, vRA’s core services — Platform Services, vIDM, vRO, vPostgres, and RabbitMQ — are deployed in a single HA pair behind 1 VIP.  There are many options for how to deploy the IaaS components (totally handled by the deployment wizard) for optimal scale and availability.  Following the existing reference architecture results in 8 windows machines and 2 additional VIP’s…

Consolidating the services and taking all the guess work out of getting there makes vRA significantly more…potent.  vRA 7 delivers several significant innovations focused on driving management efficiencies and taking many of the complexities out of hybrid cloud management.  But all of that could be lost with a “meh” user experience.  The new deployment architecture is a huge step forward in ensure that’s not the case.

+++++
virtualjad