Determining the resources required to host the Horizon View infrastructure is straightforward for the Horizon View and vCenter Servers but far more involved for vSphere servers that will host the virtual desktops. This recipe will focus primarily on determining virtual desktop resource requirements.
The infrastructure resource requirements for VMware Horizon View can be broken down into two primary sections:
Resources required by the virtual desktop itself, including compute, networking, and storage. This can vary based on the user workload, applications being used, and any other factors that distinguish one user from the next.
The network bandwidth required for each Horizon View client connection; this will vary based on the workload profile of each client.
In this recipe, we review methods for measuring or determining what infrastructure resources we need for each of these items.
One of the preferred methods to determine virtual desktop resource requirements is to use a commercial tool such as Liquidware Labs Stratusphere FIT (http://www.liquidwarelabs.com/products/stratusphere-fit). Stratusphere FIT can generate detailed reports concerning the compute resources required by each of the virtual desktops in our organization. This information can be used to determine the desktop resource requirements with a very high degree of precision.
For organizations that cannot justify the expense of Stratusphere FIT, and feel that a simpler approach to desktop resource utilization is sufficient, the Windows Performance Monitor tool can be used to measure the resource utilization of their virtual desktops.
Note
While the Performance Monitor tool provides a useful insight into resource utilization, it cannot compare with commercial tools such as Stratusphere FIT. Given how important it is to accurately determine our Horizon View infrastructure requirements, we should consider using the best tools at our disposal in order to gather current desktop resource requirements.
When using Performance Monitor, the desktop should be measured during a period of normal use, and the data being measured should be saved into the comma-separated format in order to make it easier to analyze. This section will detail each of the counters that should be monitored using the Performance Monitor tool.
Note
Due to differences in hardware and software configurations, Windows resource names will vary slightly from one system to the next. The performance monitor counter names provided in this section are just examples; when using the performance monitor, select the appropriate counter based on the target resource you wish to monitor. Ensure that you are monitoring the active resources, as a system might have some unused devices, such as hard disks or network adapters.
This Windows counter represents the total network throughput of the specified desktop network adapter. The average of this value will help us calculate the network requirements of each virtual desktop on the vSphere Server. For Windows 7 and newer OSes, this counter is displayed as Network Adapter\Bytes Total/sec–Network Adapter in Windows Performance Monitor.
To determine the number of desktops a vSphere Server can host based on the information gathered, we use the following calculation:
Network: The total server network bandwidth in MB/network total MB per second of reference desktop
Read/write bytes per second—the disk read and writes bytes of a desktop provide us with a starting point for sizing the storage network connection that will connect the vSphere hosts to the storage infrastructure. These counters are displayed as PhysicalDisk\Disk Read Bytes/sec – 0 C: and PhysicalDisk\Disk Write Bytes/sec – 0 C: in Windows Performance Monitor.
To determine the number of desktops a vSphere server can host based on the information gathered, we can use the following calculation:
Storage network: The total server storage network bandwidth in MB (disk read MB per second + disk write MB per second) of the reference desktop
Reads/writes per second—the number of disk reads and writes on a desktop provide us a with starting point for sizing the virtual desktop storage platform. The storage design is impacted not only by the total amount of disk input/output (I/O), but also by the ratio of reads to writes. These counters are displayed as PhysicalDisk\Disk Reads/sec – 0 C: and PhysicalDisk\Disk Writes/sec – 0 C: in Windows Performance Monitor. These values can also be referred to as either read or write I/O Operations per Second (IOPS).
To determine the number of desktops a vSphere Server can host based on the information gathered, we use the following calculation:
(Disk Reads per second + Disk Writes per second) * Total number of desktops = Total IOPS required by the virtual desktop storage solution
Note
Regardless of which storage protocol our vSphere hosts will use, there will be some overhead involved. After you have measured your baseline disk bandwidth (disk read or write megabytes per second) or IO (disk reads or writes per second) from your reference desktop, add 15 percent to the value recorded prior to calculating your overall resource requirements.
This counter measures the percentage of time for which the processor was busy. The average of this value will impact the number of virtual desktop processors we can host per vSphere Server CPU core. This counter is displayed as Processor\% Processor Time - _Total in Windows Performance Monitor.
To determine the number of desktops a vSphere Server can host based on the information gathered, we can use the following calculation:
This counter represents the total number of bytes allocated by Windows processes, including any that were paged to physical disk. The average of this value will help us calculate how much memory should be allocated to the virtual desktop master image and, by extension, how much memory will be required in each virtual desktop vSphere host. This counter is displayed as Memory\Committed Bytes in Windows Performance Monitor.
To determine the number of desktops a vSphere server can host based on the information gathered, we can use the following calculation:
Memory: Total server memory in MB / (memory committed MB per second of reference desktop * 1.25)
Note
The
1.25multiplier is used in this calculation to grant the desktop additional memory and reduce the likelihood that the Windows swap file will be utilized. In most cases, when a desktop is forced to use the swap file, a decrease in performance will occur as well as an increase in the amount of IO it generates, which is why the additional memory is important.
One of the easiest things to overlook when designing our Horizon View infrastructure is how much network bandwidth is required in order to support the client connections. The preferred protocol for Horizon View is PCoIP, although it also supports VMware HTML Access as well as Microsoft Remote Desktop Protocol (RDP).
PCoIP is a display protocol provided by VMware for use in the Horizon View product suite. The PCoIP protocol has multiple features that make it ideal for connecting to Horizon View desktops or streamed applications:
It's capable of adapting to varying levels of connection latency and bandwidth
It has multiple built-in techniques for optimizing and accelerating connections over a WAN
It is able to achieve compression ratios of up to 100:1 for images and audio
It uses multiple codecs that enable more efficient encoding and decoding of content between the virtual desktop and the remote client
It is based on User Datagram Protocol (UDP), which eliminates the need for latency-inducing handshakes used in display protocols based on Transmission Control Protocol (TCP)
Microsoft RDP is a TCP-based display protocol that lacks many of the WAN optimization and acceleration techniques that are found in PCoIP. In addition, VMware Horizon View includes Microsoft Group Policy Object (GPO) templates that enable a very granular control over PCoIP connection characteristics. The Horizon View document Setting up Desktop and Application Pools in View (https://pubs.vmware.com/horizon-view-60/index.jsp#com.vmware.horizon-view.desktops.doc/GUID-D90CC716-6CDA-4210-8AF2-9E75C729D847.html) provides us with details on how to use the PCoIP GPO templates.
The VMware Horizon View Architecture Planning guide (https://pubs.vmware.com/horizon-view-60/index.jsp#com.vmware.horizon-view.planning.doc/GUID-5CC0B95F-7B92-4C60-A2F2-B932FB425F0C.html) provides us with estimates for the PCoIP bandwidth utilization based on the application workload of the client. The following table is built upon this information:
|
User type |
Workload characteristics |
Bandwidth in Kbps |
|---|---|---|
|
Task Worker |
2D display and single monitor. Web and limited Office applications. Horizon View desktop and PCoIP settings optimized. |
50–100 Kbps |
|
Task Worker |
2D display and single monitor. Web and limited Office applications. Horizon View desktop and PCoIP settings not optimized. |
100–150 Kbps |
|
Knowledge Worker (3D) |
3D display (Windows Aero) and multiple monitors. Office applications. |
400–600 Kbps |
|
Knowledge worker (3D): heavy video |
3D display (Windows Aero) and multiple monitors. Office applications. Frequent bursts of large display changes and other imaging traffic. |
500 Kbps–1 Mbps |
|
Power user |
3D display (Windows Aero) and multiple monitors. 480P video and images with frequent screen changes. |
2 Mbps |
Bandwidth utilization is heavily dependent on a number of factors, many of which can be controlled with the Horizon View PCoIP GPO settings or even Windows virtual desktops settings.
Even with a careful analysis of user desktop usage patterns, it is important to remember that there will be spikes in usage from time to time. A knowledge or task worker that has a need to use an application with a large amount of screen changes, such as viewing images in succession or watching a video, might cause a brief bandwidth spike between 500 Kbps and 1 Mbps or more, referenced as a Heavy Video user in the table. Preparing for these spikes in bandwidth utilization is important in order to preserve the quality of service for all of the Horizon View client connections.