This will walk you through doing the vCenter HA deployment with the Advanced option. The reason you would use the Advanced option is if the vCenter VMs are not in the inventory of the vCenter that is going to be deployed as HA. This would mean that you deployed the VMs in another vCenter. There is good reason to deploy in another vCenter. Perhaps you have a vCenter already running and you will be migrating to this newer vCenter. The other reason might be that you deployed in a different vCenter, it will allow you to snapshot the VMs during your deployment.
A supported vCenter HA configuration needs to have three separate hosts. One for each vCenter (two hosts) and one for the witness server (one host). If we did the Basic install, it would put the VMs on different hosts and add anti-affinity rules. You can follow this article about deploying with less than three hosts and the configuration change that is needed. Less than three hosts is not supported and should only be used in a test/lab environment.
Deploying vSphere 6.5 vCenter HA
The first thing we need to do is edit the vCenter VM you have deployed already and add a NIC to it.
Place the NIC on the VLAN/portgroup that will house the vCenter HA network (this is the non-public address space for vCenter HA… meaning, the communication done on this VLAN for vCenter HA is for the exchange of HA information.
This will walk you through deploying vCenter for HA. The deployment is actually very similar to deploying a non-HA configuration. This will use the same installer.exe that you use to deploy the PSCs.
Deploying vCenter 6.5 Update 2
You have the Load Balancers setup for connecting to your PSCs
You have the PSCs setup properly with certs from the VMCA (this includes the VIP FQDN)
You have the DNS names created for any vCenter you will deploy (this includes the reverse DNS)
If you are able to take snaps of your PSCs while they are down (this would mean you are deploying into a different vCenter that enables snapshots to be taken). If this is a greenfield, you can take a snapshot of the PSCs while running, but I do not believe this is supported.
Launch the installer.exe
Put a check in I accept the terms of the license agreement and then click Next
Select vCenter Server (Requires External Platform Services Controller) and then click Next
Type in the vCenter (or host) FQDN name that you will be deploying to and use the an administrator account (or root account if you are deploying to a host) to authenticate.
Click Yes to accept the thumbprint
Select the Datacenter you will deploy to and then click Next
Select a host to deploy vCenter to and then click Next
Type in the name of the appliance (this is the name that will show up in vCenter or on the host within it’s inventory) and the root password you want to use. Click Next
Select the size you would like to use and then click Next
Select the datastore and then click Next
Set the following:
System Name (this is the fqdn of the vCenter you are deploying)
DNS Server (you can enter just one for the time being)
Validate that all the information entered is correct and then click Finish
Yes, during the deployment of this configuration, I had to open a Support Request due to what I can only refer to as “bugs”. The case was escalated and the second tier engineer actually pointed me to that post. It is done by one of their VMware Engineers. Sadly, I had been referring to the article already. What I’m going to try to do is provide detail on Update 2 as there seems to be slight updates there.
Adjusting the Machine SSL Certificate on your Platform Services Controllers (PSCs) for Load Balancing
SSH into your first PSC
Type: cd /certs (if the directory doesn’t exist, type mkdir /certs)
This will be the first part of deploying your vSphere 6.5 Update 2 Platform Services Controller (PSC) and vCenter in an HA configuration. We will walk through the entire setup starting with the Platform Services Controllers (PSCs) and then move on to deploying vCenter and configuring the HA environment.
Video Demonstration and Discussion
DNS for every system (this includes the reverse DNS) – All of your PSC and vCenter deployments along with the VIP on your load balancers need this setup before you start
Secondary VLAN for the Private Network between vCenter servers and the Witness server (this VLAN must be different than the VLAN used for the management of vCenter)
Load Balancers need to be up and ready. There are only three load balancers that are supported by VMware: NetScaler, F5 and NSX. Your configuration is unsupported if you use another load balancer (even if it works). VMware actually does a decent job of going through each of these configurations:
Some of the articles talk about putting certificates on your Load Balancers. This is not required. SSL Passthrough (which means you don’t have certs on the load balancers) is a supported configuration. Within this document, I will be doing SSL Passthrough.
One thing you should note and not miss, is that the Timeout (or stickiness) of the connections within the load balancers needs to be set to 1440 seconds. The issue, especially with the deployment, is if this is not set, the deploy can fail if it tries to hit one PSC and then at a later time, hits the other PSC. I’ve even gone so far as to shutdown one PSC at a site during the deployment to make sure I don’t have to rebuild 🙂
Deploying the Platform Services Controllers (PSCs)
This process will walk you through deploying your vSphere 6.5 Platform Service Controllers in a Ring Topology. This is useful for deploying your PSCs into a single SSO domain with multiple sites (hence creating the Enhanced Linked Mode setup). It is also useful if you are going to be doing vCenter HA (vCenter HA is the process of making vCenter Highly Available as apposed to setting HA up for your clusters).
Deploying vSphere 6.5 Platform Service Controllers (PSC) in a Replication Agreement
DNS entries for every PSC (this includes the reverse DNS)
The PSCs have to be installed one at a time. For the initial config I found that if you configure one DNS server and one NTP server during deployment it works out better. You can add a secondary DNS and NTP after you’ve finished the deployment.
This process will use ONE SSO domain (vsphere.local) and two sites (SITE1 and SITE2) – This creates our Enhanced Linked Mode between two sites.
Leveraging the installer.exe from the vCenter ISO, you will deploy each PSC completely for one site and then move on to the next site.
You will create a replication ring since we’ll have more than 2 PSCs
Launch the installer.exe
Accept the EULA and then click Next
Under External Platform Services Controller select Platform Services Controller and then click Next
Enter in the vCenter FQDN name that you will be using to deploy the PSC (alternatively, you can enter in a host to deploy to). Follow that by enter in a username and password of an account that has Administrator (or root) access. Click Next
A thumbprint window may appear. Click Yes
Select the Cluster that the PSC will be deployed to (optionally, you can select a Folder as well).
We are going to walk through how to create a Subordinate CA from your own internal CA. We’ll be using Microsoft for our CA but you are welcome to use your own.
One of the reasons for this particular guide is just due to some changes I noticed in Update 2 that may not be clear when using older documentation. I’ve retrofitted the older documentation that I found so hopefully this is easier to follow.
Creating a Microsoft Certificate Authority Template for SSL certificate creation in vSphere 6.5 Update 2
Note: If you have a Root CA (offline) and a Subordinate CA (online), the instructions here will need to be carried out on the Subordinate CA. After all, he’s the only one online. Right? 😉
If you want to buck normal convention and only have the Root CA be online, you will do these steps on him instead.
Click Start > Run and then type: certtmpl.msc
Find the Subordinate Certificate Authority template and right click it and select Duplicate Template
Change the Certificate Authority to Windows Server 2008
Click the General tab
Change the Template display name to: vSphere 6.x VMCA
Change the Validity period to 10 years and the Renewal period to 5 years (Things to note here: You can choose values here to conform to your own companies requirements. Further, when the VMCA issues certificates, the validity period is 2 years by default regardless of what you put here – this seems to be new in Update 2).
Click the Extensions tab
Select Key Usage and click Edit
Adjust the settings to conform to the following:
Click OK (or Cancel if you did not have to make changes)