Deploying Citrix XenDesktop Hosted-shared desktops on Amazon Web Services (AWS) combines the benefits of virtualized application and desktop delivery with the advantages of cloud computig. Building a XenDesktop Hosted-shared desktop (XenApp) farm on AWS creates a Desktop as a Service (DaaS) solution that allows instantaneous application and desktop provisioning. This capability often eases IT’s efforts to cope with workload spikes and business changes such as reorganizations, mergers, and acquisitions.
Delivering XenApp application and desktop services from an AWS cloud is cost-efficient because it’s strictly a “pay-for-what-you-use” model that doesn’t require an up-front investment. Depending on your application stack and system requirements, the price point for delivering application services can be as little as a penny per hour per user , as shown in the “Scalability and Economics of XenApp on Amazon Cloud” (PDF) whitepaper.
The scalability of Citrix XenDesktop Hosted-shared desktops (XenApp) helps to lower the cost of application service delivery. To size an AWS environment and help to estimate costs, it’s helpful to project how many users each Amazon Elastic Compute Cloud (Amazon EC2) instance can support while maintaining acceptable response times. For this reason, here at Citrix our solution architects, in close cooperation with Amazon solutions architects, recently conducted a series of tests. Using a simulated user workload, we validated the scalability of XenApp on single AWS instances, examining user responsiveness under a variety of EC2 instance types. Citrix solution architect Paul Wilson also spearheaded a second test to validate the scalability of a large XenApp farm running multiple server instances.
What we found was that a single instance of XenApp scaled well when there was a good balance between CPU, memory, and I/O resources in the specific EC2 instance type. In the second test, Paul demonstrated that there was linear scalability as he scaled the number of instances.You can read the detailed testing report and see a summary of the results in the white paper “Scalability and Economics of XenApp on Amazon Cloud” (PDF). We’re also documenting the steps needed to build your own XenApp farm on AWS using CloudFormation scripts that we were created during tests. Stay tuned for a follow-up blog entry on this subject. You will then be able to also repeat our tests or run your own to determine optimal user loads, without having to manually install the various XenApp components and configure the whole environment.
In addition to scalability testing, we looked at cost-effectiveness — a topic we’ll explore in another blog entry. In that blog we’ll step through an Excel spreadsheet we created and show you how to estimate costs for your own workgroups.
Test Environment Overview
For the scalability testing, the test environment included:
- Citrix XenApp 6.5. XenApp provides application and session virtualization, centralizing application delivery and management. It enables both local and hosted delivery across a range of device types. For the scalability testing, all application services were hosted server-side on AWS.
- Amazon Web Services (AWS). Amazon Web Services works closely with Citrix to help organizations get started deploying XenApp farms in a cloud services model. Through the EC2 web interface, you can easily configure and deploy AWS compute resources to support XenApp-managed application services. You can also provision an Amazon Virtual Private Cloud (VPC) environment, isolating a portion of the AWS cloud. In either case, you can take advantage of the efficiency, security, and scalability that AWS offers.
- LoginVSI from Login Consultants (www.loginvsi.com). LoginVSI is a performance benchmarking tool used to simulate user workflow and to collect user experience data.
In our testing, all XenApp servers were configured with a single Amazon Elastic Block Store (EBS) boot volume and one or two local-instance storage volumes, depending on the instance type. EBS storage provides block-level storage for Amazon EC2 instances. Since Amazon charges for EBS both by the amount of storage (GB per month) as well as the number of IOPs, we configured XenApp servers with local-instance storage for all volatile data such as paging files and user profiles. Since each XenApp session generates an average 7-8 IOPS per user in the workload we used, local-instance storage was an extremely economical approach.
By launching instances in separate AWS Availability Zones, you can protect applications from a single point of failure and enhance business continuity. For example, you may want to configure redundant infrastructure services such as Gateway or Active Directory services. Keep in mind, however, that this redundancy increases Amazon’s “reserve charges.” The spreadsheet that we created takes these charges into account so you can calculate a realistic estimate of projected costs.
Rather than a “one-size-fits-all” approach, Amazon defines preconfigured EC2 instance types (see aws.amazon.com/ec2/instance-types) and groups instance types into related families (e.g., Standard, High-Memory, High-CPU, and Cluster Compute). Instance types vary depending on the system resources — compute, memory, networking and storage — dedicated to each configuration and are charged per hour accordingly. To examine the scalability of XenApp servers on EC2 instances, we wanted to determine the number of users that each single instance type could support. This value is key for sizing and calculating cost-efficiency.
In the first series of tests, we tested a single Amazon EC2 instance of each type. In a second phase, we looked at the scalability of a XenApp 6.5 farm hosting 1,000 users. In both cases, we used LoginVSI to simulate multiple users accessing XenApp via Citrix HDX protocol and running typical office productivity applications.
Single Instance Testing
For the single instance testing, we selected the predefined LoginVSI Medium with Flash workload. (Since application demands and the intensity of user activity can impact scalability, we kept this workload constant for all of the single instance tests.)
The LoginVSI Medium with Flash workload loops through a series of Microsoft Office 2010 applications (Microsoft Outlook, Word, Excel, and PowerPoint), Internet Explorer with a Flash video applet (hosted server-side), Adobe Acrobat Reader, and a print-to-PDF task. LoginVSI opens 5 applications at a time, just like a typical user, and emulates a user typing at 160ms per character. Applications run in a standard 64-bit Windows 2008R2 Amazon Machine Image (AMI), an EC2-provided virtual machine.
During each test run, we recorded relevant performance statistics, such as CPU and memory utilization, read/write IOPS and latencies, and network throughput. LoginVSI tracked user experience data. In our testing, we defined success criteria as response times lower than 4000 ms measured less than six times consecutively with no more than 80% CPU usage and 70% memory usage (which is about when paging activity begins to saturate the disk).
At the conclusion of each run, we overlaid the user experience data with performance data for the subsystem that experienced a performance bottleneck. The point where the user experience and the subsystem bottleneck intersected determined the maximum number of users that the instance type could reasonably support.
1,000 User Scalability Testing
We performed a second type of test to evaluate the feasibility of running multiple XenApp server worker instances, similar to what would be required to support a typical XenApp production farm on AWS. In this testing we examined the scalability of one EC2 instance (the High-Memory Quadruple Extra Large instance, m2.4xlarge). The purpose of this test was different — to demonstrate that a XenApp workgroup could be use to scale — so we used the LoginVSI Light user workload. Using 16 EC2 m2.4xlarge instances. We also used AWS CloudWatch and a Citrix internal testing tool to gather performance data.
The bar graph below shows the results for our single instance testing and gives the maximum number of user sessions that each EC2 instance type supported before a user-experience and subsystem bottleneck occurred. Note that this value reflects the specific test conditions and should be used only as a guideline. Under different application workloads, user types, and EC2 instance types, the optimal number of users will change.
From the graph, it is readily apparent that some EC2 instance types are better suited for XenApp workloads than others. The EC2 instance types that supported the highest number of users had proportionally higher CPU and memory resources, such as those in the Cluster Compute family. The following table highlights the instances that achieved the best results.
|Instance Type||Configuration||# Users|
|Cluster Compute Eight Extra Large – cc2.8xlarge||60.5 GB RAM, 88 EC2 Compute Units, 1690 GB local-instance storage, 10GbE||150|
|Cluster Compute Quadruple Extra Large – cc1.4xlarge||23 GB RAM, 33.5 EC2 Compute Units, 1690 GB local-instance storage, 10GbE||80|
|High-CPU Extra Large – c1.xlarge||7 GB RAM, 20 EC2 Compute Units, 1690 GB local-instance storage||22|
|High-Memory Quadruple Extra Large – m2.4xlarge||68.4 GB RAM, 26 EC2 Compute Units, 1690 GB local-instance storage||65|
|High-Memory Double Extra Large – m2.4xlarge||34.2 GB RAM, 13 EC2 Compute Units, 850 GB local-instance storage||33|
The cc2.8xlarge instance graph below shows how the user experience degraded at about 150 users. The limiting factor was the EBS boot volume, which hosts the OS and applications, as shown in the graph depicting transfers-per-second to the C: drive.
In the test of multiple m2.4xlarge instances, the testing showed linear scalability from one instance with 67 users to 15 instances with 1,000 users. Here, given adequate storage capability, the limiting factor was CPU utilization, as shown in this CloudWatch graph.
The CloudWatch graph of all 16 volumes below shows almost 200 IOPS for each server. Since each server is hosting 67 sessions, that’s an average of three IOPS per user for the tested LoginVSI Light workload.
Remember that the results presented reflect specific test conditions and workloads, so you should use them only as a guideline. Conducting a proof-of-concept with your own workload can determine optimal solution sizing.
The testing brought to light a few best practices with respect to AWS storage:
- Use EBS volumes to hold OS boot and XenApp installation data.
- Configure local-instance storage for volatile data including page files, user profiles, and application streaming cache. Since a XenApp server instance can reach 200+ IOPS, a larger XenApp farm with multiple instances can become quite costly if you host volatile data on EBS instead.
You can use EC2 command line tools to build an AMI with local storage to contain page files and user profiles. We’re also working on some automated deployment scripts for constructing a production-ready XenApp farm on AWS using AWS CloudFormation technology. We’ll be blogging about these scripts and how to use them in the near future, so stay tuned!