DefinIT

Deploying fully distributed vRealize Automation IaaS components – Part 2: Database, Web and Manager services

vRANow that the prerequisites for the IaaS layer have been completed, it’s time to move on to the actual installation of the IaaS components, starting with the database. We then move onto the first Web server, which also imports the ModelManagerData configuration to the database, populating the database with all of the info the IaaS layer needs out of the box. We then install the second Web server before moving on to the active Manager server. The second Manager server is passive and the service should be disabled – I’ll cover installing DEM Orchestrators, Workers and the vSphere Agents in the next article. (more…)

Deploying fully distributed vRealize Automation IaaS components – Part 1: Pre-requisites

vRAOne 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

  • imageActive/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. (more…)

HTTP Error 500 installing vCAC IaaS Model Manager Data

| 10/07/2014 | Tags: , , , ,

This was a fun little error, whilst installing the distributed IaaS roles I couldn’t seem to get the IaaS components to install – when I got the Website and Model Manager Data install it would fail with the following message:

##InitializeRepo Registering solution user in the VA, initializing Repository MetaModel and Authorization 
"C:\Program Files (x86)\VMware\vCAC\Server\Model Manager Data\Cafe\Vcac-Config.exe" RegisterSolutionUser -url https://vcloud.definit.local --Tenant "vsphere.local" -cu "administrator@vsphere.local" -cp ******  --FileName "C:\Program Files (x86)\VMware\vCAC\Server\Model Manager Data\Cafe\Vcac-Config.data" -v 
    VMware.Cafe.HtmlResponseException: Internal Server Error (500) 
    at VMware.Cafe.JsonRestClient.<HandleErrorResponse>d__8d`1.MoveNext() 
  --- End of stack trace from previous location where exception was thrown --- 
     at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task) 
     at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task) 
     at VMware.Cafe.JsonRestClient.<CreateResource>d__2d`1.MoveNext() 
  --- End of stack trace from previous location where exception was thrown --- 
     at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task) 
     at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task) 
     at VMware.Cafe.ComponentRegistryClient.<CreateSolutionUserAsync>d__5.MoveNext() 
  Http response: 
  StatusCode: 500, ReasonPhrase: 'Internal Server Error', Version: 1.1, Content: System.Net.Http.StreamContent, Headers: 
  { 
    Vary: Accept-Encoding 
    Vary: User-Agent 
    Connection: close 
    Date: Thu, 10 Jul 2014 23:20:43 GMT 
    Content-Length: 3784 
    Content-Type: text/html; charset=utf-8 
  } 
  Warning: Non-zero return code. Command failed. 
C:\Program Files (x86)\VMware\vCAC\Server\Model Manager Data\DeployRepository.xml(556,5): error MSB3073: The command ""C:\Program Files (x86)\VMware\vCAC\Server\Model Manager Data\Cafe\Vcac-Config.exe" RegisterSolutionUser -url https://vcloud.definit.local --Tenant "vsphere.local" -cu "administrator@vsphere.local" -cp ******  --FileName "C:\Program Files (x86)\VMware\vCAC\Server\Model Manager Data\Cafe\Vcac-Config.data" -v" exited with code 1. 
Done Building Project "C:\Program Files (x86)\VMware\vCAC\Server\Model Manager Data\DeployRepository.xml" (InitializeRepo target(s)) -- FAILED. 
Build FAILED.

image

I’ve pasted it in here because I couldn’t find anything through google that referred to my error messages – hopefully if you’re reading this you’ve found it because you’re looking for it!

I tried all sorts of things before noticing the HTTP header – specifically the Date – which showed an incorrect time. I jumped on the VCAC appliances via SSH and checked the time using “date”. One of my appliances was indeed out of skew – somehow the NTP service had been stopped after I configured it previously.

I edited the ntp.conf (vi /etc/ntp.conf) and checked I had entries in there – e.g. “server 0.uk.pool.ntp.org” and then started the NTP daemon using “rcntp start”, then sync’d using “rcntp ntptimeset”

The moral of the story – check time sync on ALL vCAC components – it’s important!