I’m writing this info down so I can find it easily later, but maybe it will help others too. This was deployed in my AutoLab 2.6 environment, running on an ESXi 5.5 host. I wanted to test the use of highly available Platform Services Controllers, which of course requires a load balancer placed between vCenter and the PSC nodes.
For lab use I chose the free Citrix Netscaler VPX Express, which can be licensed for free 1 year at a time with a MyCitrix.com account. Having never used a netscaler before, I relied on this excellent guide for assistance in deploying and initial configuration.
Deployment
I deployed a pair of PSC nodes using the included vcsa-cli-installer on the VCSA install iso. That was pretty simple, the json formatted install file is well documented (there is a fantastic series on doing this over at virtuallyghetto). They had to be deployed directly to the ESXi 5.5 outer host, after which I moved them into the AutoLab vApp. I used the following commands in a batch file, after extracting the contents of the VCSA install iso to \\192.168.199.7\build\VCSA6
set NetPath=%~dp0
%NetPath%VMware-VCSA-all-6.0.0-2656757\vcsa-cli-installer\win32\vcsa-deploy.exe --no-esx-ssl-verify B:\Automate\PSC1\psc01.json
%NetPath%VMware-VCSA-all-6.0.0-2656757\vcsa-cli-installer\win32\vcsa-deploy.exe -v --no-esx-ssl-verify B:\Automate\PSC1\psc02.json
The VM from which I ran the installer had to have a network interface connected to the internal autolab network. The first psc deployed fine without it, but to add the second, the installer needed to obtain an authentication token from the first psc.
Certificate Signing
Prior to running the HA scripts on the PSC appliances, I needed to configure the VMware Certificate Authority (VMCA) as a subordinate CA. This will be signed by the Microsoft CA running on the DC in the autolab deployment. I followed the steps in KB 2112016 to do that.
In order to copy out the certificate signing request, I scp’d the files from the first PSC. Before you can use SCP, you will need to run the steps documented in KB 2107727. ssh to the PSC appliance using the credentials you defined in the json files earlier, and run the following commands. I ran this from the same VM that I used to deploy the PSC’s originally, so I could go directly to the PSC IPs, but you could do this from a VM inside the autolab deployment as well.
shell.set –enable True
shell
chsh -s /bin/bash root
When we’re finished, we’ll change the default shell back by running this command:
chsh -s /bin/appliancesh root
When running the certificate manager (/usr/lib/vmware-vmca/bin/certificate-manager), you will need to supply a path to store the certificate files. There is no default specified, so I just used /root
Edit /usr/lib/vmware-vmca/share/config/certool.cfg and update the defaults before running the certificate manager.
Follow the steps in KB 2112014 for signing the csr. I was expecting to need to follow the steps under the heading “Creating a new template for vSphere 6.0 to use for VMCA as a Subordinate CA” in KB 2112009, but unfortunately the AutoLab CA is configured as a standalone root CA, which doesn’t support certificate templates.
Visit https://dc.lab.local/certsrv/ to access the Microsoft CA and submit the certificate signing request, then approve the certificate via the certsrv.msc snapin (look under pending requests). As per the VMware KB, download the resulting signed certificate as a Base64 encoded certificate, then download the CA Certificate chain as base64. In autolab there are no intermediate CAs, but in a real environment there might be one or more. Combine them into one certificate file root_signing_cert.cer as in KB 2112014 by placing the signed certificate first, then any intermediate certificates, then lastly the root CA certificate.
Copy root_signing_cert.cer back to the first PSC, and apply it using certificate-manager option 1. When entering the details for certool.cfg, use the FQDN of the actual PSC appliance (psc01.lab.local) rather than the highly available name (in my case psc.lab.local).
After installing the certificate, make sure you stop and start all services on the PSC using the commands service-control --stop --all and service-control --start --all
Verify the certificate was installed successfully by visiting the PSC in a web browser (in my case, https://psc01.lab.local). Check the certification chain, make sure that the VMware CA is now in the chain.
Using SCP, copy the same certificate to the PSC replication partner, in my case psc02.lab.local. Choose option 2, then option 2 in the certificate-manager to install the same certificate. Make sure you enter the same options for certool.cfg, except for the hostname.
HA Scripts
I followed the steps in KB 2113315 to run the HA scripts. Upload the HA script from this link via winscp, then extract to /ha.
mkdir /ha
cd /ha
unzip ~/VMware-psc-ha-6.0.0-2924684.zip
Skip step 4 in this KB, since we are using the subordinate CA configuration for the VMCAs.
Run the following command on the first PSC from the /ha folder, make sure you update the FQDN to match the load-balanced FQDN in your environment:
python gen-lb-cert.py –primary-node –lb-fqdn=psc.lab.local
Wait for the command to complete. Skip steps 6 and 7 in the KB.
Copy /etc/vmware-sso/keys to /ha/keys.
mkdir /ha/keys
cp /etc/vmware-sso/keys/* /ha/keys
Copy the /ha folder to the second PSC and run the following command, again making sure you update the FQDN:
python gen-lb-cert.py --secondary-node --lb-fqdn=psc.lab.local --lb-cert-folder=/ha --sso-serversign-folder=/ha/keys
Wait for the command to complete. We’ll come back to this KB article shortly.
Load balancer configuration
After you have done the initial netscaler config (see previously mentioned guide), follow the steps in KB 2116281 for configuring the Netscaler load balancer.
- Login with username and password nsroot.
- Enable SSL Offloading, under System -> Settings -> Configure Basic Features. The Virtual Server for port 443 won’t come up until this feature is enabled (I found this out the hard way, thanks to the guys over at definit.co.uk for this post that helped me out)
- Upload the load balancer certificate (lb.crt and lb_rsa.key), leaving the certificate type to PEM with a blank password.
- Upload the CA certificate (root.cer). I named this certificate Root CA
- Right click on the psc-ha-crt, choose link, and select Root CA
- Add the two PSCs to the configuration under Load Balancing -> Servers
- Create services as per the KB article
- Configure the virtual servers. When prompted, enable load balancing. I found that all the virtual servers showed as down until I had completed the next step.
- Create the persistency group
Complete the HA configuration
Return to the KB article 2113315 and continue from step E. Open an ssh session to the first PSC node and run the following command:
python lstoolHA.py --hostname=psc01.lab.local --lb-fqdn=psc.lab.local --lb-cert-folder=/ha --user=Administrator@vsphere.local
This command will output a lot of information to the terminal. Wait until it completes. Verify that the PSC is still functional by using the following command. It should match the site specified in the json files you used to deploy the appliances.
python /usr/lib/vmidentity/tools/scripts/lstool.py get-site-id --url https://psc01.lab.local/lookupservice/sdk 2> /dev/null
There should be one line returned, which will be the sitename (in my case, default-first-site). Use this in the following commands to verify the PSC address.
python /usr/lib/vmidentity/tools/scripts/lstool.py list --url http://localhost/lookupservice/sdk --site default-first-site --type cs.license | grep "URL:"
python /usr/lib/vmidentity/tools/scripts/lstool.py list --url http://localhost/lookupservice/sdk --site default-first-site --type cs.identity| grep "URL:"
The output should be a bunch of information messages, followed by a list of URLs that refer to the load balanced FQDN.
Join PSC to Active Directory
Join the first node to the Active Directory domain with the following command, and then reboot the node:
/opt/likewise/bin/domainjoin-cli join lab.local administrator
Wait for the first node to finish booting, then repeat these commands on the secondary PSC node.
Add the identity source for Active Directory on the first PSC node only:
/usr/lib/vmidentity/tools/scripts/sso-add-native-ad-idp.sh lab.local
Return the PSC shell to the default by running this command on both of the PSC nodes:
chsh -s /bin/appliancesh root
Complete!
You’re now ready to install vCenter with an external PSC. Make sure you use the load balanced FQDN when registering the vCenter to the PSC.