View deployments can use VMware HA clusters to guard against physical server failures. Depending on your setup, clusters can contain up to 32 nodes.

vSphere and vCenter Server provide a rich set of features for managing clusters of servers that host virtual machine desktops. The cluster configuration is also important because each virtual machine desktop pool must be associated with a vCenter Server resource pool. Therefore, the maximum number of desktops per pool is related to the number of servers and virtual machines that you plan to run per cluster.

In very large View deployments, vCenter Server performance and responsiveness can be improved by having only one cluster object per datacenter object, which is not the default behavior. By default, vCenter Server creates new clusters within the same datacenter object.

Under the following conditions, vSphere clusters can contain up to 32 ESXi hosts, or nodes:

vSphere 5.1 and later, with View Composer linked-clone pools, and store replica disks on NFS datastores or VMFS5 or later datastores

vSphere 6.0 and later, and store pools on Virtual Volumes datastores

If you have vSphere 5.5 Update 1 and later, and store pools on Virtual SAN datastores, the vSphere clusters can contain up to 20 ESXi hosts.

If you store View Composer replicas on a VMFS version earlier than VMFS5, a cluster can have at most eight hosts. OS disks and persistent disks can be stored on NFS or VMFS datastores.

For more information, see the chapter about creating desktop pools, in the Setting Up Desktop and Application Pools in View. Networking requirements depend on the type of server, the number of network adapters, and the way in which VMotion is configured.

vSphere, through its efficiency and resource management, lets you achieve industry-leading levels of virtual machines per server. But achieving a higher density of virtual machines per server means that more users are affected if a server fails.

Requirements for high availability can differ substantially based on the purpose of the desktop pool. For example, a stateless desktop image (floating-assignment) pool might have different recovery point objective (RPO) requirements than a stateful desktop image (dedicated-assignment) pool. For a floating-assignment pool, an acceptable solution might be to have users log in to a different desktop if the desktop they are using becomes unavailable.

In cases where availability requirements are high, proper configuration of VMware HA is essential. If you use VMware HA and are planning for a fixed number of desktops per server, run each server at a reduced capacity. If a server fails, the capacity of desktops per server is not exceeded when the desktops are restarted on a different host.

For example, in an 8-host cluster, where each host is capable of running 128 desktops, and the goal is to tolerate a single server failure, make sure that no more than 128 * (8 - 1) = 896 desktops are running on that cluster. You can also use VMware DRS (Distributed Resource Scheduler) to help balance the desktops among all 8 hosts. You get full use of the extra server capacity without letting any hot-spare resources sit idle. Additionally, DRS can help rebalance the cluster after a failed server is restored to service.

You must also make sure that storage is properly configured to support the I/O load that results from many virtual machines restarting at once in response to a server failure. Storage IOPS has the most effect on how quickly desktops recover from a server failure.

The settings listed in the following tables are View-specific. For information about limits of HA clusters in vSphere, see the VMware vSphere Configuration Maximums document.

Note

The following infrastructure example was tested with View 5.2 and vSphere 5.1. The example uses View Composer linked-clones, rather than instant clones, because the test was performed with View 5.2. The instant clone feature is introduced with Horizon 7. Other features that were not available with View 5.2 include Virtual SAN and Virtual Volumes.

View Infrastructure Cluster Example

Item

Example

Virtual machines

vCenter Server instances, Active Directory, SQL database server, View Composer, View Connection Server instances, security servers, parent virtual machines to use as desktop pool sources

Nodes (ESXi hosts)

6 Dell PowerEdge R720 servers (16 cores * 2 GHz; and 192GB RAM on each host)

SSD storage

Virtual machines for vCenter Server, View Composer, SQL database server, and the parent virtual machines

Non-SSD storage

Virtual machines for Active Directory, View Connection Server, and security server

Cluster type

DRS (Distributed Resource Scheduler)/HA

Virtual Machine Desktop Cluster Example

Item

Example

Number of clusters

5

Number of desktops and pools per cluster

1 pool of 2,000 desktops (virtual machines) per cluster

Nodes (ESXi hosts)

Following are examples of various servers that could be used for each cluster:

12 Dell PowerEdge R720 (16 cores * 2 GHz; and 192GB RAM on each host)

16 Dell PowerEdge R710 (12 cores * 2.526 GHz; and 144GB RAM on each host)

8 Dell PowerEdge R810 (24 cores * 2 GHz; and 256GB RAM on each host)

6 Dell PowerEdge R810 + 3 PowerEdge R720

SSD storage

Replica virtual machines

Non-SSD storage

32 Non-SSD datastores for clones (450 GB per datastore)

Cluster type

DRS (Distributed Resource Scheduler)/HA