Overview

One of the key benefits of Cloud Desktop is the support for multi-session desktop environments. Multi-session desktops let you have multiple users logged into a single Session Host server, which can minimize the number of required server instances and significantly reduce compute costs.

In order to effectively leverage multi-session desktops and ensure a good experience for your users, it is important to properly size your CAS Collection Pools. Sizing consists of determining several parameters:

• Workload identification: What users in your organization have similar usage patterns?
• Workload demands: What are the CPU and memory requirements for a typical user's session in each workload?
• User density: How many desktop sessions will be running on each Session Host server?
• Session Host resources: What VM instance types and sizes will be used for Session Host servers?

This article will walk through each of these topics to help you estimate the proper sizing for your Cloud Desktop environment. It's helpful to remember that resources in CAS can be resized at any time, although some components might require a reboot and could result in a brief service disruption for your users. Therefore, itopia recommends that you perform sizing calculation and validation prior to deploying your production environment.

Workload Identification

The first step to properly sizing your Cloud Desktop environment is to determine the number of distinct workloads performed by your users. A workload refers to a set of applications and tasks that your end-users commonly perform in their Cloud Desktops. Depending on your environment, you may have: a single workload, where all users perform similar tasks and run a similar set of applications; or multiple workloads, where different sets of users require different applications and perform different tasks as part of their regular duties.

Therefore when transitioning to Cloud Desktop, it is useful to inventory the applications used and the tasks performed by the users in your organization. This inventory can then be analyzed to identify commonalities across users and create the initial grouping into workloads.

Other factors may contribute to defining unique workloads, such as two departments that use the same applications but one department handles sensitive data and therefore requires stronger security controls. If these differences are significant, it may be required to consider each group as a different workload; however, the sizing parameters can usually be considered identical for both.

Workload Demands

With your workloads now defined, you can perform benchmark testing to determine the resource requirements for each instance (user) of the workload. There are several methods to do this, each providing different degrees of accuracy.

Sizing can be estimated three ways:

• Existing environment metrics - The simplest method is to run a performance monitor on one (or more) user's existing workstation while they perform their daily tasks. Using this information and the technical specifications of their device, you can establish a rough estimate of the CPU and RAM requirements for their workload and extrapolate that information for a multi-session environment.
• Single-session extrapolation - If you don't plan to do a proof-of-concept deployment in CAS, you can manually provision a standard VM in Google Cloud, install your required applications, and then have a single user log in and perform their regular workload. If their user experience is good, try reducing the CPU and RAM resources for the VM and have them test again. the goal is to find the smallest VM instance size upon which a single user session can have good performance. You can then use this VM instance size with the formula below to determine the best sizing for your User Session Servers.
• Multi-session load testing - If you have a proof-of-concept deployment (or you have your production deployment but are not yet loading production workloads), configure a Collection Pool with an estimated VM size and user density, assign enough users to populate a single host, and then have those users access their Cloud Desktops and test performance. If their user experience is good, try reducing the CPU and RAM resources or increasing the user density; continue to iterate this testing until session performance starts to be affected.

Special Workload Considerations

Certain applications and workloads may require additional consideration and planning in order to perform well in Cloud Desktop (or any cloud-based VDI solution). Specifically, applications that leverage media streaming such as software telephony (VoIP phones) and video teleconferencing typically incur a large performance penalty and are very sensitive to multi-session environments. itopia generally recommends removing these applications from Cloud Desktops and running them directly on users' local workstations; if this is not possible, Collection Pools should be carefully sized to account for the resources demanded for these applications, and Dedicated Collection Pools may be a good option to impose a 1:1 user density. Other elements such as network traffic routing and end-user bandwidth also affect the performance of these scenarios. so careful planning is recommended.

Similarly, workloads that perform a lot of "local I/O" such as reading and writing from the local disks on session hosts may also require additional consideration. For standard workloads, itopia deploys session hosts using "Standard HDD (magnetic)" storage for the local disks. If your users are performing high-I/O activities, consider configuring your session hosts with "Standard SSD (solid-state)" or even "Premium SSD (solid-state)" storage for the local boot disk. Be aware that these disks incur significantly higher costs per gigabyte than HDD-based storage; refer to Google's 

