The virtual building blocks that make up VMware vRealize are comprised of at least one Windows machine as well...
as several virtual Linux appliances. In the past, several Windows machines were required, but VMware is driving even more functionality into pre-packaged Linux appliances, cutting down the complexity and time required for setup.
Before you get going, a number of items are required prior to deploying VMware vRealize. Ensuring that you have met all the requirements and that they work as expected will potentially save you much anguish and troubleshooting later.
First and foremost, Active Directory and a DNS infrastructure are required. The virtual machine and appliances should be able to execute forward and reverse lookup without issues. IP v4 should be working cleanly. It should go without saying that the Windows servers in your test lab should be on the same time zone and share an accurate time source.
Without an accurate time source and correct clocks, you will experience issues across the board. Even being off by as little as a minute can cause issues. Network Time Protocol (NTP) mistakes are one of the most prevalent error sources when working with VMware vRealize.
If your lab is using Windows Server 2012, you need to be aware of a known issue with regards to available cyphers in the default Windows installation. Essentially the SHA512 certificate isn't supported out of the box but this issue doesn't affect Windows 2008. However, if you don't fix this issue, you will find that vRealize will not work. As this is a test lab to minimize any issues, I recommend turning off the Windows firewall.
Lastly, when starting these machines up, bear in mind just how much is going on in the background. It can take 15 to 20 minutes for a service or server to be ready. Be patient.
The core building blocks
All the required infrastructure for our example test lab can fit in five virtual machines, but requirements need to be met.
IAAS server: This is the key server that provides many items, including the self-service portal and multi-tenancy aspects of the server.
Identity server: The identity appliance is akin to the one that VMware single sign-on (SSO) uses itself. The key difference is the fact that this identity and authentication server provides authentication services to tenants. Keeping the underlying vSphere SSO and identity server separate is highly recommended and is considered best practice. An administrator wouldn't want to potentially risk exposing the management vSphere authentication infrastructure to his tenants.
vRealize automation server: The vRA server contains a lot of the secret sauce that makes up the whole vRealize infrastructure. This runs many of the background services that vRealize requires.
SQL database server: The IAAS server requires a SQL server to store the databases that vRealize will use. The SQL server contains all the databases and information about diverse information such as tenants, blueprint configuration and users.
vRealize Orchestrator: Orchestrator is used to develop custom workflows and service offerings. A typical example is creating a workflow to allow business administrators to reset Active Directory passwords for users from the portal, thereby removing the need to get a systems administrator to reset them.
Implementing a basic lab deployment
The Identity Appliance, which is delivered in an open virtualization format, should be deployed as you would any normal deployment. Fill in the questions and then deploy the server. I recommend turning on Secure Shell (SSH) by checking the box entitled "Enable SSH service in the appliance".
One thing that is not obvious is that to fill in the network IP details, you need to expand the networking property. I wholeheartedly recommend using a static IP and a pre-configured DNS entry.
Once the appliance is powered up, log in to the appliance using the format https://fqdn:5480 and substituting "fqdn" with the fully qualified domain name. Log in as the root user (root) using the password you chose when the appliance was installed. At this point we can configure the appliance.
To configure this correctly, it is best to work in order from left to right. The first item to configure is time zone. Remember, it's important to select the appropriate time zone or you could run into an error down the road. Don't forget to apply the settings.
At this point I suggest using SSH and the Yet another Setup Tool (YaST) to set the time to refer to the time server on the local network. A tutorial on it can be found here. It's a separate application, but the same principles and process applies.
The next task is to configure the built-in SSO. When you first set up your vSphere 5.1 (or greater) environment, you may remember that you set up the VMware SSO server as part of that. To integrate the new identity appliance with the rest of the environment, we need to join it to the original SSO server.
Enter the SSO environment password and click the Apply button. If successful, the red alert text will change to read "SSO initialized" and turn green and the SSO status should change to "running," as seen in Figure 4. The actual initialization process may take several minutes.
Click on the "Host Settings" option inside the SSO tab. Ensure the SSO hostname is correct and apply the change if needed. The SSO hostname should be the fully qualified domain name. If you change it, you need to apply the configuration as shown in Figure 5.
The next step is to configure certificates. As this is a small test lab environment, we will be using a self-signed certificate and most of the settings will be greyed out. To fill in the details, select "Generate Self Signed Certificate" from the Choose Action drop-down list. Fill in the rest of the details and click "Apply Settings" to generate a certificate.
The very last tab option in SSO allows Active Directory users to be authenticated. The settings to use should be obvious. In a production environment, the use of a service account is strongly advised and simplifies troubleshooting when needed. I used the domain administrator account for this.
Lastly, select the Network tab and make sure all the network details are correct. Most of the settings will have been previously completed when the Identity Appliance was deployed.
Deploying the vRealize appliance
The core vRealize machine is also an appliance. To deploy the appliance, repeat the process performed by the Identity Appliance -- all the initial settings will be the same. Don't forget to set the DNS name before the server is deployed; it just makes life easier. Again, I recommend enabling SSH service because it is good to use the same NTP server and configuration as we did before with the Identity Appliance.
Fill in the hostname, using the machine FQDN. The network settings are shown in Figure 7. Click the little arrow and it allows you to fill in the network IP details. See Figure 7 for my system prior to deployment.
Once you have set up and deployed the vRA and powered it on, it will need configuring. Like the other appliances, log in using https://fqdn:5480 and configure the time zone as we did previously.
In the vRA Settings tab, under the Host Settings option, you will need to configure some items. First, select "Keep Existing" host configuration. Directly below is the SSL configuration. Fill in the common name, organization and organizational unit and ensure that "Generate Certificate" is selected.
On the SSO tab, fill in the SSO host field as well as the admin username and password and click the Apply button to complete. If everything works, the red error message turns green and you will get a new entry that gives miscellaneous SSO info as well as the status.
When this is done, move onto the Licensing tab and enter your vRealize license information. Again, apply the license and you should get a message saying that the license key was updated successfully. At this point we are done with the VMware vRealize appliance. The database and clustering tabs are only used when setting up resilient infrastructure. By default vRA has its own database included in the installation.