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:

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.

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.

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:

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

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:

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.

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

Medium Workload

Heavy Workload

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.

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.