The vSphere development team has done a great job in maintaining the same look and feel when it comes to interface of the new vSphere 6.0. Of course, there are minor changes due to new features but if you’ve been using previous versions of vSphere, you’ll have no trouble navigating through the new version.
However, don’t let this fool you. The engine and architecture has changed quite a bit in this version and there are some new concepts to learn. In this article, I am going to talk about the changes in architecture and in particular, Platform Services Controller (PSC) as that will determine how you install or upgrade your environment.
In previous versions, the application side of things e.g. Management, Operations etc. were 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 clear entities: a “Management Node” and the “Platform Services Controller (PSC)”.
The Management Node contains all the application and services you associate with the running and management of 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 i.e. 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.
As you can see, 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?
Functionally, they’re the same. Simply put: “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 VM/server for installation i.e. 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 organisations did for SSO.
As compared to that, if you have a single site and can’t see the organization going beyond 8 vCenters or so, then you can quite safely have installations with “Embedded” PSCs. However, it is important to remember that VMware currently recommends no more than 8 PSCs. I don’t think it’s a hard limit but be careful as installing too many vCenters with embedded PSCs may exhaust the maximum number of PSCs you should have in an environment.
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, you may have deployed it with the PSC already enabled. 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/HA SSO, a single/HA PSC is enough to run your entire environment. The usual decisions regarding resilience and Single Point of Failure apply.
Now that there are even more components bundled a PSC, dealing with Certificate Management, Licensing and other things, it will depend on your usual policies to determine if separating the PSC out from the vCenter server is worth doing or not. 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/machine deployed to take the vCenter install. Once at least one PSC is deployed, you can go ahead and install vCenter. When asked during the installation, just point the installation towards the server running the PSC role and the rest is the same.
I am sure there is more detail that you’ll go through in form of other blog articles and documentation etc. in coming days but hopefully, this post will help in giving an early idea of what are the changes with respect to architecture in vSphere 6.0 and what are the design decisions one needs to make with regards to Platform Services Controller (PSC) when installing or upgrading an environment for vSphere 6.