Home > Blogs > VMware Consulting Blog

vSphere Datacenter Design – vCenter Architecture Changes in vSphere 6.0 – Part 2

jonathanm-profileBy Jonathan McDonald

In Part 1 the different deployment modes for vCenter and Enhanced Linked Mode were discussed. In part 2 we finish this discussion by addressing different platforms, high availability and recommended deployment configurations for vCenter.

Mixed Platforms

Prior to vSphere 6.0, there was no interoperability between vCenter for Windows and the vCenter Server Linux Appliance. After a platform was chosen, a full reinstall would be required to change to the other platform. The vCenter Appliance was also limited in features and functionality.

With vSphere 6.0, they are functionally the same, and all features are available in either deployment mode. With Enhanced Linked Mode both versions of vCenter are interchangeable. This allows you to mix vCenter for Windows and vCenter Server Appliance configurations.

The following is an example of a mixed platform environment:

JMcDonald pt 2 (1)

This mixed platform environment provides flexibility that has never been possible with the vCenter Platform.

As with any environment, the way it is configured is based on the size of the environment (including expected growth) and the need for high availability. These factors will generally dictate the best configuration for the Platform Services Controller (PSC).

High Availability

Providing high availability protection to the Platform Services Controller adds an additional level of overhead to the configuration. When using an embedded Platform Services Controller, protection is provided in the same way that vCenter is protected, as it is all a part of the same system.

Availability of vCenter is critical due to the number of solutions requiring continuous connectivity, as well as to ensure the environment can be managed at all times. Whether it is a standalone vCenter Server, or embedded with the Platform Services Controller, it should run in a highly available configuration to avoid extended periods of downtime.

Several methods can be used to provide higher availability for the vCenter Server system. The decision depends on whether maximum downtime can be tolerated, failover automation is required, and if budget is available for software components.

The following table lists methods available for protecting the vCenter Server system and the vCenter Server Appliance when running in embedded mode.

Redundancy Method Protects
vCenter Server system?
vCenter Server Appliance?
Automated protection using vSphere HA Yes Yes
Manual configuration and manual failover, for example, using a cold standby. Yes Yes
Automated protection using Microsoft Clustering Services (MSCS) Yes No

If high availability is required for an external Platform Services Controller, protection is provided by adding a secondary backup Platform Services Controller, and placing them both behind a load balancer.

The load balancer must support Multiple TCP Port Balancing, HTTPS Load Balancing, and Sticky Sessions.  VMware has currently tested several load balancers including F5 and Netscaler, however does not directly support these products. See the vendor documentation regarding configuration details for any load balancer used.

Here is an example of this configuration using a primary and a backup node.

JMcDonald pt 2 (2)

With vCenter 6.0, connectivity to the Platform Services Controller is stateful, and the load balancer is only used for its failover ability. So active-active connectivity is not recommended for both nodes at the same time, or you risk corruption of the data between nodes.

Note: Although it is possible to have more than one backup node, it is normally a waste of resources and adds a level of complexity to the configuration for little gain. Unless there is an expectation that more than a single node could fail at the same time, there is very little benefit to configuring a tertiary backup node.

Scalability Limitations

Prior to deciding the configuration for vCenter, the following are the scalability limitations for the different configurations. These can have an impact on the end design.

Scalability Maximum
Number of Platform Services Controllers per domain


Maximum PSCs per vSphere Site, behind a single load balancer


Maximum objects within a vSphere domain (Users, groups, solution users)


Maximum number of VMware solutions connected to a single PSC


Maximum number of VMware products/solutions per vSphere domain


Deployment Recommendations

Now that you understand the basic configuration details for vCenter and the Platform Services Controller, you can put it all together in an architecture design. The choice of a deployment architecture can be a complex task depending on the size of the environment.

The following are some recommendations for deployment. But please note that VMware recommends virtualizing all the vCenter components because you gain the benefits of vSphere features such as VMware HA. These recommendations are provided for virtualized systems; physical systems need to be protected appropriately.

  • For sites that will not use Enhanced Linked Mode, use an embedded Platform Services Controller.
    • This provides simplicity in the environment, including a single pane-of-glass view of all servers while at the same time reducing the administrative overhead of configuring the environment for availability.
    • High availability is provided by VMware HA. The failure domain is limited to a single vCenter Server, as there is no dependency on external component connectivity to the Platform Services Controller.
  • For sites that will use Enhanced Linked Mode use external Platform Service Controllers.
    • This configuration uses external Platform Services controllers and load balancers (recommended for high availability). The number of controllers depends on the size of the environment:
      • If there are two to four VMware solutions – You will only need a single Platform Services Controller if the configuration is not designed for high availability; two Platform Services Controllers will be required for high availability behind a single load balancer.
      • If there are four to eight VMware solutions – Two Platform Services Controllers must be linked together if the configuration is not designed for high availability; four will be required for a high-availability configuration behind two load balancers (two behind each load balancer).
      • If there are eight to ten VMware solutions – Three Platform Services Controllers should be linked together for a high-availability configuration; and six will be required for high availability configured behind three load balancers (two behind each load balancer).
    • High availability is provided by having multiple Platform Services Controllers and a load balancer to provide failure protection. In addition to this, all components are still protected by VMware HA. This will limit the failure implications of having a single Platform Services Controller, assuming they are running on different ESXi hosts.

