Citrix Cloud Testing on Amazon EC2 M4


Citrix Cloud on AWS

I was recently afforded the unique opportunity to collaborate on a project to test capacity out of a Citrix XenApp on AWS deployment. The goal of the project was to independently determine the maximum user density for a few different EC2 instance types running XenApp 7.14.

EC2 instances are on-demand and elastic hosted server resources. Which means that they are provisioned dynamically within a pool of available resources, and with an OS you deploy ontop. Amazon provides a variety of templates to easily install Windows, Linux or your other favorite OS. EC2 instances are broken down into a few varieties. They are optimized for storage, memory, compute or graphics. The designation before the name of the instances illustrates their configuration. G3 indicates graphics optimized instance third generation.

The other difference between instance type is the cost. If you are provisioning a 2vCPU 4GB of RAM machine the price per hour would be significantly less than that of a 16vCPU 64GB of RAM machine.

1st

This would allow the customer to match the exact machine size to the purpose of their deployment, and optimize the amount of money they were spending on their hosted application solution.

Utilizing Login VSI’s virtual users I ran a predetermined user count against a Citrix XenApp deployment managed from Citrix Cloud.

For this blog, I will only discuss one data point, and the Citrix Cloud configuration on AWS. We have a significant amount of results, and we will make those available on www.loginvsi.com/blog.

For those of you not familiar Citrix Cloud is providing Citrix capabilities traditionally delivered on premise through a HTML web based user experience therefore installing a receiver is no longer required.

Some of the key components as they move into their cloud forward offerings are StoreFront / Netscaler and Studio.

2nd

StoreFront and NetScaler are completely managed now through a web page. This completely removes the administrator’s responsibilities of configuring hardware / software solutions for Citrix. You simply fire this up, attach it via their “Citrix Cloud Connector” and configure to start deploying your desktops or apps. It works completely flawlessly.

Studio is managed through the connector as well, and provides the Citrix HTML 5 receiver for management access through the Citrix Cloud web portal.

During my time working with it, it proved to be very flexible, easy to configure and reliable for all testing. I would recommend this to any administrator looking at future proofing their Citrix deployments. It is truly ready for market.

Some images below of the management interface:Some images below of the management interface:

There will be a management icon within your Citrix Cloud Dashboard. Select “XenApp and XenDesktop Service” “manage”

3rd

You will then go to the management interface for XenApp / XenDesktop; you have two options Creation and Delivery. Creation – Studio / Delivery – StoreFront / NetScaler:

4th

Management interface for Studio. Notice the Citrix Receiver icon in the middle. Studio is provided through the Citrix HTML 5 receiver. Interesting touch.

5th

Management for Citrix NetScaler / StoreFront:

6th

AWS Configuration for demonstration purposes:

7th

Color coded

8th

Delivery group configuration:

9th

11th

There is only one XenApp host in each delivery group. This is to determine the maximum amount of users for one M4.

2XLarge instance backing the XenApp host. We are delivering Office 2016 applications, and the standard set of VSI Knowledge worker actions.

It is very easy to change the instance type in EC2. You simply select the “Instance” and change the “Instance Type” through the context menu.AWS_Change_Instance_Types

There are a variety of different configuration, which allows you to really get the most out of the testing. If you are aiming for user density numbers you can size it exactly. This allows you to pay for EXACTLY what you need as opposed to over provisioning. This will help drive the cost of VDI / SBC deployments down ultimately, and increase end user experience quality.

If you are sizing your images with Login VSI and backing them up with EC2 AWS instances you are getting an optimal user experience exactly sized right for your needs.

Information on instances:

https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-types.html

VSI Results

12th

Testing Configuration

For our testing purpose we provisioned a m4.2xlarge machine on EC2. This instance has a machine profile of 8 vCPU and 32 GB of memory. This is either running a XENO E5-2686 or 2676. Mostly a general use machine which is balanced.

Our testing configuration was 50 test users over the course of 48 minutes. We utilized the industry standard Knowledge Workload. This mostly presents a large portion of the VDI / SBC user base. Office application and standard office applications like Adobe Reader.

 

Application start times are all over the place for the most part, but staying for the most part under 12 seconds. Which would be reasonable for the users. Login process takes under 16 seconds even under VSI Max settings.

 

What does the backend look like?

16th

When the CPU is at 100% the VSIMax is being reached within the user session. This means the numbers are indicating the bottleneck to be the CPU provisioned for the M4.2Xlarge instance which is approximately.

Wrap-up

