BACKGROUND IMAGE: iSTOCK/GETTY IMAGES
One of the most important aspects of deploying a Citrix XenApp environment is scalability, whether it's planning for a new infrastructure or even upgrading an existing one.
From MetaFrame 1.8 up to today's XenApp 6.5, Citrix Systems Inc. has made it a priority for XenApp to be able to scale the host environment out and up when needed. Expected to be announced at the vendor's Synergy conference in 2013, the two sub-projects under Citrix's Project Avalon, Excalibur and Merlin, could include even more scalability features and architecture.
There are a couple of different ways to ensure XenApp scalability. First, you need to pay attention to the design of the virtual infrastructure that will be hosting the environment, specifically the amount of RAM available to all virtual machines, the amount of overall CPU processing power available, and the size, connectivity speed, and type of disk storage that will host the virtual disks and files. Plan for what you need today, add what you might need tomorrow, and then add 20%.
How resource allocation affects XenApp scalability
One tactic many shops use to guarantee scalability is over-architecting the virtual host environment to allow for future growth without having to purchase additional hardware. If you don't supply enough resources, bottlenecks in your XenApp environment can have a huge impact on its ability to scale. Disk, CPU, RAM, or network congestion inhibit the ability to expand a farm to accommodate more users, hosted applications or hosted desktops.
Some of Citrix's documentation on XenApp scalability factors do not seem to fit with the situations I've encountered in the real world. For example, this Citrix blog points out that CPU is "always" the primary bottleneck for XenApp 6.5. However, I have seen more times than I can count that disk I/O has been the primary bottleneck, especially with Hosted Shared Desktops or XenDesktop implementations.
RAM is a close second (sometimes first), with CPU actually being the last resource that causes bottlenecks. The post's author does not explain his testing scenarios, so I can't compare them truly one-for-one with my experiences.
Using load testing to allow for XenApp scalability
One of the primary things you can do to create some really good scalability baselines with XenApp is to employ a load-testing methodology.
More on Citrix XenApp
Comparing XenApp with App-V and ThinApp
Tools for WAN optimization in XenApp
You want to create a load-testing scenario that comes as close as possible to real-world user application and desktop usage in your environment. If you can use live test users, that is a huge plus because it offers a more "true" test and adds flexibility to your load testing with things like latency logins and different endpoints. Still, it does require extra work in coordinating the testing and making sure everyone is testing what they should.
Citrix provides an automated load-testing tool, as do many other vendors, that will generate load on XenApp and run that load for as long as you want. You create a testing scenario with user logins, application launches and use, and all the data on the XenApp environment performance is recorded for further analysis. With the automated load testing, you do lose some flexibility that you have with manual testing, but it doesn't require as much in the way of resources or tester coordination.
Citrix has published the Design and Scalability Considerations for Enterprise XenApp Deployments white paper, but it does not directly address the impact of scalability on Hosted Desktops or XenDesktop implementations. Here are other options for further reading to get you started:
- Andy Baker's blog postings on scalability (see the series links at the beginning of the article)
- Amazon EC2 XenApp scalability analysis
- Scalability and economics of XenApp on Amazon Cloud (this one is not from Amazon, and it's pretty interesting reading)
- Designing a scalable XenDesktop farm
- XenDesktop scalability guidelines