The infrastructure as a service (IaaS) server is the only service that -- as of this writing -- still has to be...
placed on a Windows server. Deploying the IaaS server using VMware vCloud Automation Center (vCAC) can be a frustrating exercise if not done correctly. This tip walks you through an IaaS deployment while using Windows 2012 R2.
As noted in part two of this series, the administrator absolutely must ensure that the Windows server's clock is in sync with the rest of the servers and Active Directory infrastructure. Prior to running any IaaS-related setup, make sure that the Windows server is connected to Active Directory, and that forward and reverse domain name systems work flawlessly.
Inside the IaaS server, there are a number of components that make vRealize work the way it does. The IaaS server is the biggest part of the vRealize infrastructure.
The communication and provisioning of virtual machines (VMs) is enacted by two components: the Distributed Execution Manager (DEM) and agents.
The role of the DEM
The DEM's job is to communicate between the vRealize environment and the cloud environment. You can use the DEM to talk to platforms, such as Amazon Web Services and vCloud Hybrid Service -- VMware's own cloud platform.
DEMs are also used to aid deployment of physical machines. It integrates with HP, Cisco and IBM out-of-band management. Although this function is available, I have never seen it used, as using DEMs for physical distribution is niche at best.
Within the DEM, there are two management components that provide different roles within the vRealize infrastructure. These management infrastructure components are DEM Orchestrator and DEM Worker.
DEM Orchestrator monitors, controls and assigns jobs to the DEM workers. It also manages requests from workflows, among other things, to perform a certain task. To ensure consistency and to avoid any confusion, there should only be one DEM Orchestrator working at a time. You can, however, implement backup orchestrators and switch them over manually, if needed.
The job of the DEM Worker is to deal with external systems and run the workflows. In effect, a worker functions as a go-between.
The agents are used to collect data and deploy the VMs in the associated cloud or hypervisor deployment. The included agent can talk to vSphere, Red Hat Enterprise Virtualization, Hyper-V and several other Type 1 hypervisors.
Installing the IaaS server
The prerequisite list for IaaS installation using vCAC is not only extensive, but would take ages to complete if done manually. Thankfully, someone clever at VMware created a preinstallation script to install all the requirements automatically.
Once the Windows server is configured and joined to the domain, save that script on the desktop of the IaaS server with a .ps1 extension. Once saved, open the PowerShell application and run the script -- opening a PowerShell window and dragging the script into it also works. This script will install all the dependencies needed to install IaaS. As the script runs, it may ask several questions throughout the installation. Just select the appropriate response from the list.
Part way through the installation, it will ask you about the domain admin account for the installation. For our purposes, we can just use the domain administrator account. In a real production scenario, this would be frowned upon. But this is just a test setup, with no sensitive data.
Once these prerequisites are completed, use a Web browser to open the vRealize appliance, using https://vra_fqdn:5480 (Note: not the IaaS server). Navigate to the vRealize Automation settings menu and locate the IaaS install tab at the end. All you need to do is download the IaaS installer -- the first link -- and copy it to the IaaS server. As the webpage notes, don't rename the file.
Once uploaded to our IaaS server, run the application as the administrator.
On the first screen, accept the terms in the license agreement and click next. You will be presented with a screen inviting you to view the details of the vRealize server we created earlier. Be sure to tick the box about accepting certificates.
On the next screen, you select the installation type. If it was a production environment, there would be the option to customize the installation -- i.e., split out the various components to separate servers -- but we don't need to concern ourselves with the more advanced features at the moment, so just go for the complete installation.
The next screen checks the prerequisites that we installed earlier. These should have been installed, but if you really want to double check, click the check again feature. Otherwise, just click next.
On the next screen, we configure the server accounts and the database connectivity. Installing a Microsoft SQL server is beyond the scope of this series of articles. Once you have a setup database server, follow the installation as detailed below.
On this screen, I used the domain administrator credentials. The passphrase can be anything you desire -- just make sure it is relatively complex.
The database server should be filled in with FQDN, and the username and password. Unless you have a compelling reason to do so, leave the database name as the default. I had to change mine shown in the screenshot for other reasons.
The next screen allows you to configure the DEM and vSphere agents. Because our lab is so simple, we can just go with the defaults.
On the screen shown in Figure 6, just click load and it will load our default tenant because we only have one. Next, click download on certificate and place a tick in the "Accept Certificate" box.
Fill in the SSO credentials, as we did before with the original secondary SSO server. Use the test button to ensure it works. On the IaaS box, use text to ensure it resolves correctly. If all is good, it should go green and change to "passed."
On the following page, it confirms the details. Hit "Finish" to start the installation. Please note that the installation will take a while. At this point, you can go and make a well-deserved cup of coffee.