by Gareth Carson, CTP
When I was younger, so much younger than today, I gazed at a pair of trainers that I had to own, pleaded to always be a good boy and never do naughty things if I could have them. Once I duped my parents, I tried the shoes on. Wow, they were incredible. Clean, not a mark on them and, more importantly, they were “named” sports trainers. Proper cool-looking grips with some mesh material on the leather for extra dude appeal. There was one small problem. They were way too small. As they were the only pair in the shop, I tried them on and did the new shoe walk up and down the store and told my folks they fit perfectly. To this day, I have feet like a Hobbit. I cannot stress to you how much size matters. Sorry folks!
One of the tasks, that as an architect, you will be required to do from time to time is to assess a solution based on a set of requirements. Sometimes, you will not have the luxury of true benchmarking or testing, but we do have tools to utilise for such exercises as Login VSI and Login PI. I will move on to the advantage of such tools in later articles. Sometimes you will be forced to do some theoretical sizing, and this will be based on a set of requirements and best practice and a little bit of simple arithmetic. The issue with theoretical sizing is just that–and there are external factors that play havoc with the “true” figure.
What do you really need to be aware of when sizing a Citrix solution from the ground up?
- Know your best practice.
- Know your math.
- Drink Coffee.
- Be aware of the impact of Office/AV/Monitoring agents.
- Be aware of Spectre/Meltdown and L1TF vulnerabilities.
- Numa Sizing.
- Real world experience from yourself or others (Never hurts to ask the experience of another guru).
- VDI handbook 7.15 LTSR.
- Know when to round up or down from a figure.
- Factor in growth.
- Factor in N+1.
Spectre/Meltdown has been on everyone’s radar but L1TF is the new guy in town. Recent tests performed by those Login VSI consultants, whose company mantra I always feel should be “SIZE DOES MATTER,” have recently conducted tests with L1TF on Citrix Hypervisor and ESX hosting layers and found quite a significant performance hit with VDI windows 10 workloads. This is over a 20% performance hit with ESXi and Citrix Hypervisor. That is quite significant, and if you do not take this in to account when sizing a solution, you will be preparing to fail.
Let’s take the following scenario:
- Dave the CIO in Company ACME.COM wants to have 5,000 users all on Citrix SBC desktops in the data centers across Austin, Dallas, and Houston, Texas.
- The hardware they have has 550 GB memory and 2 x 24 core CPU.
- They are after Windows Server 2016 O/S server-based computing solution.
- Applications consist of office apps, web based apps using Chrome and IE and some dictation software. Users will play media files from time to time and have some crazy excel files that love to hog a resource.
- The solution is active/active but if one site fails, 75% of your workforce should still be able to work at either site.
- Citrix Hypervisor will be used as it has been decided this provides the best solution for Citrix Workloads.
You are putting in the solution and halfway through the project, you remember that line from the film JAWS “We are going to need a bigger boat.”
It slowly dawns on you that more hosts and resource will be required.
Although you might be right in your math when it comes to sizing, you may have missed out on some fundamental points I listed above on what to factor in. If you do not take this in to account when carrying out your theoretical sizing, you might fall short.
- You have 5000 users.
- You have 2 x 24 cores (48 logical cores) per host
- 550 GB memory per host
- Resource hogging applications
Taking the information we have above, we can work out the following for a Citrix Application workload:
Tip! Most of the time your resource constraint will be the CPU.
Sizing – Phase 1
Number of Users per CPU
You have decided that you want no more than 30 users per Citrix Application server. You are scaling out not up. Based on this, the best practice is to go with 8 vCPU and 32 GB Memory for a 2016 Windows Server O/S with Citrix heavy user load (I am leaving NUMA out of this one for now).
Note: Heavy user load according to VDI handbook for CPU usage basically aligns 4 users for each virtual CPU. There are some recommendations out there that range from 1 to 2 and having software like WEM can help in this area. Contention Ratio for CPU in this example is 1:1.
(Read your VDI Handbook! https://docs.citrix.com/en-us/xenapp-and-xendesktop/7-15-ltsr/citrix-vdi-best-practices.html)
4 CPU x 8 Users= 32 Users (This is based on heavy user ratio for CPU).
Amount of Citrix App Hosts Required
We want 30 users divided by total number of users required (5000 Total users) to work this sum out.
30 USERS / 5000 USERS = 166.66 Citrix Hosts.
We round up remember so we get 167 Citrix Application Hosts that we require.
Amount of Citrix Application Servers per Citrix Hypervisor Host
Based on 8 CPU per Citrix Application Server host, we can have no more than 5 machines per Citrix Hypervisor host as it has 44 logical cores.
44 cores divided by 8 cores = 5.5 Citrix Application Server hosts.
We know that we cannot have 5.5 Citrix Application Server hosts, so we round down. Rounding up at this point would provide 6 hosts which we do not have the capacity for.
This means we can have 5 Citrix Application Server hosts per Citrix Hypervisor (based on 2×44 CPU and 550 GB memory).
Amount of Citrix Hypervisor Hosts Required
Now we can figure out how many Citrix Hypervisor hosts we require.
We figured out that we require 5 Citrix App hosts per Citrix Hypervisor host which we divide by 167 total Citrix Hypervisor hosts.
5 / 167 = 33.4 Citrix Hypervisor hosts.
We round up as we cannot have 33.4 Citrix Hypervisor hosts.
34 Citrix Hypervisor Hosts are required.
Are we there yet?
Are we confident at this stage this is a true figure? Remember the requirements and the performance hits?
It is at this stage we need to factor in the effects of office/AV/Spectre/Meltdown and L1TF. We also need to look at the DR requirements and take this in to consideration plus growth.
Sizing – Phase 2
Let’s now move on to the next stage of the sizing exercise.
The next set of figures may change slightly depending on when you apply the figures but, in this scenario, I will apply the growth figure last.
Let’s take the 75% requirement based on the base figure as the next sum.
There are different ways to figure this out such as taking the total figure of Citrix Hypervisor hosts and working out 150% and then dividing by two. I approach this differently.
75% of the total figure of Citrix Hypervisor hosts (34) = 25.5
As there are 2 sites in this scenario you need to multiply this figure by 2.
25.5 x 2 = 51
You then take this figure and split it across the 2 Data Centre sites (Austin and Houston).
51 / 2 = 25.5
You round up, so you have the number 26.
26 Citrix Hypervisor hosts are required at each site location. A total of 52 Citrix Hypervisor hosts.
If we go with a slightly made up theoretical figure of 25% performance hit for Xenapp workloads (This is just an example to highlight how you would factor in a performance hit).
25% of Total number of Xenserver hosts (52) = 13
Therefore we add 13 Citrix Hypervisor hosts to each site to mitigate the performance impact.
52 + 13 = 65
Now we divide 65 by 2 (We have 2 sites, remember?).
65 / 2 = 32.5
We round up, so we have 33.
33 Citrix Hypervisor Hosts are required at each site location. 66 Citrix Hypervisors in total.
Lastly, I factor in the growth figure. Now, you could argue the growth figure should be taken from the original figure presented without taking the additional requirements into consideration. Personally, I would take this from the last set of figures we had for Citrix Hypervisor Hosts required, which was 66.
20% of 66 Citrix Hypervisor Hosts = 13.2
We need to round up this figure and then divide it by 2 (As we have 2 sites).
14 / 2 = 7
7 additional Citrix Hypervisor hosts are required at each site location for 20% growth.
33 + 7 = 40
40 Citrix Hypervisor hosts are required at each site location. 80 Citrix Hypervisor hosts in total.
N + 1 Requirement
This one is a little tricky as you need to think about Resource Pools and Workloads. It is not as simple as just saying you require an extra Citrix Hypervisor per site. You will require N + 1 per Resource Pool for true N + 1. You need to identify the Resource Pool size limitations based on the version of Citrix Hypervisor you are deploying.
Remember you are sizing so you can tolerate a percentage of host failure within a Resource Pool. Therefore it is best to assess your sizing without basing it on the virtual cores you can achieve with Hyperthreading. You will need CPU and memory capacity for failed machines.
We can see the original set of figures based on hosting figures came out at 34 Citrix Hypervisor Hosts.
With the requirements taken in to consideration this quickly adds up and that figure turned in to 80 Citrix Hypervisor hosts in total. 40 at each site location (N + 1 will increase this figure). This is theoretical sizing and not an exact science. Sometimes this is all you must go on, so you really do need to take other factors into consideration when sizing appropriately.
Yes, there is NUMA, hardware considerations and many other factors but the idea is to present a scenario that will highlight how easy it is to get the math wrong and show you the process of manually working the math out.
Our friends at Login VSI provide useful tools for sizing workloads and have plenty of articles on performance impacts:
My good community friend Dave Wilkinson also has some great articles on how to carry out your cost/sizing using Excel. This is based on Azure but will highlight the use case.
When it comes to sizing/costing Excel can become your best friend and there are various tools that can aid in this process. You do not have to hurt your head. Lastly, just to put the record out there, I do not want to be known as the guy with a size issue. That is Wilky.