This post is also available in: Italian
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:
- Deploy in virtual or virtual or physical?
- Use the appliance or the installable version ?(in this case on which Windows Server?)
- How increase the availability of vCenter and it’s services?
- Using a single system with all the vCenter components or multiple systems?
- Using and external DMBS or a local one? (in this case, use an embedded one?)
- What about DNS and AD and other dependencies?
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)
- 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:
If 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 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.
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
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)
The 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).