Getty Images
6 steps for calculating and sizing a Citrix VDI environment
While all Citrix environments will require different resource planning, IT administrators can use these 6 steps to calculate and estimate sizing for their CVAD environment.
Correctly sizing a Citrix Virtual Apps and Desktops environment is one of the most critical steps in setting up a new CVAD environment.
As a Citrix virtual desktop administrator, you want to ensure that all the users have the best possible UX within your budget. But there are many factors that can influence the sizing of an environment.
To begin with some disclaimers, every environment is unique, and what works for one environment will not work with another environment. If you want to be precise in sizing your environment, there is only one way to do it: benchmarking. Tools such as Login VSI and LoadGen allow you to create a synthetic workload and benchmark your new environment. This way, you can test if the hardware can handle your different types of end users.
The second disclaimer is that sizing is never finished. Every update to the system can affect the performance and can alter the needed sizing. A test case from Go-EUC showed an example migration from Windows 2019 to Windows 2022 has an impact of 30% on the CPU capacity. To ensure a consistently good performance for end users, monitor performance with tools such as ControlUp, Liquidware Stratusphere and Goliath.
It's also critical to project forward with your budgeting and overall capacity planning. It's common for virtual desktop environments to function properly at first but two years later are beginning to slow down. Without the foresight to budget in advance, it can be difficult to justify funding when a large investment is already in place. The notion of buying new hardware every three to five years and then replacing it might not be consistent with the time anymore -- suppliers like Citrix and Microsoft work with three to six month iterations of their products, affecting virtual desktop performance consistently.
With all this in mind, you should make a sizing plan for a Citrix Virtual Apps and Desktops VDI environment with these six factors in mind.
6 factors to create a Citrix Virtual Apps and Desktops sizing plan
A strong sizing plan lets you calculate how much hardware your environment needs. It's worth noting that with cloud services such as Microsoft Azure, you don't buy hardware but can create the servers directly in Azure. As such, this sizing guide is most relevant for VDI deployments or hybrid approaches to desktop virtualization.
1. End users
The first thing we need to know about for a sizing plan is the end users. How many end users will be signed into the environment? It's essential to look at the total number of users in the environment and the concurrent number of users to determine the maximum number of logins the environment will experience per day. These numbers can differ a lot between sectors; imagine a hospital with a nursing staff that works 24 hours in shifts. That use case might have three to four times as many end users in total than the amount that would be signed into the environment concurrently. The required number of users can also dictate the correct amount of storage required for all user profiles. It will also allow you to set the maximum concurrent load to correctly size the vCPUs and RAM.
2. Office workload
While the number of users is critical, you will need to understand what the end users will be doing in the environment. This may be a bit difficult because what your company could find as a standard user could be a heavy user for a different company.
One common type of worker is known as a standard office worker. These types of users mainly work within Microsoft Office, some internet browsing and business line applications such as ERP apps. When that same user does extensive calculations within Office or the ERP application, such as exporting a large amount of data from the ERP suite to Excel and then working with that data, this is referred to as a heavy office worker. A user that only needs email and a bit of internet browsing or does a small task within a business line application can be referred to as a light office worker.
Generally speaking, light office workers are rare because most users require at least one business line application. Sometimes, however, you may need to prepare for task workers that rarely use the environment. These workers could be considered light office workers.
3. GPU workload
If a user has any sort of workload that might require GPU, you need to account for them separately. You will need to identify what sorts of GPU workloads will be required. Is the workload heavy single-threaded, or is it multi-threaded? Are the users doing renders, or are they just editing -- for example, altering an image?
A big mistake I have often seen when it comes to GPU workloads is to add a big GPU to a regular virtualization server. This does not work with a computer-aided design (CAD) workload; many CAD programs are heavily single-threaded. You can get the most performance gain by ensuring you have CPUs with a high clock speed of at least 3 GHz or more.
Keeping all this in mind, we can make three profiles for GPU workload. First, the default CAD user mainly uses CAD to view and edit drawings and doesn't render any files in 3D. These users are the CAD GPU workers. Then we have the users who use the environment to edit pictures in applications such as Adobe Photoshop; these users also don't require a large amount of raw GPU power, and the software is often better optimized for the multi-threaded workload. This we will call the standard GPU worker. Lastly, we have a user who requires a large amount of GPU power; this user may need to create 3D renders with CAD or video edit and render it out. These are the heavy GPU workers. And all three require different hardware in your size plan.
4. Multi-session vs. single session
When sizing your environment, using multi- and single-session hosting is something to consider. The advantage of the single-session VDI is that you guarantee every user a part of the performance. With multi-session -- Remote Desktop Session Host -- you share the resources of the virtual server; this can lead to one user consuming too many resources, hindering other users' performance on the server.
The disadvantage of a single session is the amount of hardware you will need. It will be much higher, which means higher costs. Generally speaking, it's a good idea to use multi-session hosting for as many desktops, machines, apps and services as possible to limit hardware costs.
Consider a Microsoft Office workload as an example. The light and standard workload of this suite can run on multi-session. Multi-session can work for a standard GPU workload as well.
5. Cloud or on premises
The next consideration is if you will use a cloud or on-premises environment. You should keep in mind that public cloud providers have a hard time delivering the CPU speeds required for the CAD and heavy GPU workloads. Another key factor to remember is the number of users per server allowed in a multi-session environment. In a cloud environment, you would use a smaller server and fewer users per server than on premises.
This has to do with autoscaling -- Citrix can create and delete servers on demand, and the fewer servers that your environment needs, the cheaper the environment will be. But autoscale can't delete a server if users are still working on it. Consider an example where you make a large server in the cloud where 20 people can sign in at night; the server is almost empty except for one user still working on it. At that point, you need to keep paying for that large server just for one user.
You should create smaller servers and size them with five to 10 users each. This way, there is a higher chance the server can be deleted sooner, saving operations costs. For example, you could create six servers if you have 100 users and want to divide them on premises on multi-session servers. With six servers, you have a user density of around 16 per server; even if one server experiences an outage, the density goes up to 20, which is acceptable. For 100 users in the cloud, you should make 20 smaller servers with a maximum density of five users. Using a public cloud like Microsoft Azure significantly impacts your sizing plan.
6. Overhead
While it's easy to overlook, overhead is a critical factor to consider. Despite the best laid plans, your environment will change over time and might need room to grow. More users could be onboarded and the workload will become heavier over time simply by updates. Also, remember that you should work with N+1, meaning we take the normal required servers plus one server just in case of an outage or maintenance.
Calculating an example Citrix environment
Now you need to add the resources to the types of workers. This is, of course, subject to change and your specific environment, but the following table provides a good starting point:
| Workload | vCPU | vRAM | vGPU | Single or multi-session |
| Light office worker | 0.5 Core (2 -- 2,6 GHz) | 1 GB | -- | Multi |
| Standard office worker | 0.8 Core (2 -- 2,6 GHz) | 2 GB | -- | Multi |
| Heavy office worker | 4 Core (2 -- 2,6 GHz) | 8 GB | -- | Single |
| CAD GPU worker | 4 Core (3 -- 3,6 GHz) | 16 GB | A16 (T4) | Single |
| Standard GPU worker | 4 Core (2,6 -- 3 GHz) | 8 GB | A16 (T4) | Multi |
| Heavy GPU worker | 8 Core (3 -- 3,6 GHz) | 32 GB | A40 | Single |
For profiles, consider using FSLogix to calculate at least 5 GB of storage per user when using Exchange online and 1 GB of storage per user if you're not using Exchange Online.
Here is an example of such a calculation: If you have 40 standard office workers, you will require 40 x 0.8 = 32 vCPUs and 40 x 2 GB RAM = 80 GB. In this case, it would make sense to create 3 -- remember to work with N+1 -- multi-session servers of 16 vCPUs and 40 GB of RAM if this were an on-premises environment.
