Ok, tell me if you’ve heard this one before? How big can my XenDesktop farm be? The response is “It depends. . . Blah, blah, blah”

I’ve had many people ask me this exact question. I don’t like saying “it depends”, but it really does.  But how can anyone design their XenDesktop environment with an “It Depends” answer?  Well, the answer to that is It Depends Enough joking around. Let’s take a look at XenDesktop and understand what goes into approximating the size of the farm.

The one component that will have the greatest impact on the size of a XenDesktop farm is the XenDesktop controller. The Controller is used to:

  1. Maintain proper level of idle desktops (in hosted VM-based model)
  2. Monitor the state of virtual desktops (idle, online, offline, in use, etc) for hosted VM-based VDI and hosted Blade PCs.
  3. Authenticate users
  4. Enumerate virtual desktops for the user
  5. Connect a user to their appropriate virtual desktop

Now that we know the determining factor is the controller, one would think that it would be easy to figure out the max size of the farm.  One thing we need to completely understand is that there is no number at which point the XenDesktop farm will simply stop functioning.  There is no defined limit.  The limit is defined based on the environment like:

  1. XenDesktop Controller Architecture: Is the XenDesktop Controller implemented as a single server or are the functions split across multiple controllers?
  2. Logon storm: How fast and long will users logon during the start of a shift or a workday. I discussed this in a previous blog.
  3. Logon Latency Acceptance: How long will a user accept their long time being?  10 seconds? 20 seconds? 60 seconds?

Controller Architecture

Looking at different implementation examples, I know that one will get the best logon speeds and farm sizes by separating out functionality within the controller.  For the large XenDesktop implementations, we recommend 3 controllers:

  1. Master: Responsible for idle desktops and connecting users to a desktop
  2. Brokers (x2): responsible for authentication, enumeration and virtual desktop state monitoring

By separating out theses loads, I’ve seen farms scale over 5000 hosted VM-Based desktops. Read about this architecture in the Modular Reference Architecture for XenDesktop.

Logon Storm

Like I stated earlier, the logon storm will have an impact on the environment.  During a storm, users will authenticate, enumerate, and connect to their desktop. For each connection that is made, a new idle desktop must take the place of previously idle desktop.  As you can see, by separating the XenDesktop Controller functionality across multiple systems, the logon storm’s impact is spread across multiple systems, thus helping to negate the impact. The impact of the storm is explained in the blog How User Patterns Impact a Desktop Virtualization Infrastructure

Logon Latency

How long are you willing to wait for a logon to complete?  As the number of users connecting during a logon storm increases, the logon latency will also slowly increase. At some point, the logon latency will become too great for users to accept.  At that time, it is often appropriate to start distributing your load across multiple XenDesktop farms.

OK, OK, Just give me the answer!!!

So how big can my XenDesktop farm be?  2,000-20,000 users. 

  1. Smaller: If I don’t separate out my controller functionality, and have thousands of users connecting within a short duration, and expect sub-10 second logon times, my farm size will be limited in size
  2. Larger: If I separate out my controller functionality, have tens of thousands of users connecting over 1 hour,  and my users will accept 20-40 second logon times

When you are asked about how large can your XenDesktop farm be, you need to ask a few questions before you can give an educated guess:

  1. Will we be able to separate out our controller functionality?
  2. How many users do you expect to login within a 10 minute period?
  3. How long will users accept their logon times becoming?

I’ve seen logon rates of 2,000 users in 10 minutes, with separated controller functionality and 20-30 second logon times occurring in XenDesktop farms of 5,000-6,000 users. 

I hope this helps shed some light on how big is too big for your virtual desktop infrastructure.



Daniel

Lead Architect – Worldwide Consulting Solutions

Follow Me on twitter: @djfeller

Blog for Next-Gen Desktop: Ask The Architect

Questions, then email Ask The Architect

Facebook Friends: Ask The Architect