VMware Horizon sizing guide for Windows 10 environments

Understanding the requirements for sizing a VMware Horizon environment

Before building and deploying a new VDI platform, it is important for you as a VDI admin to understand what kind of requirements you have for the new environment. You should answer the following questions before proceeding.

What is the number of users and what are their working patterns?

Are your users working in a call center from 8 a.m. to 6 p.m. each day, which would be a more fixed pattern where you have most of the workload using the service throughout the day? Or do you have a more distributed array of users?

What are the users' workloads and what applications what will they run?

What kind of applications and services will the users be accessing on the VDI platform? Do they only need Office 365 and a few other line-of-business applications, or do users need complicated and resource-intensive application portfolios? It is important to understand what kind of performance these applications require to run smoothly on the VDI platform. There are certain applications and services that may require specific hardware such as GPUs to fully function as well.

What kind of end-user experience do you want?

Do you intend to deploy purely single-session VDI desktops or a combination of multi-sessions and single-session VDI?  

There are other functional requirements such as networking and security, but these supporting services do not affect the overall platform in the same way the number of users, workloads and session types do. One final aspect to look at is storage. Most deployments will have Office 365 as part of the VDI session. Therefore, you should generally store user profiles on a shared location to ensure mobility across VDI desktops.

For the sake of this article, the following conditions exist for this example deployment:

• 500 knowledge users that require a combination of line-of-business applications and Office 365;
• most users run either single or multiple display monitors and have limited use of video memory-intensive applications;
• dispersed workforce coming from primarily home computers or corporate laptops;
• users running Windows 10 single-user instances;
• similar performance requirements across all users both in compute and storage performance;
• the environment is nonpersistent VDI;
• zero-trust based architecture treating all users as external connected users; and
• VMware vSAN as the underlying storage system. 

The nonpersistent VDI means that a user will always access a freshly-installed Windows desktop and use products such as Dynamic Environment Manager and FSLogix to handle user profiles, and App Volumes to handle application delivery.

Sizing the physical environment

With the parameters established, it's time to start sizing a new environment. First of all, you need to start with the underlying hardware, CPU and memory.  

A good rule of thumb for a VDI pilot is that you should start out with each virtual machine defined by using 1/8 per vCPU of a CPU core at minimum. Not all users are exactly equal; some might have more specific requirements for certain applications which may require more compute power or memory. For this article, you can use a 1/6 vCPU to pCPU core ratio and have a 2 vCPU, 8 GB memory baseline for Windows 10 machines on the Horizon VDI.

For a beefy Dell R740 server, which can come with up to 2x 28 Cores CPU, you can theoretically have up to 336 VDI instances on a single server.

With most VDI implementations today, memory is not the primary constraint. In most cases it is either CPU or IOPS for the underlying storage environment. The R740 can support up to 3 TB of physical memory, meaning there is plenty of memory available for the 336 VDI instances.

You must also consider the type of endpoint that will be connecting. This is where the Client Display Overhead comes into play; the display resolution and the number of monitors on the end-user side will affect the amount of overhead RAM required for configurations (figure 1).

For a dual display setup with users running 1080p, dual monitor setup will add about 25 MB of vRAM per virtual machine in addition to the base memory of the VM. This means if you calculate a baseline with 50% of users accessing multiple displays and 50% using single monitors with 1080p, you have an estimate of an additional 16 MB memory per user, which is 8 TB in total for 500 users.

VMware Horizon storage sizing

Next, you need to move into the storage layer and understand how many IOPS you should have for the VDI environment; this is where most issues occur that VDI deployments face. There is a lot of documentation from VMware -- and other vendors corresponding to their own products -- that includes information on how to calculate IOPS for a VDI environment.

You may want to transition from a three-tier SAN-based architecture to a hyperconverged platform running VMware vSAN. This will allow you to distribute the storage read/write input output (I/O) to each local compute node instead of having a back-end storage controller managing the data flow.

VMware offers different varieties of hyperconvergence, such as hybrid or all-flash deployments, but VMware's storage architecture provides sufficient performance and low latency I/O for VDI-based deployments.

VMware provides a file-based storage service which also reduces the need for file servers -- used to handle application and profile volumes. VMware recently introduced this service with vSAN 7, and enhanced support for small and medium businesses is available with v2.1 and on.

With VMware ESXi, you also have an option called View Storage Accelerator which comes enabled by default for Horizon pools. The accelerator caches common image blocks in ESXi server memory while reading virtual desktop images. It is especially useful for hybrid deployments where you have a combination of solid-state drive (SSD) and hard-disk drive storage because the cache can handle peak read workloads. The default size of this cache is 1,024 MB memory per ESXi instance, but you can configure it up to 2 GB. It's important to note that the cache size is fixed, regardless of the number of VMs.

VMware vSAN also has its own read cache that you can use. The VMs rely on the client cache of the host they are running on, but this read cache mechanism is compatible with the View storage accelerator cache. When the View cache accesses the data, the cache will serve a read and the request will never hit the vSAN layer. However, when there is a View cache miss, the system will check the vSAN client cache first before going to the disk. When doing the calculation, you have to factor in the vSAN client cache, which allocates 0.4% of host memory, up to 1 GB per ESXi host, in combination with the Horizon View storage cache, which is a total of 2 GB of memory per ESXi host.

Hyperconverged infrastructure will also allow for easier scalability if you need to expand the VDI deployment in the future, compared to a three-tier architecture. If you want to use vSAN, you'll need to consider the resources vSAN will take from each ESXi host to provide the vSAN service and the file service.

Take into consideration that you should have at least 10% CPU overhead for vSAN service, and vSAN requires a minimum of 32 GB per ESXi if you plan to use five disk groups with seven disks per disk group. This depends on the storage requirements and vSAN configuration, and the actual memory requirements will differ. You'll need to do a calculation for your own deployment. Secondly, the file service uses 4 vCPU and 4 GB of memory per host.

Final components of sizing a VMware Horizon environment

You'll also need to factor in the hardware requirements of the VMware Horizon View components. You should place these components outside of the current VDI desktop environment, but you still need to factor them into the sizing process (figure 2).

These components include the following:

• Connection center
• vCenter Server
• Horizon Cloud Connector
• Unified Access Gateway
• Enrollment server
• Workspace One access, used for SSO regardless of iDP

There are other internal components you'll need to account for that differ from environment to environment, such as database servers, file services, DHCP, DNS and Active Directory. They should have some form of load balancing in place to ensure availability of the central components.

Each of these services has its own requirements for CPU and memory. For example, Connection Center by default requires 10 GB of Memory and 4 vCPU per instance, and the Unified Access Gateway uses 4 GB of memory and 2 vCPU per instance.

If you plan to deploy this environment using VMware vSAN and combine it with file services, this will tap into the available vCPU and memory on each host and require the following resources:

• VMware Horizon View components: vCPU and Memory -- use 2x the resources for redundancy on a separate cluster;
• vSAN: between 16 GB and 32 GB memory on each host and 10% CPU overhead;
• vSAN Read Cache: 1 GB of host memory;
• Horizon View Storage Accelerator: 1 GB of host memory; and
• vSAN File Services: 4 vCPU and 4 GB memory on each ESXi host.

After you factor all this in, you'll be left with the remaining compute capacity available for the VDI environment. However, it's still important for you to have some spare capacity on the infrastructure for spikes in the workload.

Optimizing the virtual environment and the Windows OS 

When building and sizing a VMware Horizon VDI environment with Windows 10, it is important to understand that Windows 10 is still a generic operating system aimed at both consumers and enterprise users alike. It is also built for the OEM market, and therefore it requires a lot of tuning to ensure it runs properly in a VDI environment.  

Fortunately, there are a lot of ways you can optimize Windows 10. The first method is to use the VMware OS Optimization Tool for Windows 10, which can optimize the golden image to run on VDI. VMware says its technicians optimized Windows 10 using this tool, and the desktops showed a considerable improvement in performance -- around 30 percent -- after they optimized them with the tool. The tool disables unused services, removes Windows 10 Appx packages and performs other optimization changes.

There are also other tuning tips that you can follow to optimize the environment and improve the overall experience:

• Enable sleeping panes in Microsoft Edge. This reduces the browser's use of memory.
• Schedule antivirus and software updates to run at non-peak hours if you're using persistent VDI. If you're using nonpersistent VDI, disable software updates -- you'll update the OS and components via the golden image.

You can use third-party tools such as Login VSI to perform load-testing for centralized VDI environments after making these changes. Login VSI measures the total response time of several specific user operations performed within a desktop workload in a scripted loop. It's especially useful to calculate the required number of users that can access the VDI platform at any given time.

Regardless of how well the VDI platform is tuned or how many SSD disks are in the platform, the overall end-user experience is not just measured in the performance or the IOPS. For instance, if you have a SaaS application and a slow internet connection or a non-optimized network setup from the central VDI environment, that is going to hinder the overall experience. When you look into sizing from a VDI perspective, it is not just about CPU, memory and IOPS; it is also about understanding all factors that can affect the overall user experience.