This post will be part of a series detailing the steps required to deploy a vRealize Automation 7 large deployment implementation from the reference architecture. I would recommend reading the reference architecture before commencing with any vRA 7 install.
The vRealize Automation Reference Architecture document can be found here:
vRealize Automation 7 Reference Architecture
vRealize Automation Overview
Just in case you are not aware of VMware’s Automation product, here’s a brief introduction – VMware vRealize Automation provides a secure portal where authorised administrators, developers, or business users can request new IT services. In addition, they can manage specific cloud and IT resources that enable IT organisations to deliver services that can be configured to their lines of business in a self- service catalog.
vRealize Automation provides a secure portal where authorised administrators, developers or business users can request new IT services and manage specific cloud and IT resources, while ensuring compliance with business policies. Requests for IT service, including infrastructure, applications, desktops, and many others, are processed through a common service catalog to provide a consistent user experience.
You can improve cost control by using vRealize Automation to monitor resource and capacity usage. For further cost control management, you can integrate vRealize Business Advanced or Enterprise Edition with your vRealize Automation instance to expose the cost of cloud and virtual machine resources, and help you better manage capacity, cost, and efficiency.
The vRealize Automation documentation can be found at the VMware vRealize Automation Information Center:
VMware vRealize Automation Information Center
New Features in vRealize Automation 7 since 6.2 release
vRealize Automation 7 includes several architectural changes that simplify configuration and deployment. The deployment wizard is a major improvement over the vRA 6.x release providing a more reliable and robust deployment method. The previous release was very sensitive, especially with the IaaS components.
Architectural Changes
- The appliance database is now clustered automatically within the appliance. There is no longer any need for an external database load balancer or DNS entry.
- The instance of vRealize Orchestrator is now clustered automatically within the vRA appliance.
- Authentication is now handled by an embedded instance of VMware Identity Manager, known as Directories Management, within vRealize Automation.
- vRealize Application Services functionality has been merged into vRealize Automation.
Deployment Changes
- vRealize Automation deployments require two less load balanced endpoints as there is no need to balance the appliance database and an external SSO provider.
- Four virtual machines can potentially be removed from the footprint for most deployments, though an external vRealize Orchestrator instance is still recommended for some situations.
- A new deployment wizard which offers two types of installs, simple and enterprise. Simple is for installing vRA in a monolithic (non-distributed) fashion, enterprise assumes a fully distributed install
Deployment Recommendations
- Keep the vRealize Automation, vRealize Business and vRealize Orchestrator appliances in the same time zone with their clocks synchronised. Otherwise, data synchronisation might be delayed.
- Install vRealize Automation, vRealize Business Standard Edition, and vRealize Orchestrator on the same management cluster. Provision machines to a cluster that is separate from the management cluster so that user workload and server workload can be isolated.
- Deploy Proxy Agents in the same data center as the Endpoint with which they communicate. VMware does not recommended placing DEM Workers in Remote Data Centers unless there is an express workflow skill based use case that requires it. All components except the Proxy Agents and DEM Workers must be deployed in the same Data Center or Data Centers within a Metro Area Network. Latency must be less than 5 milliseconds, and bandwidth must not be less than 1 GB/s between the Data Centers in the Metro Area Network.
- For more information including a support statement, see the VMware Knowledge Base article Installing VMware vRealize Automation on a distributed multi-site instance
Support
A large deployment can support the following items:
- 50,000 managed machines
- 2500 catalog items
- 100 concurrent machine provisions
Components
An installation consists of the following components:
- vRealize Automation appliance, which deploys the management console, manages Single Sign-On (SSO) capabilities for authorization and authentication, and includes an instance of vRealize Orchestrator.
- Infrastructure as a Service (IaaS) components, which are installed on a Windows machine (virtual or physical), and appear largely under the Infrastructure tab on the console.
- An MS SQL Server Database, which is deployed during the IaaS installation.
Requirements
A large enterprise HA deployment requires the following systems:
Virtual Appliances
- vRealize Automation Appliance x 2
- vRealize Orchestrator Appliance x 2 (or use the embedded vRO instances on the vRealize Automation Appliances)
Windows Server Virtual Machines
- Infrastructure Web Server x 2
- Infrastructure Manager Server x 2
- Infrastructure DEM Server x 2
- Infrastructure Agent Server x 2
- Cluster Microsoft SQL Database
Load Balancer
- vRealize Automation Appliance nodes
- Infrastructure Web Server nodes
- Infrastructure Manager Server nodes
- vRealize Orchestrator Appliance (optional if using external vRO Appliances)
The following illustration outlines the vRA architecture for an enterprise deployment
The following table outlines the hardware specifications for the vRA components using the large deployment model in the reference architecture:
| Server Role | Components | Required Hardware Specifications | Recommended Hardware Specifications |
| vRealize Automation Appliance | vRealize Automation Services,
vRealize Orchestrator, vRealize Automation Appliance Database |
CPU: 4 vCPU
RAM: 18 GB (this may need to be increased for Directories Management sync) Disk: 108 GB Network: 1 GB/s |
Same as required hardware specifications. |
| Infrastructure Web Server | Web site | CPU: 2 vCPU
RAM: 2 GB Disk: 40 GB Network: 1 GB/s |
CPU: 2 vCPU
RAM: 4 GB Disk: 40 GB Network: 1 GB/s |
| Infrastructure Manager Server | Manager Service, DEM Orchestrator | CPU: 2 vCPU
RAM: 2 GB Disk: 40 GB Network: 1 GB/s |
CPU: 2 vCPU
RAM: 4 GB Disk: 40 GB Network: 1 GB/s |
| Infrastructure DEM Server | (One or more) DEM Workers | CPU: 2 vCPU
RAM: 2 GB Disk: 40 GB Network: 1 GB/s (Per DEM Worker) |
CPU: 2 vCPU
RAM: 6 GB Disk: 40 GB Network: 1 GB/s (Per DEM Worker) |
| Infrastructure Agent Server | (One or more) Proxy Agent | CPU: 2 vCPU
RAM: 4 GB Disk: 40 GB Network: 1 GB/s |
Same as required hardware specifications |
| MSSQL Database Server | Infrastructure Database | CPU: 2 vCPU
RAM: 8 GB Disk: 40 GB Network: 1 GB/s |
CPU: 8 vCPU
RAM: 16 GB Disk: 80 GB Network: 1 GB/s |
Note: Typically disk sizes for vRA components host on Windows Servers are driven by customer standard build specifications. These need to be considered with the above table.
DNS and Host Name Resolution
- All vRA components must be able to resolve each other by using a fully qualified domain name (FQDN).
- The Model Manager Web service, Manager Service and Microsoft SQL Server database must also be able to resolve each other by their Windows Internet Name Service (WINS) name.
Note: vRA does not allow the use of an underscore (_) in host names.
Password Considerations
The vRealize Automation administrator password that you define during installation must not contain special characters.
In vRA 7.0.1, the following special characters are known to cause errors:
- Double quote marks (“)
- Commas (,)
- A trailing equal sign (=)
- Blank spaces
- Non-ASCII or extended ASCII characters
Note: Passwords that contain special characters might be accepted when you enter them, but cause failures when you perform operations later.
Time Synchronisation
All systems must synchronise their clocks from an accurate time source. Installation will fail if system clocks are not synchronised.
Installation Accounts
The following table outlines the accounts required for a distributed installation, I used separate accounts for the IaaS components but you can consolidate the account requirements if your setup allows this:
| Component | Account | Access |
| vRealize Automation Appliance
(VMware Identity Manager) |
root | |
| Default Tenant | administrator@vsphere.local | |
| Website and Model Manager | testlab\svc_vra_iaas01 | Access to IaaS SQL DB
Local Administrator on IaaS Web Servers |
| Manager Service and DEM Orchestrator | testlab\svc_vra_mgr01 | Access to IaaS SQL DB
Local Administrator on IaaS Manager Web Servers |
| DEM Worker | testlab\svc_vra_pxy01 | Local Administrator on IaaS DEM-W/Agent Servers |
| Proxy Agent | testlab\svc_vra_pxy01 | Local Administrator on IaaS DEM-W/Agent Servers |
| vRA to vCenter | testlab\svc_vra_vc01 | |
| vRA to AD | testlab\svc_vra_ad01 | |
| vRO to AD | testlab\svc_vro_ad01 | |
| vRA to vRO | testlab\svc_vra_vro01 |
Load Balancer
The following table outlines the load balanced components required for a distributed installation:
| Component | Load Balancer | Server FQDN and IP Address |
| vRealize Automation Appliance | vra-portal.testlab.com <192.168.140.24> | vratestlab01.testlab.com <192.168.140.10>
vratestlab02.testlab.com <192.168.140.11> |
| Website and Model Manager Data | vra-web.testlab.com <192.168.140.25> | vratestlab03.testlab.com <192.168.140.13>
vratestlab04.testlab.com <192.168.140.14> |
| Manager Service
DEM Orchestrator |
vra-mgr.testlab.com <192.168.140.26> | vratestlab05.testlab.com <192.168.140.15>
vratestlab06.testlab.com <192.168.140.16> |
| DEM Workers and Agents | N/A | vratestlab07.testlab.com <192.168.140.17>
vratestlab08.testlab.com <192.168.140.18> |
I will continue with the vRA 7 deployment in part 2 of this series.
