Ever got yourself in a situation where you thought, crap, now I’m stuck with a stupid decision I made a while back? This happens in the vSphere world as well when people choose a vCenter server with an embedded Platform Services Controller. Installing vCenter with an embedded Platform Services Controller is fine for smaller and test environments. It keeps the footprint small and is easy to maintain. When environments need to scale or be more resilient it is better to have external PSC’s. For instance, you can’t use two vCenter servers in enhanced linked mode when using the embedded option, so when scaling out it becomes more difficult to manage. To overcome all sorts of challenges it might be a good idea to use an external PSC (which is also a best practice). If you started of with an embedded PSC, I got you covered. In this blog post we will move from an embedded to an external PSC. We will also deploy this external PSC using the unattended install method because automating things is really cool. I will also touch on the subject of replication topologies when the number of PSC’s grows beyond two.
Overview of what we are doing
I will be using the vCenter server appliance version 6.0 Update 2. We start of with a vCenter appliance with an embedded PSC. We need to change this setup to a vCenter with an external PSC. To start off we install a new PSC using vcsa-deploy. This is a command line tool included on the vCenter ISO that installs a Platform Services Controller or vCenter using a predefined JSON template. After that we reconfigure the vCenter server so it uses the new PSC and we remove the embedded PSC from the vCenter server.
This is a visual representation of our starting point.
Install Platform Services Controller
Before we can start deploying the Platform Services Controller with vcsa-deploy we need to set up the DNS entry for the Platform Services Controller. During the setup there is a check for forward and reverse DNS so make sure these are created before deploying.
We then setup the JSON template. The ISO has a number of example templates available so it is fairly easy to get started with this. All parameter options are described in the official documentation.
NOTE: The command line tool was changed from version 6.0 Update 3 so be sure to use the correct document.
This is the template I created, because comments can not be used in JSON files I have added comments behind <–. To use this specific JSON template you need to remove the <– and the comment behind it from the file.
{
"__version": "1.1",
"__comments": "Deploy a Platform Services Controller to SSO domain", <-- This is the only allowed comment.
"target.vcsa": {
"appliance": {
"deployment.network": "VM-RegionA01-vDS-COMP", <-- The network the appliance needs to be connected to
"deployment.option": "infrastructure", <-- The type of deployment, infrastructure is used for PSC's
"name": "psc-01b", <-- The VM name
"thin.disk.mode": true <-- This doesn’t need explanation
},
"network": {
"hostname": "psc-01b.corp.local", <-- The FQDN of the appliance
"dns.servers": [
"192.168.110.10"
],
"gateway": "192.168.110.1",
"ip": "192.168.110.150",
"ip.family": "ipv4",
"mode": "static",
"prefix": "24"
},
"os": {
"password": "VMware1!", <-- The root password of the appliance
"ssh.enable": true
},
"sso": {
"password": "VMware1!", <-- SSO password for existing domain
"domain-name": "vsphere.local", <-- SSO domain name for existing domain
"first-instance": false, <-- False because we are adding to an existing SSO domain
"replication-partner-hostname": "vcsa-01b.corp.local", <-- Name of the PSC to replicate with (our embedded PSC)
"site-name": "first-site" <-- SSO site name for existing domain
},
"vc": { <-- This is where we are deploying to
"hostname": "vcsa-01a.corp.local", <-- vCenter server we are deploying to
"username": "Administrator@vsphere.local",
"password": "VMware1!", <-- SSO password for existing domain
"datacenter": [
"RegionA01" <-- vSphere datacenter we are deploying to
],
"datastore": "RegionA01-ISCSI02-COMP02", <-- vSphere datastore we are deploying to (NOT datastore cluster)
"target": [
"RegionA01-COMP01" <-- vSphere cluster we are deploying to
]
}
}
}
Now that we have the template complete we can start the installation. Hook up the vCenter Server Appliance ISO to your management station and start a command prompt. I am using Windows in this case but the vcsa-deploy tool is also available for Linux and Mac OS.
Run the following command:
D:\vcsa-cli-installer\vcsa-deploy.exe --accept-eula C:\path\to\json\template_file.json
Get a cup of coffee and relax because this will take some time. After this process is finished the new Platform Services Controller will be running and replicating with the embedded Platform Services Controller that is included with your vCenter Server.
When the installation is done we are at the following scenario:
Reconfigure vCenter and removing the embedded PSC
The next step is to point the vCenter server towards the new Platform Services Controller. This can be done with a command directly from the appliance shell. Log in to the vCenter appliance with SSH as root and enable the shell.
shell.set --enabled true shell
First lets check if the replication between the two PSC’s was successful. With the following command.
vcsa-01a:~ # /usr/lib/vmware-vmdir/bin/vdcrepadmin -f showpartnerstatus -h localhost -u administrator -w <password> Partner: psc-01a.corp.local Host available: Yes Status available: Yes My last change number: 4478 Partner has seen my change number: 4478 Partner is 0 changes behind.
As you can see the partner is 0 changes behind and they both have the same change number so it is save to assume replication was successful.
We can now reconfigure the vCenter server so it will point towards the external PSC and remove the embedded PSC services locally. This procedure is actually pretty straight forward. There is a command we can use to do both steps in one go.
/bin/cmsso-util reconfigure --repoint-psc psc-01a.corp.local --username administrator --domain-name vsphere.local --passwd <SSO-DomainAdmin-Password>
Don’t confuse the “reconfigure –repoint-psc” parameter with the “repoint –repoint-psc”. The reconfigure parameter lets you repoint the vCenter server to the external PSC and remove the local PSC components and services from the vCenter server. If you should use the repoint parameter, you will only point the vCenter server to the external PSC but will not remove the local PSC components and services.
After this we are in the following scenario:
Conclusion
So, basically the procedure to move from an embedded Platform Services Controller to an external Platform Services Controller is now done. What I would suggest though is adding another PSC in the mix at this point. This wil give some extra resiliency and flexibility if something would happen to the Platform Services Controller or if you need to perform maintenance. With a second Platform Services Controller you can easily repoint (remember the parameter we discussed above) the vCenter server to the second Platform Services Controller and keep running smoothly.
In this post I used the unattended installation method to install that external PSC. This is mainly because I like automating things but there is another catch to it. While filling out the template it really gets you thinking up front on what you want to achieve, this helps you to better understand what you are doing. What you usually get is people firing up the GUI en start filling in the required information on the fly and acquiring this as they go along. This could be more time-consuming and error prone (especially when deploying multiple PSC’s or vCenter servers). On a final note, when you need to install more than one component or need to repeat it often unattended installs are the way to go.
