XenDesktop 5 Scalability – XenDesktop Controller Capacity


Think about the architecture of XenDesktop 5. One of the core components responsible for an acceptable user experience during the initial authentication and launch of the virtual desktop are the controllers. If these controllers get overloaded, it will take users longer to launch their virtual desktops. What is acceptable is based on the users and their requirements. But for this example let’s say when we hit the icon for the virtual desktop we expect a response within 2 seconds. How many controllers do I need for 5,000, 10,000, 15,000 or even 20,000 users? It really boils down to the logon storm and the controller hardware. The more powerful your hardware is; the greater of a storm a single controller can tolerate.

But what is the bottleneck when you need to add a new Controller? CPU is the easy one. How heavily loaded are the CPUs. As the utilization increases, the time it takes to handle logon requests will slow down to a point where users notice. So what about the user experience? We want to make sure the system responds to user requests in a timely manner. How long are your users willing to wait for enumerations or launches? I typically see 2 to 2.5 seconds is a safe estimate. I suggest you track the following metrics:

Citrix XML Service

  • Enumerate Resources (Avg Transaction Time)
  • Launch Get Address (Avg Transaction Time)
  • Get Logon Ticket (Avg Transaction Time)

As this reaches your own threshold, it is time to think about adding a new controller, which will help offload the controller.

Adding a new controller to XenDesktop 5 is much easier than previous versions. In XenDesktop 5, each controller is identical (unlike XenDesktop 4 where we did all sorts of crazy things to get the most desktops per farm). So as your CPU increases and your response times slow, add a new controller into the site and the load is distributed evenly.

Estimates are always good, but as with all estimates, your own experiences will vary:

  • In one test, a single controller with 8 CPU cores was able to support 10,000 logons in the course of roughly 15 minutes (roughly 11 simulated users per second) averaging about 50-60% CPU utilization.
  • In another test, a single controller with 2 vCPUs was able to support 1,250 logons (roughly 40 users per minute) resulted in an average of 12% CPU utilization.

So what does this all mean? For XenDesktop controllers, the scalability is better than what we saw in XenDesktop 4. And because we are not constrained by a master controller like we were in XenDesktop 4, our XenDesktop 5 sites can be even larger than before.

But this isn’t the end of planning your capacity with XenDesktop 5. There is still much to discuss so stay tuned for more.

Daniel – Lead Architect
XenDesktop Design Handbook

Advertisements

5 thoughts on “XenDesktop 5 Scalability – XenDesktop Controller Capacity”

  1. Nice blog, but that brings many other potential architecture design questions that come to mind. One of them being about the other bottle necks such as the network infrastructure, do you have multiple subnets and multiple controllers and/or multiple controllers per subnets? I guess that would depend on the actual number of virtual desktop per subnet.

    To meet your referenced numbers taking the first number 5,000 virtual desktops you would need a single subnet of 255.255.224.0 a /19 (total of 8190) or you could have 5 subnets of 255.255.252.0 a /22 (total of 1022 max hosts). So taking this into account wouldn’t you have multiple controllers on the one giant subnet or multiple controllers per subnet? Of course making sure to looking to logon storm by having the available virtual desktops waiting for the users when they login and optimize your controller(s).

    Then there is also placement of the PVS servers, do you have 1 PVS Server per subnet multiple PVS per subnet or multiple PVS spanning multiple subnets (dual homing). Unless you elect for the MCS option, which would bring up whole other subject on storage.

    What you recommend on the subnet scenario?

    Like

    1. I have similar network/IP questions with regards to best practice, # of VMs that should go on subnets, if PVS is OK traversing network routers, etc. Interested in hearing a word on this kind of design too.

      Like

    2. Eric – did you every got any information back re subnet recommendations, specifically re PVS dual-homing? I have determined that the built-in TFTP service only supports binding on a single IP address but it appears that PVS itself can/will listen on multiple subnets.

      Like

  2. I would also caution you on the use of such a large subnet. When you have that many host you run into performance issues caused by the amount of broadcast traffic generated by that number of VM’s. If you can, I would recommend looking at creating /23, and no larger.

    Like

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s