Sam has been working in the IT industry for nearly 20 years now, and is currently working for VMware as a Senior Technical Marketing Manger in the Cloud Management Business Unit (CMBU) focussed on Automation. Previously, he has worked as consultant for VMware PSO, specializing in cloud automation and network virtualization. His technical experience includes design, development and implementation of cloud solutions, network function virtualisation and the software defined datacentre. Sam specialises in automation of network virtualisation for cloud infrastructure, enabling public cloud solutions for service providers and private or hybrid cloud solutions for the enterprise.
Sam holds multiple high level industry certifications, including the VMware Certified Design Expert (VCDX) for Cloud Management and Automation. He is also a proud member of the vExpert community, holding the vExpert accolade from 2013-present, as well as being selected for the vExpert NSX, vExpert VSAN and vExpert Cloud sub-programs.
Enter a name for the monitor, and leave the other parameters the same. Select the “Special Parameters” tab and configure the send string to the URL to monitor - e.g for the PSC SSO it’s going to be:
For the receive string, enter the expected response (“GREEN”). Click Create.
Assigning a NetScaler Monitor to a Service
Assign the monitor to the PSC Services (or Service Groups) configured for PSC by opening the Configuration > Traffic Management > Load Balancing > Services page and selecting the PSC service for HTTPS/443 and clicking Edit.
Now 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.
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!
Having just completed a particularly problem-prone distributed IaaS install, this was almost the straw that broke the camel’s back. Logging into vRealize Automation for the first time as an Infrastructure Admin displayed the infrastructure tab and all menu labels as big ugly references, and no functionality:
Rebooting the IaaS web servers restored the functionality of the IaaS layer but still did not fix the label issue, it took a further reboot of both vRealize Automation appliances, then the IaaS web servers to finally view the correct labels.
Note: This falls under the “I don’t think this is supported” category – use this method at your own peril!
As part of some testing I’ve been doing for vRealize Automation DR scenarios, I wanted to test changing the IP address of a HA PSC pair using a script (think SRM failover to a new subnet).
I’m not sure how supported this is, but this process can recover a vSphere 6 vCenter Server Appliance or Platform Services Controller when you’ve lost the root password.
The recommendations for the vRealize Appliance have changed with 6.2, the published reference architecture now does not recommend using an external Postgres database (either vPostgres appliance, a 3rd party Postgres deployment or using a third vRealize Appliance as a stand-alone database installation). Instead the recommended layout is shown in the diagram below. One instance of postgres on the primary node becomes an active instance, replicating to the second node which is passive. In front of these a load balancer or DNS entry points to the active node only. Fail-over is still a manual task, but it does provide better protection than a single instance.
Providing a highly available single sign on for vRealize Automation is a fundamental part of ensuring the availability of the platform. Traditionally, (vCAC) vRA uses the Identity Appliance and relies on vSphere HA to provide the availability of the SSO platform, but in a fully distributed HA environment that’s not really good enough. It’s also possible to use the vSphere 5.5 SSO install in a HA configuration - however, many companies are making the move to the latest version of vSphere and don’t necessarily want to maintain a 5.5 HA SSO instance.
Having just welcomed VMTurbo on board as a blog sponsor, I thought I’d do a quick posting on how to deploy their free Virtual Health Monitor appliance.
Sign up for a free license here and download the appropriate version
Deploy the VMTurbo Appliance
Deploying the appliance is simply a case of importing the OVA downloaded. There’s nothing really to configure and it took 61 seconds in my lab environment, so it’s pretty quick! Network configuration is via DHCP and you can configure a static IP by logging into the console and running “ipsetup”
After deploying a new vSphere 6 vCenter Server Appliance (VCSA) and configuring the Platform Services Controller (PSC) to act as a subordinate Certificate Authority (CS), I was unable to register the NSX Manager to the Lookup Service. Try saying that fast after a pint or two!?
Attempting to register NSX to the Lookup Service would result in the following error:
NSX Management Service operation failed.( Initialization of Admin Registration Service Provider failed. Root Cause: Error occurred while registration of lookup service, com.vmware.vim.vmomi.core.exception.CertificateValidationException: Server certificate chain not verified )
