vCenter and PSC (Platform Services Controller) considerations

With the introduction of vSphere 5.0, VMware released an appliance based virtual centre with an aim at reducing the deployment time and easing the support burden for the infrastructure and support teams. In the previous release, there was a disparity between the amount (VM’s and Hosts) the appliance and the windows deployment could support. With vSphere 6.x release, the difference between an appliance deployment and an installed based on Windows is minimal. The main focus resides on the database the installation support.

As in figure 4, the database support offers any challenge for the appliance-based deployment, specifically, if the deployment is based using vPostgress, there are some complexity’s around the data and the method of backing it up (for the clarity of this ASD Oracle has not been considered due to expense and support challenges). The details the backup procedure can be located at VMware KB 2091961.]

 

VC1

 

There have been some changes to the vCenter deployment options since the 5.x release. VMware has consolidated components into two separate installs; this is detailed in figure 6, the consolidation reduces the critical need for the Virtual Center instance to be 100% available. The focus of the availability moves to the data and the PCS.

Platform Services Controller

With vSphere 6.0 introduced, new service called Platform Services Controller (PSC) was introduced. The PSC can be deployed as either a Windows Server or an Appliance.

PSC has the following components

  • VMware Appliance Management Service
  • VMware Authentication Framework
  • VMware Certificate Service
  • VMware Common Logging Service
  • VMware Component Manager
  • VMware Directory Service
  • VMware HTTP Reverse Proxy
  • VMware Identity Management Service
  • VMware License Service
  • VMware Security Token Service
  • VMware Service Control Agent
  • VMware Syslog Health Service

Multi-master Architecture and Replication

PSC1

As in 5.5 SSO, PSCs in 6.0 use the same multi-master architecture. This means that it is possible to have several PSCs in an environment all automatically replicating with a partner node (figure 6). All of the nodes are master nodes, unlike in SSO 5.1 where there was a primary node and multiple secondaries (master-slave). The default replication interval between PSCs is 30 seconds and is latency sensitive.

 

PSC High Availability

PSC2

The PSC service can be installed in a High Availability (HA) mode to ensure that it doesn’t hit this type of problem. The PSC can be fronted by a load balancer

Another possibility is using Fault Tolerance (FT). Fault Tolerance is vSphere 6.0 now supports up to 4 vCPUs, so this can provide continuous availability if needed. This was considered, but the load balanced option was considered the better choice.

PSC Backups and Recoverability

Backup of the PSC should regularly happen. Please see the following article on “VMware KB 2110294” This article provides all of the supported techniques for backing up and restoring single external PSCs and multiple PSCs including:

  • Backup
  • Recovering from a single failed vCenter Server
  • Recovering from a single failed Platform Services Controller
  • Recovering from a single failed vCenter Server
  • Recovering when all Platform Services Controllers fail
  • Recovering from a single failed Platform Services Controller behind a load balancer

You may also like...

Leave a Reply

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