vmware psc что это
What is VMware Platform Service Controller (PSC)?
By Vladan SEGET | Last Updated: February 24, 2017
Several folks asked me recently What is VMware Platform Service Controller. I’ve published few guides on VMware vCenter Server Appliance (VCSA), the migration of vCenter to VCSA or in-place migration of Windows based vCenter but I think that I have not published enough information about VMware Platform Service Controller (PSC). Hence this post.
VMware PSC is not new. It was a part of vSphere 6.0 where it assured a number of services already. Services such as VMware Appliance Management Service, VMware License Service, VMware Component Manager, VMware Identity Management Service, VMware HTTP Reverse Proxy, VMware Service Control Agent, VMware Security Token Service, VMware Common Logging Service, VMware Syslog Health Service, VMware Authentication Framework, VMware Certificate Service, VMware Directory Service.
VMware PSC when deployed separately, in a separate VM, it deploys only the services bundled with the PSC, not the vCenter specific services. There are different topologies which exists and which has advantages or inconveniences.
PSC user interface allows many tasks already.
PSC allows:
Using single PSC in Single domain
The most simple are to deploy VMware PSC and vCenter server on a single VM, together. As such, the PSC component does not need a network connection to the vCenter server (as it communicates already, it is within the same VM).
Further, it has some following advantages:
Using multiple PSCs in single domain
Single PSC has several vCenter servers “hooked” into it.
The notion of a site, vSphere domain, Domain names….
PSC Domain – when installing PSC, there is a prompt to create vCenter SingleSign-On Domain (SSO) or join an existing domain. The domain name is used by VMware directory service for their internal LDAP structuring. You should always use another name then you’re using for your Microsoft AD, Open LDAP or other directory services within your organization.
PSC Site – You can organize PSC domains into logical sites. A site in the VMware Directory Service is a logical container for grouping PSC instances within a vCenter Single Sign-On domain.
PSC can also be deployed without a load balancer, but in this case, in a case of failure the PSC, you must manually fail over the vCenter Server instances that are registered to it by repointing them to other functional PSC instances within the same site.
Know that other types of deployments exist which we will sum here:
Platform Service Controller (PSC) services:
There is quite a few of them in vSphere 6.5.
Wrap up:
Most of the time you can stick with single VM where vCenter server and PSC collaborate together. If you want enhanced linked mode for your vCenter, and being able to manage several sites within a single console, than you’ll probbably deploy an external PSC, or 2 external PSCs behind a load balancer. You should know that not all load balancers are supported. Only F5, Netscaler, and NSX are supported. Nginix, haproxy, A10, etc are not supported.
Check more articles from ESX Virtualization:
Stay tuned through RSS, and social media channels (Twitter, FB, YouTube)
VMware PSC replication
Компонент Single Sign On, выполняющий проверку подлинности, появился в VMware vSphere 5.1. К vSphere 5.5 он стал «адекватнее» и стабильнее.
Его можно было поставить как на отдельный сервер, так и совместить вместе с vCenter Server.
В vSphere 6 этот компонент был объединен с другими сервисами в роли Platform Service Controller.
С тех пор и до vSphere 6.7 (или 6.7 Update 1) рекомендуемой схемой высокодоступного размещения PSC была следующая:
Наверное, особенно круто было заниматься обновлением этого зоопарка из 4+ систем.
Особенно я прослезился со следующего KB — правила репликации PSC, рассказавшего о том, что репликация происходит в том порядке, в каком ранее добавлялись PSC (если развернули первый, на него нацелили второй, на второй — третий, то и репликация пойдет по такой схеме). Все связи между SSO-службами добавляются и удаляются только вручную.
Попутно узнал, что рекомендуемая топология — c центральным PSC.
А теперь к хорошим новостям: забудьте все, что только что прочитали 🙂
Начиная с vCenter 6.7 рекомендуемой топологией является встроенный PSC для любой топологии. Вы даже можете сделать vCenter HA (vCenter High Availability) для встроенного PSC, если хотите его защитить.
Ну и к вопросу резервной копии — в v6.7 появился ручной File-Based Backup, позволяющий сделать бэкап системы vCenter+PSC, восстанавливаемой с нуля с помощью этих файлов.
А в v6.7 Update 1 — возможность запуска бэкапа по расписанию.
В общем, администрирование нескольких vCenter-серверов в v6.7 стало значительно легче.
Platform Services Controller includes the following core infrastructure services.
| Service | Description |
|---|---|
| applmgmt |
(VMware Appliance Management Service)
(VMware License Service)
The license service inventory replicates across all Platform Services Controller in the domain at 30-second intervals.
(VMware Security Token Service)
(VMware HTTP Reverse Proxy)
(VMware Service Control Agent)
(VMware Appliance Monitoring Service)
(VMware vAPI Endpoint)
VMware Authentication Framework
VMware Certificate Service
VMware Certificate Service uses the VMware Endpoint Certificate Store (VECS) to serve as a local repository for certificates on every Platform Services Controller instance. Although you can decide not to use VMCA and instead can use custom certificates, you must add the certificates to VECS.
VMware Directory Service
If your domain contains more than one Platform Services Controller instance, an update of vmdir content in one vmdir instance is propagated to all other instances of vmdir.
VMware Domain Name Service
VMware Lifecycle Manager API
VMware Service Lifecycle Manager
Likewise Service Manager
VMware Platform Services Controller Health Monitor
VMware vCenter and PSC topologies
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.
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:
– Secure Token Service (STS)
– Identity Management Service (IdM)
– Directory Service (VMDir)
– 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:
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:
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:
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:
For more information about the differences between ELM and HLM see:
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:
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:
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:
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:
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:
VMware Platform Services Controller (PSC)
VMware Platform Services Controller (PSC) is a new service in vSphere 6 that handles the infrastructure security functions such as vCenter Single Sign-On, licensing, certificate management and server reservation.
PSC provides one appliance- or Windows-based virtual machine platform to systems administrators for centralized management of these common infrastructure services.
PSC is a distributed service that automatically replicates information such as licenses, permissions and roles to other PSC instances. The maximum number of PSCs per vSphere domain is set at eight. High-availability for PSCs is achieved through local load-balancing technologies, though only four PSCs can reside behind a load balancer. PSCs are also latency sensitive and can only tolerate up to five minutes of time skew between PSC nodes.
In vSphere 6, the following components are installed in PSC:
Related Terms
IR35 private sector reforms: HMRC under fire over ‘omission’ of employers’ NI from webinar guidance
IR35 private sector reforms: IBM joins list of enterprises applying blanket ban to PSCs
VMware HCX improves VM mobility between vSphere clusters
Tanzu integration and vSphere VM Service lets developers and admins spin up VMs and guest OSes as desired-state images in vSphere.
The cloud can help improve an app’s performance and cost, but businesses need to plan for success. Follow these best practices to.