Before you attempt to manage many virtual machines with a single vCenter Server instance, you must take the following considerations into account.
- Duration of your company's maintenance windows
- Capacity for tolerating VMware Horizon component failures
- Frequency of power, provisioning, and refit operations
- Simplicity of infrastructure
Duration of Maintenance Windows
Concurrency settings for virtual machine power, provisioning, and maintenance operations are determined per vCenter Server instance.
| Pod designs with one vCenter Server instance | Concurrency settings determine how many operations can be queued up for an entire Horizon pod at one time. For example, if you set concurrent provisioning operations to 20 and you have only one vCenter Server instance in a pod, a desktop pool larger than 20 will cause provisioning operations to be serialized. After queuing 20 concurrent operations simultaneously, one operation must complete before the next begins. In large-scale VMware Horizon deployments, this provisioning operation can take a long time. |
| Pod designs with multiple vCenter Server instances | Each instance can provision 20 virtual machines concurrently. |
To ensure more operations are completed simultaneously within one maintenance window, you can add multiple vCenter Server instances (up to five) to your pod, and deploy multiple desktop pools in vSphere clusters managed by separate vCenter Server instances. A vSphere cluster can be managed by only one vCenter Server instance at one time. To achieve concurrency across vCenter Server instances, you must deploy your desktop pools accordingly.
Capacity for Tolerating Component Failures
The role of vCenter Server in Horizon pods is to provide power, provisioning, and refit (refresh, recompose, and rebalance) operations. After a virtual machine desktop is deployed and powered on, VMware Horizon does not rely on vCenter Server for the normal course of operations.
Because each vSphere cluster must be managed by a single vCenter Server instance, this server represents a single point of failure in every VMware Horizon design.
In addition to these automated options for vCenter Server failover, you can also choose to rebuild the failed server on a new virtual machine or physical server. Most key information is stored in the vCenter Server database.
Risk tolerance is an important factor in determining whether to use one or multiple vCenter Server instances in your pod design. If your operations require the ability to perform desktop management tasks such as power and refit of all desktops simultaneously, you should spread the impact of an outage across fewer desktops at a time by deploying multiple vCenter Server instances. If you can tolerate your desktop environment being unavailable for management or provisioning operations for a long period, or if you choose to use a manual rebuild process, you can deploy a single vCenter Server instance for your pod.
Frequency of Power, Provisioning, and Refit Operations
Certain virtual machine desktop power, provisioning, and refit operations are initiated only by administrator actions, are usually predictable and controllable, and can be confined to established maintenance windows. Other virtual machine desktop power and refit operations are triggered by user behavior, such as using the Refresh on Logoff or Suspend on Logoff settings, or by scripted action, such as using Distributed Power Management (DPM) during windows of user inactivity to power off idle ESXi hosts.
If your VMware Horizon design does not require user-triggered power and refit operations, a single vCenter Server instance can probably suit your needs. Without a high frequency of user-triggered power and refit operations, no long queue of operations can accumulate that might cause Horizon Connection Server to time-out waiting for vCenter Server to complete the requested operations within the defined concurrency setting limits.
Many customers elect to deploy floating pools and use the Refresh on Logoff setting to consistently deliver desktops that are free of stale data from previous sessions. Examples of stale data include unclaimed memory pages in pagefile.sys or Windows temp files. Floating pools can also minimize the impact of malware by frequently resetting desktops to a known clean state.
Some customers are reducing electricity usage by configuring VMware Horizon to power off desktops not in use so that vSphere DRS (Distributed Resources Scheduler) can consolidate the running virtual machines onto a minimum number of ESXi hosts. VMware Distributed Power Management then powers off the idle hosts. In scenarios such as these, multiple vCenter Server instances can better accommodate the higher frequency of power and refit operations required to avoid operations time-outs.
Simplicity of Infrastructure
A single vCenter Server instance in a large-scale VMware Horizon design offers some compelling benefits, such as a single place to manage golden image virtual machines, a single vCenter Server view to match the Horizon Console view, and fewer production back-end databases and database servers. Disaster Recovery planning is simpler for one vCenter Server than it is for multiple instances. Make sure you weigh the advantages of multiple vCenter Server instances, such as duration of maintenance windows and frequency of power and refit operations, against the disadvantages, such as the additional administrative overhead of managing golden image virtual machine images and the increased number of infrastructure components required.
Your design might benefit from a hybrid approach. You can choose to have very large and relatively static pools managed by one vCenter Server instance and have several smaller, more dynamic desktop pools managed by multiple vCenter Server instances. The best strategy for upgrading existing large-scale pods is to first upgrade the VMware software components of your existing pod. Before changing your pod design, gauge the impact of the improvements of the latest version's power, provisioning, and refit operations, and later experiment with increasing the size of your desktop pools to find the right balance of more large desktop pools on fewer vCenter Server instances.
