Automate changing the vSphere 6 Platform Services Controller IP address (and vRealize Automation)
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).
What I didn’t want to do was simply edit the connections directly – quite often with the VMware appliances there are scripts on start-up to ensure the configuration is correct and consistent – what I wanted was to be able to find a more supported and reliable way.
Fortunately the VAMI scripts are deployed on most appliances and are included on the PSC. I was able to work out a process (mostly by trial and error!) of getting the IP change to stick.
# Update the network IP address (this is for IPv4, there are options for IPv6 too, and DHCP) /opt/vmware/share/vami/vami_set_network eth0 STATICV4 192.168.10.52 255.255.255.0 192.168.10.1 # This updates the IP in /etc/hosts - requires the FQDN as an argument or sets it to localhost.localdomain /opt/vmware/share/vami/vami_set_hostname vra.definit.local # This makes the changes “stick” on reboot /opt/vmware/share/vami/vami_ensure_network_configuration eth0 reboot
I successfully used the the Guest Script Manager package from the VMware Center of Excellence to store and execute the script via vRealize Orchestrator, as well as using a bash script actually on the host. This worked during my testing to modify both the IP addresses in a PSC HA Cluster, and allowed (with some DNS changes) the fail-over to a completely different subnet.
vSphere 6 HA SSO (PSC) with NetScaler VPX Load Balancer for vRealize Automation
Posts in this series
- vSphere 6 HA SSO (PSC) with NetScaler VPX Load Balancer for vRealize Automation
- Deploying vRealize Automation 6.2 Appliance Cluster with Postgres Replication
- Deploying fully distributed vRealize Automation IaaS components - Part 1: Pre-requisites
- Deploying fully distributed vRealize Automation IaaS components - Part 2: Database, Web and Manager services
- Deploying fully distributed vRealize Automation instance - Configuring NetScaler Monitors
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.
The vSphere 6 Platform Services Controller can be deployed as an appliance or installed on a Windows host – personally I am a huge fan of the appliances and I tend to use them in my designs because of the simplicity and ease of use. A pair of PSCs can be deployed as a highly available SSO solution for vRealize Automation 6.2, replacing the Identity Appliance or vSphere 5.5. SSO, using either a NetScaler or F5 load balancer to load balance connections and provide the availability.
Personally, I’d prefer to use an NSX Edge Services Gateway to load balance the PSCs, but at the time of writing the Edge does not support the “Ability to have session affinity to the same PSC node across all configured ports”. See KB2112736 for more details.
So, this guide will show you how to create a highly available pair of Platform Service Controllers, configure one as a subordinate Certificate Authority to a Microsoft Certificate Services CA, and then load balance them with a NetScaler VPX. Although I am using just two node, you can in fact use the same method to load balance up to four. (more…)
Unable to connect NSX to Lookup Service when using a vSphere 6 subordinate certificate authority (VMCA)
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 )
Initially I thought that the NSX manager needed to somehow import the VMCA certificate to trust the Lookup Service certificate, however after reaching out to the NBSU ambassadors list I had a reply from Julienne Pham, a Technical Solutions Architect and CTO Ambassador with VMware Professional Services, who pointed me to the correct solution.
It seems that changing the PSC and vCenter certificates (even with the Certificate Manager tool) does not correctly update the service registration information. To quote VMware KB 2109074:
…the vCenter Server system uses a new certificate, but the service registration information on the Platform Services Controller is not updated
To resolve this issue, we need to use the ls_update_certs.py script to register the services correctly. (more…)