Introduction
Starting with the release of vSphere 6.0, vCenter Server deployment has changed and it’s now possible to deploy two different components that together provide all services for the vCenter management platform.
- The Platform Services Controller (PSC) that provides common infrastructure services for the datacenter.
- The vCenter Server that provides the remainder of the vCenter Server functionality.
To make an example, just think about the different types of roles that you can have on a Windows Server.
The idea was to have a common platform for shared services that was also usable to other VMware’s products (but this idea was never been used for other products).
The PSC “role” included several infrastructure services:
- Single Sign-On (SSO)
– Secure Token Service (STS)
– Identity Management Service (IdM)
– Directory Service (VMDir)
- VMware Licensing Service
- VMware Certificate Authority (VMCA)
- Certificate Store
- Service (Product) Registration
- Misc Services
– Authentication Framework Daemon (AFD)
– Component Manager Service (CM)
– HTTP Reverse Proxy
For more information see also the VMware KB 2113115 (FAQ: VMware Platform Services Controller in vSphere 6.0).
The vCenter “role” includes several other services specific to the vCenter functionality, like:
- vCenter Server itself (the vpxd service)
- Auto Deploy
- Syslog Collector
- ESXi Dump Collector
- The web servers used for the vSphere Web Client and vSphere HTML5 Client
- Content Library
- The embedded database server (if no external database is used)
- And more
All those “roles” can be implemented with Windows installable components or with the VCSA (Linux virtual appliance based) approach.
Starting with vSphere 6.5 the VCSA approach is the recommended and, with the new major release, the Windows installable option will be removed (see https://blogs.vmware.com/vsphere/2017/08/farewell-vcenter-server-windows.html).
Installation options are into a virtual machine (VCSA and Windows versions) or also on a physical machine (Windows only), both types of installation are supported by VMware.
Deployment options
Those two different “roles” or components could be implemented and deployed in two different ways:
- vCenter Server with an Embedded Platform Services Controller.
- vCenter Server with an External Platform Services Controller.
The “embedded” deployment installs all services on the same system (virtual machine or physical server) as your vCenter Server. It’s ideal for small environments, or when simplicity and reduced resource utilization are key factors for the environment.
Note that using VCSA, this type of deployment can still support all vCenter Server maximum.
With the external PSC deployment, the platform services are installed on a separate system from the one hosting vCenter services. The same PSC could be “shared” across multiple vCenter Server nodes, using the Enhanced Linked Mode capability.
This type of deployment ideal for larger environments, where there is a need for a single-pane-of-glass view into the environment and where there are multiple vCenter Servers on the same site.
You can migrate from a deployment type to another without redeploying the vCenter or PSC using those resources:
- To migrate from an embedded to an external PSC see VMware KB 2148924 (How to reconfigure vCenter Server with Embedded PSC to vCenter Server with External PSC).
- Starting with vSphere 6.7 Update 1 it’s now possible also migrate from an external PSC to an embedded PSC using the new Convergence Tool (http://emadyounis.com/vcenter-server-6-7-update-1-convergence-tool/).
Linked Mode
You can “federate” multiple vCenter Server systems using vCenter Linked Mode (introduced in vSphere 4.0) to build a single pane of glass and share information between vCenter instances, like view and manage the inventories of all the vCenter Server systems that are linked.
Starting with vSphere 6.0, a new vCenter Enhanced Linked Mode (ELM) was introduced to replace the existing Linked Mode capability which was based on Microsoft ADAM technology.
With ELM is possible to use a shared PSC for all vCenter building a single-pane of glass management with a maximum of 15 vCenter (with vSphere 6.5U1 or later).
But until vSphere 6.5U2 the PSC only supported option was with the external PSC. Now it’s also possible using an Embedded deployment.
Roles, Global Permissions, Licenses, Certificates, vSphere Tags and VM Storage Policies are automatically replicated across all vCenter instances.
But with the new VMware Cloud on AWS (VMC) offering there is also a new Hybrid Linked Mode (HLM), with a completely different implementation and some differences with ELM:
- It supports only the Embedded deployment, and not the external PSC deployment.
- Can be configured at any point in the on-prem vCenter Server, not only during the initial install.
- Instead of a 2-way trust, a 1-way trust is established where the “cloud part” trusts the on-prem vCenter Server and data are synced uni-directionally from on-prem to the cloud.
For more information about the differences between ELM and HLM see:
http://www.virtuallyghetto.com/2017/09/enhanced-linked-mode-elm-vs-hybrid-linked-mode-hlm.html.
SSO domains
Linked mode works around the concept of SSO domains. The vCenter Single Sign-On (SSO) component is used to authenticate a user in an identity source backend.
To make an example, it’s like an Active Directory Domain Controller. And has some similar concepts, like:
- SSO domain: the built-in domain used for the authentication without any other external dependency. Like an AD domain it’s similar to a DNS domain, but does not require any DNS zone to work properly.
Usually, it’s used the vsphere.local domain. With vSphere 6.0 and later, you can give your vSphere domain a unique name. To prevent authentication conflicts, use a name that is not used by OpenLDAP, Microsoft Active Directory, and other directory services.
The domain name is used by the VMware Directory Service (vmdir) for all Lightweight Directory Access Protocol (LDAP) internal structuring. - SSO site: you can organize PSC domains into logical sites. A site in the VMware Directory Service is a logical container for grouping Platform Services Controller instances within an SSO domain. Quite similar to the AD site concept.
- SSO replication: more PSC could be joined at the same SSO domain (like more AD DC can exist for the same domain) and they can automatically replicate the data using a multi-master approach (like with the AD DC).
To implement the ELM you need the same SSO domain for all the vCenter Servers.
In the HLM, the SSO domains will be different between on-prem and VMC, however, there is a 1:1 relationship between them.
VMware vCenter and PSC topologies
Depending on the PSC deployment (external or embedded) and the number of SSO domains, sites and the number of PSC you can have a lot of different topologies.
But only a few are really supported by VMware, and also this depends by the vSphere version:
- For vSphere 6.0 see VMware KB 2108548 (List of recommended topologies for VMware vSphere 6.0)
- For vSphere 6.5 see VMware KB 2147672 (Supported and deprecated topologies for VMware vSphere 6.5)
- For vSphere 6.5 Update 2 and vSphere 6.7 finally, the embedded deployment is fully supported
Consider all the possible topologies may not so much interesting and can create too much confusion, for this reason, we will consider only the main possible topologies:
- Single site, multiple vCenter federate with ELM
- Multi-site, multiple vCenter federate with ELM
- Hybrid cloud, with HLM
The last one it’s related only if you are using VMware Cloud on AWS and has its own configuration mode, well described in this post:
https://cloud.vmware.com/community/2017/11/02/configuring-hybrid-linked-mode-hlm-vmware-cloud-aws/.
In a single site, multi vCenter topology, there must be a single SSO domain for all the vCenter and one single SSO site.
That means usually have an external platform (at least for the logical point of view) for all the vCenter server:
You can have one single external PSC, or also multiple (for redundancy purpose).
But starting with vSphere 6.5 Update 2 it’s also possible have more vCenter with embedded PSC and using the SSO replication to keep all those PSC components in sync:
In a multi-site, multi vCenter topology, you will have more than one SSO site, but there must be still a single SSO domain for all the vCenter, but at least you need one PSC per site and the SSO replication will be used to keep all those PSC components in sync together.
Using an external deployment, it will be something like this:
Again, starting with vSphere 6.5 Update 2 it’s now possible using also the embedded PSC deployment with a configuration like this:
As you can notice, the topologies with the embedded PSC are very similar and much easier.
But what about redundancy and availability of the PSC and vCenter components? If we add also those aspects the topologies become much more complex.
External PSC availability
In order to provide better resiliency and availability of an external PSC deployment you need at least two external PSC within the same SSO domain (to use the SSO replication mechanism).
But each vCenter points statically to only one PSC address, so to have automatically failover you need also an external load balancer, in order to point all the vCenter servers to the virtual IP of the load balancer:
This solution makes the architecture much more complex (in a multi-site topology you need to repeat this schema in each site) but also add the external dependency of the load balancer (that is not included in vSphere).
If SSO domain includes three or more Platform Services Controller instances, you can manually create a ring topology. A ring topology ensures Platform Services Controller reliability when one of the instances fails. To create a ring topology, run the following command against the first and last Platform Services Controller instance that you have deployed:
|
1 |
/usr/lib/vmware-vmdir/bin/vdcrepadmin -f createagreement |
For more information see also: Deployment Topologies with External Platform Services Controller Instances and High Availability.
vCenter availability
Starting with vSphere is possible to use a new native vCenter High Availability (VCHA) function to increase the resiliency of the vCenter components (or also the PSC component in case of an embedded deployment).
It’s possible configure a tree node cluster of vCenter servers (only using the VCSA option) with one active node, one standby node and one witness node:
For more information see this blog post:
https://blogs.vmware.com/vsphere/2018/04/vcenter-high-availability-deep-dive-part-1.html
This solution is much simplest and can also recover and embedded PSC making the overall architecture much complete but also much clean.
And starting with vSphere 6.5 Update 2 it’s also possible use ELM between embedded PSC.
Conclusions
The embedded PSC deployment is becoming much more popular and become the recommend deployment type (from vSphere 6.5 Update 2) because it permit both ELM and HLM.
Also, the VCHA is becoming (from vSphere 6.5) the preferred solution to provide vCenter redundancy.
Combining both solutions you can have simplest deployment topologies.
To make an example, just look at the overall topology for a multi-site deployment with a proper component redundancy if you use the external PSC approach:
Very complex architecture, with at least 5 VMs per site plus the load balancer components.
Using embedded deployment is possible reduce to only 3 VMs per sites without any load balanced dependencies:
Much cleaner and easier to deploy.
Of course, all those changes in the supported topologies can make much difficult found a proper path to upgrade your environment. To facilitate this operation, VMware has announced the vSphere 6.7 Topology and Upgrade Planning Tool.
