vRealize Automation

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 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:

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.

Load Balancer

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: