vSphere 6 – Platform Services Controller (PSC): Design

In vSphere 6.0 the architecture has changed quite a bit and there are some new concepts to learn. In this post I will talk about the changes in architecture and in particular the Platform Services Controller (PSC) because it will determine how you install or upgrade your environment. You’ll find other articles about the PSC, this post will help in giving an idea of what are the changes related to architecture in vSphere 6.0 and what are the design decisions you need to make with regards to Platform Services Controller (PSC) when installing or upgrading an environment for vSphere 6.

In previous versions, the application side (Management, Operations etc.) was bundled together with the security and authentication. With version 5.1 and upwards, SSO was introduced and that was the first time, we started seeing the shift towards isolating security services from the application. With vSphere 6.0, that transition is complete and the architecture has now been divided into two separate entities: a “Management Node” and the “Platform Services Controller (PSC)”.


The Management Node contains all the application and services dedicated to run and manage the environment e.g.

•vSphere Management

•Infrastructure Monitoring

•APIs etc.

whereas the Platform Services Controller (PSC) is where the infrastructure security components are placed e.g.

•Single Sign On


•Certificate Management

•Identity Management etc.


It’s important to know that while the install topology decisions for Platform Services Controller might be similar to SSO, it is much more than just SSO: there are more services added, thereby it becoming a major block of services in itself. In the past, some people thought separating out SSO as being expensive just for one service. Now there are many services bundled so it would make sense in most cases.

The Management Node has the same components that we’ve used in the past and therefore the decision making processes for them are similar to before. Platform Service Node, however, is a change worth discussing more and why it impacts design decisions.

Embedded or External?

This is a question asked during the install of vCenter and something that one should decide on before getting to that stage. Why? Well the reason is that once you take that decision, you’re stuck with it. Changing it will require a reinstall. So, what is the difference?

Functionalities are the same.  “Embedded” means that the install is done on the same server as was done in a “Simple Install” in vSphere 5.x, whereas “External” is similar to the “Custom Install” and means having a separate server for installation (without vCenter and its components).

Now that we know this, what are the main decision points to consider?


The important question here is: How many vCenters or “PSC Enabled Solutions” will you have in the environment? By “PSC Enabled Solutions”, it’s meant that solutions that will/can utilize the PSC for authentication or other services e.g. vRealize Automation etc.

Think long term. If you are an organization that wants to have geographically-dispersed sites, wants resilience and also has vRealize Automation or similar products installed, an “External” PSC would be the way to go. You would possibly also consider a High Availability (HA) set up for that, in the same way as many organizations did for SSO.

If you have a single site and can’t see the organization going beyond 8 vCenters you can quite safely have installations with “Embedded” PSCs. However, it is important to remember that VMware currently recommends no more than 8 PSCs..

It’s worth mentioning here that a “Hybrid” configuration is also possible e.g. you can have a mix of embedded and external PSC deployments, should you feel it better suits your implementation. Just be mindful of having a reasonable number of them. Also, bear in mind that if you’re deploying the appliance version, PSC is already there.  It doesn’t matter if you have embedded/external or hybrid PSCs (Windows or Appliance), they all replicate with each other automatically and are kept in sync.


In the same way as you could have many vCenters running against a single SSO, a single PSC is enough to run your entire environment.

Server Loading

Now that there are even more components bundled a PSC it will depend on your usual policies to determine if separating the PSC out from the vCenter server. Separating it out requires an additional Windows license (not an issue if you’re using the appliance version) but results in less resource allocation per server. However, if policy within the organization prefers having less but bigger servers, keeping them together results in less management overhead.

Once you’ve made your decision, installation of it is pretty simple; just choose the option when it appears. Choosing embedded is just like doing a “Simple” install. If you choose external, you won’t be able to install vCenter on it any more so be prepared to have another VM to take the vCenter install. Once at least one PSC is deployed, you can go ahead and install vCenter. When asked during the installation, you’ve just to point the installation towards the server running the PSC role and the rest is the same.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.