User Density

Once your baseline workload requirements are established, consider a practical target for user density. Depending on the workload and the Session Host sizing (discussed below), Cloud Desktop deployments can typically support up to 25 users per host. However, there are other factors to consider for user density:

• How many users will be affected by the failure of a Session Host server?
• If a subset of users suddenly demand significantly higher compute resources, how many people will be impacted?
• What percentage of time will Session Hosts be running unutilized or underutilized?

In the event of a server failure, consider whether users will be able to quickly resume working on surviving servers. For example, if a Collection Pool has 50 users and user density is configured at 25 users per server, then a single server failure means that the surviving host must now try to support 200% of its target load; generally, this will not work or will at least provide a very bad computing experience for all users on the overloaded server. However, if the user density was configured at 15 users per server, a single server failure means that the surviving hosts must only support 133% of its target load at most.

Similarly, if a single user's session suddenly encounters a software bug (or even a website with bad JavaScript) that attempts to consume as much CPU or RAM as possible, how many users will be affected? Cloud Desktops use the Microsoft FairShare CPU scheduling algorithm to help mitigate the impact to other sessions, but even with this mitigation it is very likely that other user sessions will suffer poor performance.

Finally, consider the tradeoff of fewer, large VM instances versus more, smaller VM instances. If itopia's Dynamic Uptime feature will be enabled, CAS may be able to power off more VM instances if there are fewer users on each host, because the hosts are more likely to "empty out" as users log off. Similarly, because users connect to Session Hosts in a mostly random order, it is possible that your larger VMs may be underutilized if the Collection's full user count is not simultaneously connected. itopia's Dynamic Uptime is typically more effective with a larger number of Session Host servers.

However, it is also important to consider the benefits of fewer VMs in terms of management, OS and application patching, and disk image refreshes. Depending on the licensing model for your applications, fewer Session Host instances may also require fewer licenses.

Ultimately, each organization must attempt to strike the right balance for target user density for their own specific needs.

Session Host Resources

With the parameters above defined, you can now calculate the appropriate VM instance size for your specific workload. 

When using the first two methods for identifying your workload demand, keep in mind that resource requirements do not scale linearly with the number of users. For example, a VM instance with 2 vCPU and 4 GB RAM may be the minimum required for a single user, but a VM instance with 4 vCPU and 16 GB RAM can typically handle 5-6 users and a VM instance with 8 vCPU and 32GB RAM may be able to support up to 20 users. itopia recommends monitoring and adjusting your sizing for your specific requirements; however, as a general guideline, itopia uses the following equations for estimating resource requirements on User Session Servers for different workloads:

Light Workload

CPU: ( (number of users) x 0.3) + 2, rounded down to the nearest even number
RAM: ( (number of users x 1.25) + 4, rounded down to the nearest even number

Medium Workload

CPU: ( (number of users) x 0.6) + 2, rounded down to the nearest even number
RAM: ( (number of users x 2) + 4, rounded down to the nearest even number

Heavy Workload

CPU: ( (number of users) x 1.25) + 2, rounded down to the nearest even number
RAM: ( (number of users x 4) + 4, rounded down to the nearest even number

Using these estimates, itopia then attempts to strike a balance between minimizing "server sprawl" (i.e., having too many individual servers) and optimizing VM instance cost. Typically, itopia recommends VM instance sizes that have between 4 and 24 vCPUs; beyond that, the increased performance of additional vCPUs begins to provide diminishing returns.

Conclusion

Finding the optimal sizing for your multi-session workloads is equal parts art and science. This article provides practices and recommendations to help calculate sizing for CAS Collection Pools for typical scenarios. Whenever possible, itopia recommends testing, monitoring, and validating sizing assumptions by monitoring environment performance and adjusting sizing parameters as necessary.