This post is also available in: Italian

Reading Time: 8 minutes

The design of the VMware vCenter Server and related services has several decision that you have to take, and of course some of them will change with the version number of this products (for example SSO design are different from 5.1 and 5.5).

During the last Nordic VMUG User Conference I’ve taken a session about some the design aspects and I want to comment some of the aspects. There are also other references that you can use, like a post of Max Mortillaro (vCenter Server Design Considerations) that can add more information or other point of view.

Basically the main design decisions are:

In several cases, there are some simple answers: for example for the availability actually the only supported solution is the VMware HA (considering that VMware vCenter Heartbeat is no more avilable), but is not the only design decision… what about the DMBS part (if it is external)? As documented also in the VMware KB 1024051 (supported vCenter Server high availability options) starting from version 5.5 is possible have a clustered SQL back-end (KB 2059560) or also a Oracle RAC backend (KB 2002531).

Note that vCenter Server 5.5 U3 and 6.0 will support the clustering of the vCenter Server in addition to the backend database. More information will be available when those products will be released.

If you choose the appliance, some decisions are already done: you can only deploy in virtual, you have more limitations on the type of DBMS and which services and features can work with this type of vCenter, but you have also several advantages. For more information see my post (Installable vs. Appliance) or my last #vBrownbag Tech Talks.

About the infrastructure dependecies, the name or the IP cannot change (or at least not in a simple way) after you have installed the components, so the common way is working with FQDN and in this case you have configured both a forward and reverse lookup zone.

For the authentication, when you plan to authenticate against Active Directory, you have joined your Microsoft Windows server to the domain. But remember that also other identity sources are supported with 5.5:

  • Active Directory as an LDAP server (no more supported)
  • OpenLDAP
  • KB 2064977
  • Local OS
  • Local SSO

But the must interesting options and decisions are on how many system you can use and how. Considering that you have four main components (SSO, Web Client, Inventory Service, vCenter Server) you can install those different part on a single system or on multiple systems:


But this does not necessary sense in a real world, some components have to be in the same system. And some components may have multiple instances. Starting with vSphere 5.5 there are three main deployment scenarios: single system, multiple systems on a single site, multiple systems on multiple sites:


Single system

Design-vCenter-1If you plan to use a single system for all the vCenter components you can keep really simple the environment, but it will be limited in scaling. The DBMS could be local or external and depending on the size of your environments could be interesting keep it local or use the vCSA with the embedded DB (for small environments have a single “appliance” can simplify manageability and also the data protection and, of course, reduce the complexity). The simple install can also make this deployment fast (or at least simple), if you use the installable version.

This solution can support from 1 to 1000 Hosts and from 1 to 10,000 VMs, the only limit is when you use an embedded DB (on vCenter 5.x installable is SQL Express) where the limits become maximum 5 hosts or 50 VMs. Using the vCSA 5.5 with the embedded DB the limits has grow to 100 hosts or 3000 VMs (so again interesting numbers that can fit in almost SMB installations).

There is the good VMware KB 2052334 (Installing vCenter Server 5.5 best practices) with several hints on how deploy the vCenter.

For example the minimum hardware requirements for Simple Install deployment of vCenter Single Sign-On, the vSphere Web Client, vCenter Inventory Service, and vCenter Server are:

Host Hardware for Simple Install Deployment Minimum Requirement
Processor Intel or AMD x64 processor with two or more logical cores, each with a speed of 2GHz.
Memory 12GB.
Memory requirements are higher if the vCenter Server database runs on the same machine as vCenter Server.
vCenter Server includes several Java services: VMware VirtualCenter Management Webservices (tc Server), Inventory Service, and Profile-Driven Storage Service. When you install vCenter Server, you select the size of your vCenter Server inventory to allocate memory for these services. The inventory size determines the maximum JVM heap settings for the services. You can adjust this setting after the installation if the number of hosts in your environment changes. For more information, see the recommendations in JVM Heap settings for vCenter Server.
Disk storage 40-60GB of free disk space is required after the installation, depending on the size of your inventory. You should provide more space to allow for future growth of your inventory.
Disk storage requirements are higher if the vCenter Server database runs on the same machine as vCenter Server, depending on the size of those databases.
In vCenter Server 5.x, the default size for vCenter Server logs is 450MB larger than in vCenter Server 4.x. Make sure the disk space allotted to the log folder is sufficient for this increase.
Network speed 1Gbps
Please note the memory requirement, considering that in the installation guide is reported a 8 GB requirement (same of the vCSA), but you have to increase if you plan to have more services in a single system.

Multiple systems

There are different deployment scenarios according on how do you deploy the SSO part:

  • vCenter Single Sign-On for and additional vCenter in an existing site: Merges Lookup Services
  • vCenter Single Sign-On for and additional vCenter with a new site: Configures new Lookup Services – For multiple vCenter Server deployments

Design-vCenter-2 The single site scenario has a single SSO Server (usually with a local Web Client, in order to manage the SSO authentication back-end) and more vCenter Servers (each with the Inventory service).

The DBMS part could be one (logically) but with multiple DB, one of each vCenter Server. Usually linked mode is used to manage all those vCenter from a single client instance.

This solution could also be applied to a vCSA deployment (where you can have external SSO and DBMS), but in this case you cannot use the linked mode (because in version 5.x it’s not available in the appliance version).

To improve the availability of the SSO part, there is a HA configuration with two SSO and an external load balancer explained in the KB 2033588 (Configuring VMware vCenter Single Sign On for High Availability)

vCenter5-MultiSiteThe multi side scenario is new in version 5.5 and is based on the replication capabilities of SSO 5.5 where there is no need of an external DB and all the data could be replicated across multiple SSO.

So there is only a single SSO system only from a logical point of view, but in the reality each vCenter Server is a complete system with all the services inside it (except maybe the DMBS part, according with your design).


Virtualization, Cloud and Storage Architect. Tech Field delegate. VMUG IT Co-Founder and board member. VMware VMTN Moderator and vExpert 2010-24. Dell TechCenter Rockstar 2014-15. Microsoft MVP 2014-16. Veeam Vanguard 2015-23. Nutanix NTC 2014-20. Several certifications including: VCDX-DCV, VCP-DCV/DT/Cloud, VCAP-DCA/DCD/CIA/CID/DTA/DTD, MCSA, MCSE, MCITP, CCA, NPP.