VMware Horizon design overview

The primary focus of this book is to show you how to deploy and configure VMware Horizon. Ultimately, the deployment is only one part of a successful Horizon implementation. Determining the infrastructure requirements of your virtual desktops is critical to ensuring that all your hard work implementing Horizon won't ultimately be a disappointment because you failed to consider what your desktops actually need.

Some organizations that are virtualizing older desktops that lack flash drives, may feel that meeting their users' needs will be easy because expectations are low from the start. Of course, some organizations tend to forget that their users are probably using flash-based devices at home. This means that even with a poor computing experience at work, these users will have some expectation of what it is like when they get a new computer, which is what their new Horizon desktop will appear to be. So, even if your Horizon infrastructure is capable of providing performance that is similar to the computers that users have today, that does not mean it will provide an experience that the users will find acceptable.

The goal of this section is to provide some information that you need to consider before you buy your Horizon licenses. Buying those licenses is the easy part, assembling the infrastructure they will be built on, is not. Unfortunately, it isn't possible to put into words everything you need to know in order to build an infrastructure that guarantees a good performance for your users. Therefore, I have suggested a detailed analysis of the network and storage infrastructure that you intend to use with your Horizon infrastructure. This analysis, combined with an understanding of the resources your Horizon infrastructure will require, is integral to delivering a superior end user experience.

Measuring virtual desktop resource requirements

One of the most important aspects of any Horizon design is ensuring that an infrastructure has adequate compute, storage, and network resources to host the required number of virtual desktops. Were it not for troublesome things such as budgets, we could simply purchase an excess of all three of those resources and rest easy at night. In general, our goal is to build an infrastructure that is robust enough to support our average user workload, with some capacity in reserve for growth or maintenance purposes.

Determining the resource requirements of a Horizon environment is a complicated task, and one that could fill a book by itself. While it is possible to collect desktop performance data using free tools such as Windows Performance Monitor, gathering all of the data you need would be difficult, and interpreting it is even harder.

The goal in this section is to introduce you to some tools that were created specifically to help with designing and testing virtual desktop infrastructures so that you understand exactly what is required to ensure a successful implementation.

The following products can assist in determining your resource requirements and ensuring that your vSphere infrastructure has sufficient capacity and the performance capabilities needed to ensure the desktops perform as expected. These are as follows:

