Deploying Citrix XenDesktop hosted shared desktops on Amazon Web Services (AWS) combines the advantages of the application virtualized desktop delivery with the benefits of cloud computig. Build a XenDesktop Hosted Shared Desktop (XenApp) farm on AWS creates a desktop as a service solution (DaaS), which allows instant provisioning of application and desktop. This ability often facilitates IT efforts to cope with workload peaks and activity changes such as reorganizations, mergers and acquisitions.
The provision of XenApp application and desktop services from a cloud AWS is cost effective because it is strictly a "pay-for-what-you-use model" that does not require an initial investment. depending on your needs the battery and the application system, the point of delivery of application services prices can be as little as a penny per hour per user, as shown in the "Scalability and XenApp economy on Amazon Cloud "(PDF) whitepaper.
scalability of Citrix XenDesktop hosted shared desktops (XenApp) helps reduce the cost of providing application services. For the size of an AWS environment and help estimate the costs, it is useful to project how many users each instance Amazon Elastic Compute Cloud (Amazon EC2) can handle while maintaining acceptable response times. For this reason, here, our architects Citrix solutions in close collaboration with Amazon solution architects, recently conducted a series of tests. The use of a workload of simulated user, we validated the scalability of XenApp on simple AWS instances, consideration of user responsiveness in a variety of types of EC2 instance. Citrix solution architect Paul Wilson also ran a second test to confirm the scalability of great XenApp farm running multiple server instances.
What we found was a single instance of XenApp scale well when there was a good balance between CPU, memory and I / O resources in the specific type of EC2 instance. In the second test, Paul has demonstrated that there was a linear scalability as he climbed the number of instances.You can read the detailed test report and see a summary of the results in the White Paper "Scalability and XenApp economy Amazon Cloud "(PDF). We also document the steps required to build your own XenApp farm on AWS using CloudFormation scripts that we were created during testing. Stay tuned for a blog entry followed on this. You will then be able to also repeat our tests or run your own to determine optimum user charges without having to manually install the different components of XenApp and configure the environment as a whole.
In addition to the scalability testing, we examined cost effectiveness - a topic we'll explore in another blog entry. In this blog, we will stage an Excel spreadsheet we created and show you how to estimate costs for your own working groups
Test Environment Overview
For tests of scalability, the test environment included .:
- Citrix XenApp 6.5. XenApp delivers applications and session virtualization, centralized delivery and management of applications. It allows both local delivery and hosted in a range of device types. For scalability tests, all application services are hosted on AWS server side.
- Amazon Web Services (AWS). Amazon Web Services works closely with Citrix to help organizations start deploying XenApp in a cloud service model. With EC2 web interface, you can easily configure and deploy IT resources to support AWS XenApp application managed services. You can also provide an Amazon Virtual Private Cloud (VPC) environment, isolating a portion of the AWS cloud. In both cases, you can enjoy the efficiency, security and scalability that AWS provides.
- LoginVSI Connection Consultants (www.loginvsi.com). LoginVSI is a benchmarking tool for performance used to simulate the user workflow and gather user experience.
Configuration Shades
In our tests, 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. storage EBS provides block-level storage for Amazon EC2 instances. Because Amazon EBS burdens both by the amount of storage (GB per month), and the number of IOPS, we configured the XenApp servers with local instance storage for all volatile data such as paging files and user profiles. Since each XenApp session generates an average of 7-8 IOPS per user in the workload, we used the local instance storage was a very economical approach.
By launching instances in separate AWS Availability Zones, you can protect applications from a single point of failure and improve business continuity. For example, you can configure redundant infrastructure services such as Gateway or Active Directory services. Keep in mind, however, that this increases redundancy Amazon "reserve costs." The spreadsheet we created takes these fees into account so that you can calculate a realistic estimate of costs.
Test Methodology
approach rather than a "one-size-fits-all", defines the types of Amazon EC2 instances preconfigured (see aws.amazon.com/ec2 / body-types), and the instance types of groups of related families (eg, standard, High-memory, High-CPU and Cluster Compute). instance types vary by system resources - compute, memory, network 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 type of single instance could support. This value is the key for the design and calculation of profitability.
In the first series of tests, we tested a single Amazon EC2 instance of each type. In a second phase, we examined the scalability of XenApp 6.5 farm hosting 1000 users. In both cases, we used LoginVSI to simulate multiple users accessing XenApp through the Citrix HDX protocol and performing typical office productivity applications.
Single Instance Test
For single instance tests, we selected the predefined LoginVSI Medium flash workload. (Since the application request and the intensity of user activity can have an impact scalability, we kept this constant workload for all single instance tests.)
The LoginVSI average Flash workload loops through a series of Microsoft Office 2010 applications (Microsoft Outlook, Word, Excel and PowerPoint), Internet Explorer with a flash applet video (server side hosted), Adobe Acrobat Reader, and a print job to PDF. LoginVSI opens 5 applications at once, as a typical user, and emulates a keystroke the user to 0ms per character. Applications run in a standard 64-bit Windows 08R2 Amazon Machine Image (AMI), a virtual machine EC2 provided.
During each test, we recorded the relevant performance statistics, such as CPU and memory usage, read / write IOPS and latency, and network throughput. LoginVSI data tracking of user experience. In our tests, we defined success criteria that the response time of less than 4000 ms measured less than six times without the use of more than 80% CPU and 70% memory usage (which is when paging activity starts to saturate the disk).
at the end of each cycle, we overlaid the data from the user's experience with performance data for the subsystem which was a bottleneck. The point where the user experience and the bottleneck of the intersected subsystem has determined the maximum number of users that the type of proceeding could reasonably support.
1000 User Scalability Testing
We conducted a second type of test to assess the feasibility of running multiple instances of XenApp server work, similar to what would be necessary to support typical XenApp farm production on AWS. In this test, we examined the scalability of an EC2 instance (High-Memory Quadruple Extra Large instance, m2.4xlarge). The purpose of this test was different - to demonstrate a working group XenApp could be used to scale - so we used the user workload LoginVSI Light. Using 16 instances of EC2 m2.4xlarge. We also used AWS CloudWatch and Citrix internal testing tool to collect performance data.
Test Results
The bar graph below shows the results for our unique instance tests and gives the maximum number of user sessions that each type of EC2 instance 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 guide. Under different application workloads, types of users, and types of EC2 instances, the optimum number of users will change.
From the graph, it is clear that certain types of EC2 instances are best for XenApp workloads than others. The types of EC2 instances that have supported the largest number of users CPU and memory proportionally more resources, such as those of family Compute Cluster. The following table highlights the instances that have achieved the best results.
| instance type | Configuration | # Users |
| Cluster Compute Eight Extra Large - cc2.8xlarge | 60.5 GB RAM, 88 EC2 Compute units 0 GB of local instance storage, 10GbE | 150 |
| Cluster Compute Quadruple extra large - cc1.4xlarge | 23 GB RAM, 33.5 EC2 Compute Units, 0 GB of local instance storage, 10GbE | 80 |
| Haute -CPU extra large - c1.xlarge | 7 GB of RAM, 20 EC2 Compute Units 0 GB of local instance storage | 22 |
| speaker memory Quadruple extra Large - m2.4xlarge | 68.4 GB RAM, 26 EC2 Compute Units, 0 GB of local instance storage | 65 |
| Double High-Memory extra Large - m2.4xlarge | 34.2 GB RAM, 13 EC2 Compute Units, 850 GB of local instance storage | 33 |
cc2.8xlarge the graphic example below shows how degraded user experience to approximately 150 users. The limiting factor is EBS boot volume that hosts the operating system and applications, as shown in the graph of transfers per second C :. Player
In the test multiple instances of m2.4xlarge, tests showed linear scalability of an instance with 67 users 15 cases with 1,000 users. Here, since sufficient storage capacity, the limiting factor is the CPU usage, as shown in this graph CloudWatch.
The graph CloudWatch all 16 volumes below shows nearly 0 IOPS for each server. Since each server hosts 67 sessions, which is an average of three IOPS per user for the workload tested LoginVSI Light.
Best Practices
Remember that the results presented reflect the conditions and obligations of specific test work, so you must use only for information. Conducting a proof of concept with your own workload can determine the optimal design solution
The test highlighted some best practices for storage AWS :.
- Use EBS volumes to maintain OS boot and XenApp installation data.
- Configure the local instance storage for volatile data, including files of pages, user profiles, and application streaming cache. Since a XenApp server instance can reach 0+ IOPS, more XenApp farm with multiple instances can become very expensive if you host volatile data on EBS instead.
You can use EC2 command line tools to build an AMI with local storage to contain file page and user profiles. We are also working on some automated deployment scripts for building a XenApp farm ready for production on AWS, using AWS CloudFormation technology. We will blog about these scripts and how to use them in the near future, so stay tuned!
References
- "Scalability and economy of XenApp on Amazon Cloud" (PDF)
- "Building a XenDesktop farm Using an AWS CloudFormation model" (PDF )
- URL for CloudFormation scripts hosted on Amazon S3 (JSON)
- ZIP file and certificate CloudFormation script to build your own XenApp farm on AWS (ZIP)
0 Komentar