XenApp 6.5 Hosted Shared Desktop sizing example

In this blog series I’m taking a look at scalability considerations for XenApp 6.5 Hosted Shared Desktops, specifically:

1. How to estimate XenApp 6.5 Hosted Shared Desktop scalability
2. What’s the optimal XenApp 6.5 VM specification?
3. XenApp 6.5 Hosted Shared Desktop sizing example

My last post provided guidance on the optimal XenApp virtual machine specification.  Now in the last post of the series, I’m going to walk through an example sizing exercise.

Scenario

Company ABC recently completed a user segmentation exercise.  The following table includes 8 user groups that have been identified as good candidates for a Hosted Shared Desktop.  None of these user groups requires the ability to install applications or the ability to customize their desktop beyond profile based changes.  Three separate Provisioning Services images will be created due to application compatibility conflicts identified by Citrix AppDNA.

With Hosted Shared Desktops, it is important to consider the ‘Maximum Number of Concurrent Users’ column rather than the ‘Total Number of Users’ column.  Sizing the environment for concurrency rather than the total number of users will help to reduce infrastructure costs without affecting performance or availability.

Sufficient redundancy should be incorporated into the sizing estimate so that a single XenApp server or virtualization host failure does not affect the total number of concurrent users that can be supported (n+1).

Company ABC wishes to use their standard hardware specification – 2 sockets x 8 physical cores (16 physical cores / 32 virtual cores) with 128GB of memory.  Citrix XenServer will be used.

Number of XenApp Virtual Machines

Based on the scenario described above we need to size the Hosted Shared Desktop environment so that it can support 750 light users and 1,100 normal users.  Since multiple Provisioning Services images are required, we’ll need to calculate the number of virtual machines required for each one.

First, we need to identify two values from the second blog post in this series:

1. Value for converting light users into normal users (0.5)
2. Number of normal users that can be hosted on a single XenApp server virtual machine when using a 2 socket virtualization host (24)

Image 1 (700 light users & 50 normal users)

Step 1: Convert all users to a normal workload

• 700 light users * 0.5 (from blog 2) = 350 normal users
• 350 normal users + 50 normal users = 400 normal users

Step 2: Determine number of XenApp virtual machines

• 400 normal users / 24 = 17 XenApp virtual machines
• 17 XenApp servers + 1 server for high availability (n+1) = 18 XenApp servers

Image 2 (50 light users & 750 normal users)

Step 1: Convert all users to a normal workload

• 50 light users * 0.5 = 25 normal users
• 750 normal users + 25 normal users = 775 normal users

Step 2: Determine number of XenApp virtual machines

• 775 normal users / 24 =  33 XenApp virtual machines
• 33 XenApp servers + 1 server for high availability (n+1) = 34 XenApp servers

Image 3 (300 normal users)

Step 1: Convert all users to a normal workload

• Not necessary as all users are already normal

Step 2: Determine number of XenApp virtual machines

• 300 normal users / 24 = 13 XenApp virtual machines
• 13 XenApp servers + 1 server for high availability (n+1) = 14 XenApp servers

Therefore, a total of 18 + 34 +14 = 66 XenApp virtual machines will be required.

Number of Virtualization Hosts

If we refer back to the second blog post in this series, it tells us that each 32 virtual core server with 128GB of RAM can support 8 x 4 vCPU XenApp server virtual machines:

32 virtual cores / 4 virtual cores per XenApp virtual machine = 8 XenApp servers per virtualization host

Therefore, we will need a total of 9 XenServer hosts to support 66 XenApp server virtual machines:

66 XenApp server virtual machines / 8 virtual machines per XenServer host = 9 virtualization hosts

As n+1 high availability is required we need to increase the number of XenServer virtualization hosts required to 10.  The XenApp load balancing functionality will be used to distribute users between the XenApp virtual servers in each worker group.

Memory Requirements

Referring back to the second blog post in the series, it tells us that each XenApp server on a 2 socket virtualization host typically requires 12GB of memory.  Therefore, 8 virtual XenApp servers x 12GB = 96GB.  We also need to reserve an additional 752MB for XenServer.  Because we have 31GB of physical memory left over, we’ll increase the memory allocated to each XenApp server by 3.5GB to 15.5GB – just in case it is required.

Disk Input / Output Operations per Second

If we refer back to the second blog post in this series, it tells us that each light user requires 2 steady state IOPS and each normal user requires 4 steady state IOPS.

Local Storage

It is difficult to estimate IOPS per XenApp server for local storage when using mixed workloads because we don’t know how the different workload types will be distributed across the virtualization hosts available.  Therefore, we should estimate a worst case scenario, which in this case is a normal user:

24 normal users per XenApp virtual machine x 4 IOPS = 96 steady state IOPS per virtual machine

8 XenApp server virtual machines per virtualization host x 96 steady state IOPS = 768 steady state IOPS per virtualization host

To achieve this number of IOPS on local storage (spinning disks), we’re going to need multiple disks in a RAID 10 configuration and a battery backed write-back cache.  With the help of a 1GB plus cache we’ll probably need at least 4 local disks, 6 to be safe.

Shared Storage

The shared storage solution will need to be capable of supporting a total of:

750 light users x 2 IOPS = 1,500 steady state IOPS

1,100 normal users x 4 IOPS = 4,400 steady state IOPS

1,500 + 4,400 = 5,900 steady state IOPS

And that’s the final step in this sample exercise. I hope this helped to explain how to size the hardware requirements for Hosted Shared Desktops.

Source: Citrix's Blog