This design places the vRealize Automation application and its supporting services in Region A. The same instance of the application manages workloads in both Region A and Region B.
Table 1. Design Decisions on the vRealize Automation Topology

Decision ID

Design Decision

Design Justification

Design Implication

SDDC-CMP-001

Deploy a single vRealize Automation installation to manage both Region A and Region B deployments from a single instance.

vRealize Automation can manage one or more regions and provides a single consumption portal regardless of region.

Because of the isolation of the vRealize Automation application over virtual networking, it is independent from any physical site locations or hardware.

You must size vRealize Automation to accommodate multi-region deployments.

SDDC-CMP-002

Deploy a large-scale configuration of vRealize Automation.

Deploying the three-node architecture satisfies the design objective of 10,000 virtual machines being provisioned and managed in the scope of the initial deployment architecture.

This design enables future growth of up to 50,000 virtual machines after you expand the underlying virtual and physical infrastructure.

vRealize Automation components use more resources than the design objectives define.

Table 2. Design Decisions on Anti-Affinity Rules for vRealize Automation

Decision ID

Design Decision

Design Justification

Design Implication

SDDC-CMP-003

Apply vSphere Distributed Resource Scheduler (DRS) anti-affinity rules to all vRealize Automation components.

Using vSphere DRS prevents vRealize Automation nodes from residing on the same ESXi host and risking the high availability of the cluster.

  • You must perform additional configuration to set up an anti-affinity rule.

  • You can put in maintenance mode only a single ESXi host at a time in a management cluster of four ESXi hosts.