Although I can give you a lot of experience and background into how I size for Citrix deployments, it really isn’t that much of a secret. There are many people more qualified than myself but I’ve been a Citrix architect for years and currently run a workforce mobility practice at Presidio, a Platinum Citrix Partner, and this year’s Partner of the Year. I felt impelled to write this because I’ve seen documents and guides that say you need 100s of data points to enter, assessments need to be done and it begins to look like the cost for finding this magic number will be more than the services to build it. Don’t misunderstand me though, I’m not giving you an absolute that will be perfect. This process is really designed to help budget, size or give a sanity check to numbers you either produce or you are being shown.
For XenApp 6.5 we see quite a bit of sizing documentation, there is even quite a bit for XenDesktop 5.6. However, the sizing for anything past 7 seems a bit sparse and one is left wondering whether much has changed. The majority of deployments I see (in large scale) still tend to be towards the server side. Have things changed from XenApp 6.5 to XenApp 7.5 so much that sizing is irrelevant?
No. I’ve read and heard too much that make this out to be more complicated than it really is! The reality is that you don’t need a 50-page guide on how to size for servers (or even desktops).
There is a standard for hosts (physical servers) and XenApp guests (virtual servers) that you can use. It took a little effort but I actually found specs that Citrix Consulting will support. If you disagree, show me what you have in the comments!
This magic server consists of:
16 GB RAM (for 2008 R2) and 24GB (for 2012/2012 R2)
Notice I don’t have books on storage or IOPS, it’s because I don’t care at this point honestly, we are sizing, the storage can come later but if you must think of a number, 60-80GB for a XenApp server is a good one. Recently I’ve used 120GB as a C: drive on XenApp with PVS and generally default to a 15GB write cache where possible. I will say the write cache is a good topic to discuss, but for light use cases (office and web apps, no outlook), 15GB is a good place to start. If you’re sizing the PVS write cache under 10GB you need to justify it by going through some more difficult exercises.
So this ideal XenApp server can be used to determine how many servers we need, which is often a question I get asked constantly.
First of all, for enterprise deployments, you should have a minimum of 2 management blades or servers, ones that you can vmotion, live migrate or XenMotion management VMs from. You ought to have 2 PVS servers, 2 delivery controllers, 2 Storefront servers (notice I don’t have XML, ZDC or WI servers…we are going with 7+ is why). So without those servers we then get into the infrastructure blades or hosts.
Let’s say we have 5,000 users we need to provide desktops for and we want to leverage Citrix XenApp 7.5 to do so. We need another ideal number for number of users per server. You really can’t go wrong with 30 users/server for the cases I spoke of above, if you have crazy applications, obviously the sizing might change but most people do not (or they definitely know if they do). I don’t want to go above 60 users/server generally but 30 users is where I aim and has, in my experience, been a good gauge.
5000 total users/30 users per server = 167 servers (@30 users a server)
We want to add 1 or 2 XenApp servers for redundancy and another 4 or 5 XenApp servers for testing/dev, in this case I round up to 175 total XenApp servers. At 175 I’m looking now at the total of:
2,800 GB RAM (for 2008 R2)
As a side note, this is roughly 470MB per user (assuming we reserve 2GB for the OS)
If I have a server that has 192GB memory, I need:
2800/192 = 15 servers @192GB memory for 2008 R2 (always round up)
I would add another blade for n+1 and now I have:
2 management blades @96 GB RAM (bare minimum)
16 infrastructure blades @192 GB RAM
So If I’m looking at Cisco UCS for example, I’d need 3 chassis (each one can hold 8 blades) for 2008 R2. I could actually fit that in a single rack and server 5000 users from one rack which isn’t too bad!
Are there exceptions to this? Of course there are, but if you need a place to start, this is not a bad way to do it for sizing. I do NOT oversubscribe memory and suggest you do not either, the savings are so insignificant and the benefit seems completely unwarranted in my opinion.
If you have a better way to do this, let me know in the comments.
Credit for some of these numbers goes to the Citrix Consulting team, who I kept playing 20 questions with to figure out which combo would get them to not comment about it!
As for storage sizing, there are other general sizing techniques you can use. If you’d like to know more about a large deployment I did based on the above sizing techniques and if you’d like to know how the storage was sized, please attend my Synergy Session SYN119 on providing desktops to 50,000 students and I’ll be happy to share.
Tom Gamull is the workforce mobility practice manager for Presidio, focusing on virtualization and end-user computing. He presented at Synergy 2013 and has run numerous engineering and customer events. Tom is certified as a CCE for Apps and Desktops and a CCP for NetScaler. He is a member of the Partner Technical Expert Council for 2014. You can follow his blog (magicalyak.wordpress.com) or follow him on Twitter @MagicalYak.
Citrix invited the author of this blog post to present at Citrix Synergy 2014 and to participate in a related contest. The author received an entry into the contest for submitting this Blog.