• Lakeside Software SysTrack (https://www.lakesidesoftware.com/solutions/desktop-transformation) performs an extensive analysis of your existing desktop workloads, including characterizing those that would be difficult to virtualize, and helps determine infrastructure needs and optimal placement.
• Liquidware Labs Stratusphere UX (http://www.liquidware.com/products/stratusphere-UX) can assist you in determining virtual desktop resource needs and performs tasks similar to Lakeside Software SysTrack.
• Login VSI (http://www.loginvsi.com/) has created tools that can be used to test the performance of your Horizon infrastructure. Login VSI is used to run a simulated user workload in as many desktops as you want to test the performance of all layers of your virtual desktop infrastructure.

It is important to note that these software packages are typically used as part of a virtual desktop assessment project led by an outside system integrator. If your user base has varying requirements, products such as SysTrack and Statusphere UX may be the only way to find out exactly what infrastructure resources you need to ensure a successful VMware Horizon deployment.

The need for vSphere reserve capacity

In the event that you choose to determine your own vSphere infrastructure requirements, it is very important to keep in mind the concept of vSphere reserve capacity. I realize that you may choose to do maintenance after hours, so reserve capacity may not be a priority, but what about unplanned downtime, or periods where you can't do maintenance after hours? Many users simply cannot work if they do not have access to their computer, and now that you have virtualized that computer, it is your job to ensure it is available whenever it is needed.

Maintaining reserve ESXi server capacity is critical to ensuring that we can accommodate all of our desktops in the event of an ESXi server failure or host maintenance operation. Consider a vSphere cluster with eight ESXi servers hosting 128 desktops each (1,024 total desktops):

• Desktop requirements:

Desktop requirements will vary from one environment to the next; these figures are just an example.

• • Each single vCPU desktop requires 10 percent of one ESXi server CPU core
  • Each desktop requires 2,048 MB of memory
• Eight ESXi servers, each running 12.5 percent of the total number of virtual desktops:
  • 1,024 desktops / 8 ESXi servers = 128 desktops per host
• To continue to run all of the desktops in the event one of the ESXi servers was to become unavailable; we would need to be able to accommodate 18.29 desktops on each of the remaining seven hosts:
  • 128 desktops / 7 remaining vSphere hosts = 18.29 desktops per each ESXi server
• To continue to run all desktops without any degradation in the quality of service; each server needs to have an excess of capacity that is sufficient to host 18 to 19 desktops. This is entails the following:
  • 19 desktops * 10% of a CPU core = 1.9 available CPU cores required
  • 19 desktops * 2,048 MB of memory = 38,912 MB or 38 GB of available memory required
  • 19 desktops * 121.21 MB of memory for virtual machine overhead = 2,303 MB or 2.3 GB of additional available memory required
  • 19 desktops * 0.75 MB network bandwidth = 14.25 MB of available network bandwidth required
  • 19 desktops * 0.23 MB storage network bandwidth = 4.37 MB of available storage network bandwidth required

These calculations assume that we want to protect the ability to provide resources for 100 percent of our desktops at all times, which is a very conservative, yet valid, approach to building a Horizon infrastructure.

The final configuration of the ESXi servers should take into account not only what percentage of desktops are actually in use at a given time, but also the cost of purchasing the additional capacity needed to support ESXi server failures or other events that require downtime.

Always take into consideration the growth of your Horizon environment. Purchasing equipment that has limited ability to scale may save money today, but could cost you dearly when you need to expand. If a piece of equipment you plan to buy for your Horizon infrastructure barely meets your needs, look into the next larger model or even a competing product, if necessary.

Providing sufficient Horizon Client bandwidth

In the era of affordable 10 Gigabit Ethernet (GbE) for servers and 1 GbE for desktops, I realize that bandwidth within a single site is typically not a concern. The following information is something to keep in mind for clients who are connecting to their Horizon desktop remotely, either from over the internet or over a WAN from another company site. Ensuring that sufficient bandwidth is available is just another part of making sure your Horizon clients have an acceptable experience when connecting to the Horizon infrastructure.

The VMware document Horizon 7 Architecture Planning (https://docs.vmware.com/en/VMware-Horizon-7/index.html) provides some information about how to determine Horizon Client bandwidth requirements. The following table is built upon information obtained from that document as well as other VMware documentation:

User type	Workload characteristics	Bandwidth in Kilobits per second (Kbps)
Basic office productivity desktop	2D display, typical office applications, no video, default Windows and Horizon 7 settings	100-150 Kbps
Optimized basic office productivity desktop	2D display, typical office applications, no video, optimized Windows and Horizon 7 settings	50-100 Kbps
Knowledge Worker (3D)	3D display (Windows Aero), multiple monitors, and office applications	400-600 Kbps
Knowledge Worker (3D) - High Change Rate	3D display (Windows Aero), multiple monitors, office applications, and frequent screen changes caused by basic video or similar	500 Kbps - 1 Megabits per second (Mbps)
Power User	3D display (Windows Aero), multiple monitors, 480P video, and frequent screen changes	2 Mbps

Bandwidth utilization is heavily dependent on a number of factors, many of which can be controlled with the Horizon PCoIP and Blast GPO settings. Additionally, Windows OS settings, such as display resolution and quality, can also affect bandwidth utilization. Actual bandwidth utilization will vary based on the client usage pattern, the protocol being used, and your GPO settings.

Refer to the VMware document Setting Up Application Pools in View (https://docs.vmware.com/en/VMware-Horizon-7/index.html) for information about the AD group policy templates included with VMware Horizon. The PCoIP protocol was invented by a company called Teradici. For additional information about how the protocol works, visit the Teradici PCoIP technology page (http://www.teradici.com/what-is-pcoip).

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 Worker or Task Worker who has a need to use an application with a large number of screen changes, such as viewing images in succession or watching a video, may cause a brief bandwidth spike of between 500 Kbps and 1 Mbps or more. Preparing for these spikes in bandwidth utilization is important in order to preserve the quality of service for all of the Horizon Client connections.

Refer to Chapter 10, Creating a Master Horizon Desktop Image, for information regarding optimal settings for a Windows desktop, an important topic for those new to virtualizing desktops.

The importance of a VMware Horizon pilot

Up until now, this chapter has been about introducing us to a variety of different concepts that form the basis of architecting our Horizon infrastructure. If we learn anything from this chapter, it is that our goal is to obtain the resources we need to provide an acceptable end user computing experience.

Classifying our end users and measuring their resource requirements is a valuable exercise that will help us understand what will be required to transition our end user computing resources from the desktop to the data center. That being said, no amount of planning can possibly replace a properly run pilot that validates not only the configuration of our master Virtual Desktop image, but also the performance of the Horizon infrastructure and the quality of the experience from an end user perspective.

Our Horizon pilot should involve the same types of users as our user analysis did, but not necessarily the same users within each group. The following list includes a number of goals that our Horizon pilot should attempt to achieve:

• Include multiple users from each user classification: Task Worker, Knowledge Worker, and Power User
• Include fully remote users, as well as WAN-connected users at other company sites
• Perform additional performance analysis at all layers of the Horizon infrastructure, including:
  • Storage
  • Network
  • ESXi server
  • Guest operating
• Measure the impact of common Horizon scenarios, such as:
  • User logon storms: Large numbers of users logging on within a short time frame
  • Steady-state user load: Measure Horizon infrastructure performance during a period of steady desktop usage by a significant number of users
  • Antivirus platform performance: Measure the impact of common antivirus platform tasks, such as on-demand scans and pattern file updates
  • Horizon refresh or recompose: Measure the impact of these common Horizon linked-clone desktop maintenance operations, described in detail in Chapter 9, Performing Horizon Desktop Pool Maintenance
  • A fully populated ESXi server: Measure host performance with higher than normal workloads, such as simulating an outage or another period of higher than usual utilization.

Performance is the key

Performance deficiencies at any layer of the Horizon infrastructure can lead to a poor end user experience, usually in the form of longer than anticipated application response times. This is why it is critical to involve a large cross-section of our users in the pilot process, and to seek their opinion throughout the program.

The performance data that we collect during the pilot program can be used to measure the average of the actual resource utilization, which can then be compared to the estimated average resource utilization from the initial physical desktop analysis. Ideally, the numbers would be rather close to one another, but if they are not, we will want to work to identify the cause. Now that we can measure performance at all layers of the Horizon infrastructure, it should be easy to determine where the higher than expected utilization originates from. Some potential issues to look for include the following:

• The earlier analysis of the users did not include a sufficient number or a wide enough cross-section of users.
• The Virtual Desktop master image was not properly optimized. Refer to Chapter 10, Creating a Master Horizon Desktop Image, for details on how to optimize the master desktop image.
• A component of the Horizon infrastructure was improperly configured. This problem can affect any number of components of the infrastructure.
• The pilot program is occurring during a period of higher than normal user workload, for example, a recurring event unique to the organization, such as financial reporting.

In summary, the Horizon pilot is your best time to learn about how it will perform within your environment, both from a performance perspective and in terms of user acceptance. Use the pilot program to identify any potential barriers to a successful rollout, and make any changes that are needed in order to minimize the risk of failure as the project moves forward.