View Composer: Standalone or Co-Located with vCenter
The View Composer services which are responsible for provisioning, recomposing, rebalancing and refreshing linked clone desktops can be set up either as either a standalone machine or co-located with vCenter.
Option 1 – Co-Located Composer
Advantages:
- This traditionally was the only option before View 5.1 was released. The ability to support standalone install was introduced to provide support for the VCSA.
- Ensures that the all provisioning services reside on a single server; all provisioning services will be started together after the server is restarted
- Reduced chance of a network/firewall problems between vCenter and Composer
Drawbacks:
- Resources must be adjusted for the both services by the entire virtual machine
- Not an option when utilizing the VCSA
Option 2 – Standalone Composer
Advantages:
- Dedicated resources for each can be adjusted individually for each service
- Required when utilizing the VCSA
Drawbacks:
- Services are located on multiple machines, which means there is an increased chance that a network or firewall problem may cause an issue
- Requires a separate virtual machine which overall increases management overhead for the environment
View Composer Cautions regardless of design choice:
- Each View Composer instance and associated vCenter must be a 1:1 mapping
- Ensure that the vCenter and/or vCenter and composer servers have enough resources per the documentation to perform their respective roles (see links in sources below for details)
- It is recommended that all SQL databases be run on a separate machine
| Design Quality | Co-Located | Standalone | Comments |
| Availability | o | o | The availability of each of these solutions is tied directly to the availability of the management cluster; all of them depend on vSphere HA to be restarted in the event of a failure of host. |
| Manageability | ↑ | ↓ | Placing the composer on a standalone server increases the management overhead. |
| Performance | o | ↑ | In a standalone configuration, the performance of the virtual machines is correlated with each service’s performance characteristics, rather than a single VM. Important: this design decision does NOT impact performance of virtual desktops, rather it is merely the isolation of server resources that is in question. |
| Recoverability | ↑ | o | In the event that SRM is utilized to failover the management cluster, having a co-located instance drastically simplifies recovery. |
| Security | o | o | None of the options have a positive or negative impact on securability as both options can utilize either SQL or Integrated authentication for the database. |
Legend: ↑ = positive impact on quality; ↓ = negative impact on quality; o = no impact on quality.
Recommendation
Real world consulting experience has shown me that a 4 vCPU 16GB vCenter 5.5 with View Composer co-located can manage a full 2000 powered on linked clone virtual machines as well as a management cluster. Once scaling beyond 2000 linked clone desktops, you need to take into consideration the recompose time, which is not limited by actions initiated by View composer, but rather by the vCenter and ESXi limited concurrent queue of operations (See fig. 1 below). I do not recommend allowing a single linked clone block to go above 2000 desktops.
Typically View Composer does not consume a large amount of CPU and Memory resources and the database should not grow beyond 5GB. If there is a requirement to use the VCSA, standalone is your only choice. If VCSA is not a requirement, I typically recommend co-located for increased simplicity and reduced management overhead. Both are fully supported configurations, but considering that View Composer is not a resource intensive service and I prefer simplicity wherever possible in my designs, I typically prefer co-located even for large scale designs.
Sources
Horizon View 6.0 – vCenter Server and View Composer Virtual Machine Configuration
Horizon View 5.3 – vCenter Server and View Composer Virtual Machine Configuration
Fig. 1. Concurrent Operations with Linked Clone Desktops
This figure is from VMworld 2012 EUC1470 – “Demystifying Large Scale Enterprise View Architecture: Illustrated with
Lighthouse Case Studies”, by Lebin Cheng, VMware, Inc, and John Dodge, VMware, Inc.
elgwhoppo's vNotebook 