VMware is deprecating the external Platform Services Controller deployment model. In a future vSphere release (not update release), there will no longer be an option to deploy the external PSC
The Platform Services Controller (PSC) was first introduced in vSphere 6.0. It served a couple of purposes. First, it was to simplify the distributed vCenter Server deployment model. vSphere 5.1 allowed core vCenter Server services to run on separate nodes. This increased the number of vCenter Server nodes to roughly six nodes including the vCenter Server Database (VCDB) and vSphere Update Manager (VUM). While adding architecture choices and flexibility, the distributed deployment model became too complex for management, maintenance, and upgrades. The PSC reduced deployment options and thus complexity by offering a simpler two node architecture. Second, the PSC provided more than just single sign-on (SSO) authentication. It also managed licensing, tags & categories, global permissions, and custom roles. It is also the certificate authority for the vSphere SSO domain. Now all these components were being replicated across a vSphere SSO domain. Finally, the PSC also enhanced the experience with previous version of linked mode which included all the vSphere SSO Domain capabilities mentioned. When a vCenter Server gets registered to a vSphere SSO Domain, it inherits enhanced linked mode.
While the PSC did simplify the vSphere SSO domain, it also introduced complexity. As the gateway to the vSphere SSO Domain, its availability became important. It included no native availability and required the use of load balancers to add HA. Customers had to manage and maintain more nodes for enhanced linked mode. The PSC also had an embedded deployment option but did not support enhanced linked mode so linking embedded PSC deployments was not an option. Then there were SSO Sites and the choice of where to place the PSC during a deployment to ensure the best performance. So again, the choices and flexibility have created confusion and management complexity.
Moving Forward
vSphere 6.7 and vSphere 6.5 Update 2 introduced enhanced linked mode support for embedded PSC deployments. So, customers could now get all of the features and benefits of using external PSCs but without the complexity of extra nodes or load balancers. This was the next logical step in making customers’ lives easier by reducing management complexity.
But what about customers who already are using external PSC deployments? The answer lies in a new utility introduced in vSphere 6.7 Update 1. The converge utility allows customers with an external PSC deployment to migrate to an embedded PSC deployment. The embedded PSC deployment is the simplest and recommended deployment model going forward. Customers can protect vCenter Server and its embedded PSC using a native availability solution – vCenter High Availability – all without external components or load balancers.
Also included in vSphere 6.7 Update 1 is the repoint tool. A stand-alone embedded deployment can join or leave a vSphere SSO Domain. This helps provide flexibility for data center moves, acquisitions, or mergers. The vSphere team commitment is to ensure vCenter Server complexity is minimized while also delivering the tools required so that architectural choices can be changed as an organization evolves. To that end, we are announcing the deprecation of the external PSC deployment model. In a future vSphere release (not update release), there will no longer be an option to deploy the external PSC. Going forward the embedded deployment will be the only way to deploy vCenter Server. This will provide an easier vCenter Server lifecycle which means easier deployments, upgrades, and fewer nodes to manage.
While the PSC did help in some areas of the vSphere SSO Domain, the complexity ended up outweighing the benefit. We believe this new direction is the right direction. There are no more difficult architectural decisions for vCenter Server and customers now have the tools to move from one architecture to another without having to redeploy their infrastructure. High availability is built-in without the need for load balancers as well. Having said that, we know this transition hasn’t been easy and we’ve felt your pain through countless conversations with you, our customers. But with these new tools and capabilities, we think that customers will need to spend much less time architecting and maintaining their infrastructure and be able to use that time where it matters most in their data centers. We also look forward to even more improvements that the team is working to deliver.
