Deploying fully distributed vRealize Automation IaaS components – Part 1: Pre-requisites
Sam McGeown- Deploying fully distributed vRealize Automation instance – Configuring NetScaler Monitors
- Deploying fully distributed vRealize Automation IaaS components – Part 2: Database, Web and Manager services
- Deploying fully distributed vRealize Automation IaaS components – Part 1: Pre-requisites
- Deploying vRealize Automation 6.2 Appliance Cluster with Postgres Replication
- vSphere 6 HA SSO (PSC) with NetScaler VPX Load Balancer for vRealize Automation
- vCAC 6.0/6.1 build out to distributed model: Deploy the Identity Appliance
One of the trickiest parts of deploying vRealize Automation is the IaaS layer - people sometimes look at me like I’m a crazy person when I say that, normally because they’ve deployed a PoC or small deployment with just a single IaaS server. Add in 5 more servers, some load balancers, certificates, a distributed setup and MSDTC to the mix and you have a huge potential for pain!
If you’ve followed my previous posts, you’ll see know that I’ve got a HA Platform Services Controller configured, and a HA vRealize Appliance cluster configured with Postgres replication - all good so far.
There are loads of ways to deploy the IaaS layer and they depend on the requirements and the whim of the architect who’s designed it - but the setup I deploy most often is below
Active/Active IaaS Web components on two servers and load balanced- Active/Passive IaaS Manager components on two more servers and load balanced, with a DEM Orchestrator also running on each host
- Two more servers running the DEM Worker and Agents - typically vSphere Agents.
Keeping the web components separate ensures your users’ experience is snappy and isn’t degraded during deployments. The manager service is load balanced, but has an active and a passive side which needs to be manually started in the event of a failover. The DEM Orchestrator roles orchestrate the tasks given to the DEM Workers and don’t put much load on the servers. Finally, the DEM Workers and Agents are placed on two more servers - the DEM Orchestrators load balance the workloads sent to each DEM Worker and in the case of a failed DEM Worker will resume the workload on the other Worker. The vSphere agents are configured identically and provide high availability for the service, workloads will just use whichever agent is available for a particular resource.
I have already deployed and configured a Microsoft SQL Server 2008 R2 Failover Cluster, with a local MSDTC configured on each node. I hope to publish a blog post on this in the near future - for this article it’s not important, just that there’s a MSSQL database available and MSDTC is configured on the database server.
Pre-requisites
The pre-requisites here are for ALL the IaaS components.
Create DNS records
Create an A and PTR DNS record for the two load balanced URLS
Deploy six Windows Servers
I’m using Windows Server 2012 R2, deployed from my basic template and joined to the domain. Each is assigned a static IP address and because they’re domain joined their DNS records are updated.
- VRA-WEB-01
- VRA-WEB-02
- VRA-MAN-01
- VRA-MAN-02
- VRA-IAS-01
- VRA-IAS-02
Configure BackConnectionHostNames or set DisableLoopbackCheck
This step is required on the servers hosting the Web component of IaaS.
There’s a known issue with accessing websites hosted by IIS using NTLM authentication via a different name than the server’s DNS hostname, which results in a “HTTP 401.1 - Unauthorized: Logon Failed” error. This is one of the most common reasons the IaaS installation fails, and can be solved by setting BackConnectionHostNames, or DisableLoopbackCheck, which is the least secure option as it completely disables the protection. Using BackConnectionHostNames is a much better option as it selectively disables the protection.
There are two steps to this - set “DisableStrictNameChecking” to “1”, then add a multi-string value BackConnectionHostNames with the load balancer URL as the value.
I have written this PowerShell script to configure the BackConnectionHostNames, just edit the $loadbalancerUrl value to match your FQDN:
$loadbalancerUrl = “vra-web.definit.local”
if((Get-ItemProperty “HKLM:\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters”).DisableStrictNameChecking -ne 1) {
New-ItemProperty “HKLM:\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters” -Name “DisableStrictNameChecking” -Value 1 -PropertyType “DWORD”
}
$existingHosts = (Get-ItemProperty “HKLM:\SYSTEM\CurrentControlSet\Control\LSA\MSV1_0”).BackConnectionHostNames
if($existingHosts -eq $null) {
New-ItemProperty “HKLM:\SYSTEM\CurrentControlSet\Control\LSA\MSV1_0” -Name “BackConnectionHostNames” -Value $loadbalancerUrl -PropertyType “Multistring”
} else {
$existingHosts += $loadbalancerUrl;
Set-ItemProperty “HKLM:\SYSTEM\CurrentControlSet\Control\LSA\MSV1_0” -Name “BackConnectionHostNames” -Value $existingHosts
}
Note: It’s important to reboot the web server after this step to ensure the settings are in effect.
Create a service account
vRealize Automation IaaS requires a service account is created to run the services and provide access to the database. Create an account and add it to each of the 6 Windows Servers as a local administrator.
My service account is [email protected].
Create a build folder
For simplicity’s sake I tend to build a folder on the first Web server (typically c:\vRA) and gather all the components required.
- Download the awesome vRA Pre-req Automation Script written by Brian Graf and save in the build folder.
- Obtain a copy of ntrights.exe from the Windows Server 2003 Resource Kit Tools and save it in the build folder.
- Download the IaaS installer from the first vRealize Automation Appliance (https://vra-app-1.definit.local:5480/i/) and save it in the build folder.
Generate Certificates for IaaS Components
To try and keep this blog post to a reasonable size, I won’t go through the process of requesting certificates. I have generated two certificates using the vSphere certificate template as detailed below:
| Subject Name |
| vra-iaas-web.definit.local |
| vra-iaas-man.definit.local |
Each of the web and manager servers should have the relevant certificate (including the private key) installed in the Computer > Personal certificate store, and should be visible in IIS manager when it’s installed. It’s also worth ensuring a “Friendly Name” is set in the certificate store - this makes it easier to find in the installation process.
Run the prerequisite script
At this point I run Brian Graf’s excellent vRealize Automation prerequisite script on the IaaS Web and Manager servers. The requirements for the DEM and Agents are different (e.g. no IIS installed) so I’ll cover them at a later point.
Make sure you reboot the Web/Manager servers after running the script.
Configure NetScaler Load Balancer for IaaS Web
The IaaS web load balancer is a relatively simple affair, load balancing the two active web services on HTTPS/443. The health check should look for the presence of “REGISTERED” on the URL /WAPI/api/status - however the initial check should be set to a basic HTTPS/443 connection during the installation phase.
Create the Servers
Create the Services
Create a VIP
Ensure the persistence is set to “SOURCEIP” with a timeout of 2 minutes.
Configure NetScaler Load Balancer for IaaS Manager
The load balancer requirements for the Manager service are pretty simple, it’s basically an active/passive service and should be configured to point to both and test the /VMPS2 address for a “ProxyAgentService” response - however the initial check should be set to a basic HTTPS/443 connection during the installation phase and the secondary passive server should be disabled to ensure it doesn’t come up during the install process.
Create the Servers (be sure to disable the passive one!)
Create the Services
Create a Virtual Server
Since it’s active/passive, no persistence is required.