With these deployment recommendations hopefully the process of choosing a design for vCenter and the Platform Services Controller will be dramatically simplified.

This concludes this blog series. I hope this information has been useful and that it demystifies the new vCenter architecture.


Jonathan McDonald is a Technical Solutions Architect for the Professional Services Engineering team. He currently specializes in developing architecture designs for core Virtualization, and Software-Defined Storage, as well as providing best practices for upgrading and health checks for vSphere environments.

13 thoughts on “vSphere Datacenter Design – vCenter Architecture Changes in vSphere 6.0 – Part 2

  1. David

    What do you mean with a maximum number of VMware products/solutions. We have 10 Virtual Centers, 10 SRM servers and also 2 servers for VRealize Operations manager. Is this 22 solutions or 3 solutions?
    And what happens when you go over the limit?

    1. Jonathan McDonald


      From my understanding a ‘solution’ means if something is connected directly into Single Sign-On, and has a solution user. Thus vCenter (and all of it’s components) is 1 solution in this context. Another example currently is vRealize Automation, which counts as 1 also a solution if connected in the environment. Also, as far as I am aware, currently these are the only two things that count as a solution, vRealize Operations Manager and Site Recovery Manager do not create solution users and therefore do not count towards this total.

      I will take an acton to see about getting details on this properly documented in our guides so that it is much more clear. The information in my post came directly from the maximums guide for vSphere 6.


      1. Juan Overstreet

        Jonathan; Good post considering we are talking bleeding edge.

        The question David posed of what constitutes a service is critical for scalability planning. Please add me to the list of interested parties. Reviewing the available information, and looking at the single Sign-on Solution users in small lab environment, reviewing users ang groups-> Solution Users lists items such as vpxd and webclient users. Also, reading the maximums and taking High Available requirements into account, it will be critical to get clarity on this.
        Looking forward to reply.

        1. Jonathan McDonald

          Hi All,

          The following is the official word on this:

          A VMware Solution is defined as a product that creates a Machine Account and one or more Solution User (a collection of vSphere services) within the VMware Directory Service when the product is joined to the PSC, thus the vSphere Domain. The Machine Account and Solution User(s) are used to broker and secure communication between other Solutions available within the vSphere environment. In order to count against these maximums, the Machine Account and Solution Users must be fully integrated with all of the PSC’s available feature sets (Identity Management and Authentication Brokering, Certificate Management, Licensing, etc.) such that the product makes full use of the PSC. At this time, only vCenter Server is defined as a fully integrated solution and counts against these maximums.

          Partially integrated solutions, such as vCenter Site Recovery Manager, vCloud Director vRrealize Orchestrator, vRealize Automation Center, and vRealize Operations, do not count against these defined maximums
          Currently this is documented in, http://kb.vmware.com/kb/2113115. We are going to hopefully have it added as a footnote to the maximums guide as well.


  2. Paul

    Can you have a multisite solution that uses two PSCs behind an F5 load balancer that spans site A and site B? If so what is the trade off between that and having 4 PSCs across the two sites with local F5 load balancing only?


    1. Jonathan McDonald

      Hi Paul,

      For Platform Services Controllers, currently the load balancer only is used for failover between nodes (basically an active / standby configuration). So technically speaking as long as you have network connectivity, it can be configured. The problem is that there is no active/active type connectivity between the nodes you can’t distribute load between the two sites, all data would be sent across the wire to the active node. This can result in issues if there is latency or a slow network or even if there is an issue between sites (vCenter that is remote would be down).

      I would definitely recommend for proper availability that the 4 nodes be used, two in each site configured in an HA pair. They will all still replicate data, but you will have proper locality for connectivity within the site, and the ability to withstand a failure both within the site, and between sites.


  3. Andrew

    Assume we have two sites:
    – The primary site with a PSC and Vcenter server,
    – and a warm DR site also with a PSC and Vcenter,
    – Both Vcenters are pointed at the PSC in the primary site for normal operation.

    Should the PSC at the primary site fail, is it correct that we can manually repoint all Vcenter(s) at the PSC in the secondary site, therefore not requiring a load balancer?

    Wouldn’t this provide a relatively simple method of failover assuming a short outage was acceptable, and with enhanced linked mode, provides full visibility over all vCenters during normal operations?


    1. JT Moree

      +1 for discussion of a DR site. Most articles and vmware docs seem to ignore this use case–focusing instead on data centers with multiple vcenter servers within each site. The recommendations for embedded psc vs external are vague when it comes to DR. I have less than 100 vms and 2 hosts at each site. It seems that I should use embedded pscs at primary and DR site but the docs say that any time I have more than 1 vcenter [ at a site?] i should use external psc.

  4. Pingback: Tips for vSphere Datacenter Design — Plus More Top Posts from VMware Professional Services | Toronto VMware User Group

  5. Pingback: Deploying vCenter Server 6 in Linked Mode | SDDC Online

Leave a Reply

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