Getting started with VCF Part 4 – vRA Deployment

After taking care of all of the prerequisite steps highlighted in my VMware Cloud Foundation Part 3 post, we are now ready to deploy vRealize Automation (vRA) via vRealize Suite Lifecycle Manager (vRSLM) in the VCF SDDC Manager. This will be a relatively shorter “show and tell” post, which will take you through the deployment steps. It will also show you how you can monitor the progress of the vRA deployment. The complete deployment does take some time since there are quite a number of virtual appliances and virtual machines that need to be rolled out for vRA (11 in total), as well as the creation of a number of virtual ip addresses (load balancers) in NSX for the different highly available parts of vRA.

1. Launch vRealize Automation deployment from vRSLM

To begin, log into the VCF SDDC Manager, navigate to vRealize Suite, and click on vRealize Automation. If vRealize Suite Lifecycle Manager has not yet been configured in your environment, details on how to do it can be found in my VCF Part 2 post here.

2. Click Deploy

You will be told vRA is currently not deployed. Click the “Deploy” button to proceed.

3. Review the prerequisites

You are now show a list of all the prerequisite steps that we went through to get everything in place for the vRealize Automation deployment in step 3. If you haven’t yet done the prerequisites, you’ll need to go back and take care of these before proceeding with the vRA deployment.

4. Start populating the deployment details

At this point, we need to add a vRA License Key, and provide the certificate chain for the list of vRA virtual machines, the private key, and a Passphrase. The chain (server.pem) and private key (private_key.pem) were built during part 3, the vRA prerequisites and are stored on your SDDC Manager appliance in /tmp by default.

In this step, you will also need to provide the Windows OVA template that will be used for the IaaS components, such as the IaaS web server, IaaS managers, DEM orchestrators and DEM workers. Note that the OVA template is placed in the directory /nfs/vmware/vcf/nfs-mount/vra/repo on the SDDC Manager, so if you have uploaded it once, you can simply point to this location for any future deployment attempt.

5. Populate the FDQNs

The next page of the deployment wizard requires you to add the fully qualified domain name (FQDN) for each of the vRA components (appliance and virtual machines). Some of these fields will already be populated, such as the FQDN for the vRealize Suite Lifecycle Manager and NSX Edge Service Gateway, which were added in part 2 when we deployed the vRSLM and vRealize Operations. Although not shown below, you need to supply the various load balancer virtual IP addresses, as well as the FDQN for the SQL Server node at this step.

6. Populate the requested account information

We now move onto the step where account information for various parts of the deployment is supplied. Much of this information was setup during part 3. Here we provide the vRA service account user , the name of SQL Server database and user (optional) as well as the Local Tenant Admin for vRA. Also required at this juncture are the passwords for the Windows Template Local Administrator, the default vRA Tenant Administrator and the vRA SSH root account (though these are not shown in the screenshot below).

7. Review Summary and Finish

A last chance to look over your previous inputs before commencing the vRA deployment. If all looks good, click Finish.

At this point, a certain amount of validation is done against the inputted values. If you fat-fingered any of the inputs, or if there are issues with doing a DNS lookup for any of the FQDNs, this is reported. Here is an example of such a failure. You can go back in the wizard to correct these, then advance to the summary page and click ‘Finish’ once again.

8. Monitoring vRealize Automation deployment via vRSLM

By monitoring the Recent Tasks in the VCF Management Domain, we can observe the various vRA components being deployed from the OVF template that we uploaded as part of the deployment. Whilst vRA is deploying, we do have the ability to monitor the status by logging into the vRealize Suite Lifecycle Manager (vRSLM). On initial login to my vRSLM using admin@localhost, I can see that I have already deployed vRealize Log Insight (which was done in part 1 of this series during initial bringup) and vRealize Operations (which was done in part 2 of this series with the initial vRSLM deployment). Note that it now currently states that vRA_environment is “IN PROGRESS”.

By clicking on the three vertical dots to the right of the request, we can “View Request Details” as shown below. This will give us additional information about how much progress has currently been made:

In the first screenshot, we can see the three virtual appliances that make up vRealize Automation are currently being deployed. We have not yet moved onto the IaaS virtual machines.

In this next screenshot, progress have moved significantly further along. Here we can see that the vRA appliances have been deployed, and that all of the IaaS virtual machines have also been deployed. We are now at step 3, where the first of the Windows virtual machines is having the vRA IaaS management agent pushed out to it, so that it can then be configured as a web server for the IaaS component of vRA:

If all goes well, and the Windows OVA template is configured correctly, and all of the other pre-requisites have been put in place correctly, then the deployment should complete without error.

For a more detailed view of the deployment progress, SSH to the SDDC Manager appliance. You can then tail the log file: /var/log/vmware/vcf/domainmanager/domainmanager.log

Be aware that this log file does receive a lot of detailed log information, much of which will not be very useful. However, it does give good insight into the various tasks involved in the requests shown in the vRSLM UI above.

9. Validating vRealize Automation deployment

At this point, all 3 vRA virtual appliances should be deployed, all 8 Windows virtual machines used for vRA IaaS should be deployed, and the 3 virtual IP address/Load Balancers should be configured in NSX. As a reminder, we required a Load Balancer for the IaaS web servers, vRA appliances and IaaS management servers. Here is a view of the NSX Edge, and the Load Balancers:

We should also observe, after a few further moments, that the vRA_environment in vRSLM should no longer show “IN PROGRESS”. You can now use vRSLM to look at the vRA Environment in detail.

And when we looking the vRSLM section of the SDDC Manager, vRA should show as Active.

vRA has now been successfully deployed. As shown above, it can now be connected to a workload domain, and used for deploying applications and solutions to that workload domain. Workload domains are the next topic on our VMware Cloud Foundation agenda.

Previous posts on VMware Cloud Foundation can be found here.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.