Seeing is believing and after testing it I can confirm that Amazon EC2 is ready for the prime time. We were able to support 42 concurrent users on a M4.2Xlarge and we were able to have a continuous level of excellent user experience while doing so.

Amazon is ready to supplement your traditional on premise solutions with readily available and quickly scalable resources in the cloud. Using Citrix Cloud services you can very easily scale your delivery out to support your user base as it dynamically changes.

Using VSI you can validate your configurations with support your users and put a check box next to user experience.

Using these three solutions you can future proof your company, and deliver on a promise of value & experience

Finally, if you are looking for some testing for your deployment please reach out to me here or b.martynowicz@loginvsi.com.

As always stay tuned for more results.

Advertisements

ISS Roles Required for Citrix Desktop Director


Desktop Director runs on top of Microsoft IIS. The below are the IIS roles required for Desktop Director to function properly.

 

  • Web Server > Common HTTP Features >
Static Content
Default Document
HTTP Errors
HTTP Redirection
  • Web Server > Application Development >
ASP.NET
.NET Extensibility
ISAPI Extensions
ISAPI Filters
  • Web Server > Health and Diagnostics >
HTTP Logging
Tracing
  • Web Server > Security >
Request Filtering
  • Web Server > Performance >
Static Content Compression
Dynamic Content Compression
  • Web Server > Management Tools >
IIS Management Console
Management Service
  • Web Server > Management Tools > IIS 6 Management Compatibility
IIS 6 Metabase Compatibility

Tweaking Netscaler for XenApp/XenDesktop via TCP Profiles


I have recently come across this super blog from Citrix folks on the NetScaler Traffic Management classes. I thought i would rather add this in my blog for easy reference.

NetScaler has a highly scalable TCP stack which is built to take care of varying network conditions and various types of clients/servers. In any communication channel over TCP what makes difference is the client side stack, server side stack, intermediaries and network conditions. Beyond these core aspects the application layer as well impacts with the nature of application, size of request/response and how it makes difference to TCP connection characteristics.

For most cases what we have in default TCP stack holds well but if you know more about your application, client/servers and network conditions then you can use one of the built-in TCP profiles. These TCP profiles have fine-tuned TCP parameters which make significant difference in terms of lower latency, faster response time and better bandwidth utilization in given Application and network environment. NetScaler also allows you to create your own TCP profiles with these core TCP parameters which can optimize the TCP stack for your deployment. The TCP profile can be used globally which has system wide impact and it can also be used per vserver and service to localize the impact. Which means you can have different virtual TCP stacks for multiple vservers and services within same NetScaler, isn’t it really interesting?

The built-in profiles are aimed at common deployment scenarios based on different network and application characteristics. Let us understand the system supplied built-in TCP profiles:

 

  • Nstcp_default_profile
    • Default TCP profile impacting system globally
    • Any changes impacts the global TCP settings
    • Does not need to be bound to explicit vserver/services
    • Gets overridden by the vserver/service level profiles
  • Nstcp_default_tcp_lfp
    • This profile is recommended to be used in networks with
      • High bandwidth
      • Low packet loss
      • High Round-Trip Time (RTT)
    • Suitable for WAN kind of environments
    • Useful when there is dedicated bandwidth
    • Enterprise use cases across WAN
  • Nstcp_default_tcp_lnp
    • This profile is recommended to be used in networks with
      • Low bandwidth
      • High packet loss
      • High Round-Trip Time (RTT)
    • Suitable for WAN kind of environments
    • Useful when there is restricted bandwidth
    • Online use cases across WAN in shared bandwidth
  • Nstcp_default_tcp_lan
    • This profile is suitable for the LAN
    • Mostly to be used with servers in same datacenter
    • Useful when access is limited to same local network
  • Nstcp_default_tcp_lfp_thin_stream
    • Similar to Nstcp_default_tcp_lfp
    • Tuned for Small packets flow
  • Nstcp_default_tcp_lnp_thin_stream
    • Similar to Nstcp_default_tcp_lnp
    • Tuned for Small packets flow
  • Nstcp_default_tcp_lan_thin_stream
    • Similar to Nstcp_default_tcp_lap
    • Tuned for Small packets flow
  • Nstcp_default_tcp_interactive_stream
    • This profile is recommended to be used with
      • Chatty applications like telnet
      • Application virtualization environment
      • Small packet and quick feedback based Apps
    • Should work with different kind of networks
  • Nstcp_internal_apps
    • This profile is recommended only for Internal services
    • Should not be used for any other network service

Full credit to Citrite “Abhilash Verma” for taking time to write this stuff and the original writing could be found here