Monthly Archives: February 2012
How many desktops can a XenDesktop 5.x site support? I get asked this question a lot. Tests have been done showing that a site can support 10,000, 20,000 or more desktops. But my question is if it really matters. After a certain number, I always am left to wonder if putting that many desktops in a single site is really a good idea. It all comes down to what level of risk you are willing to take. Let me go through what I mean
- Host Risk: At the base level, we have a hypervisor host (XenServer, Hyper-V or vSphere). Depending on the hardware and user workload, I’ll be running somewhere between 50-100 virtual Windows 7 desktops on each host. If the host has a catastrophic failure, those desktops go offline. Users will try to reconnect and they will be sent to other hosts. This is why we recommend N+1 at a minimum. If you lose one host, you should have at least one extra one to take over. If you lose a host, you can expect most of those users to try to reconnect immediately. Trying to support 50-100 connections is easy.
Pool/Cluster Risk: One level higher than the host is a group of hosts in a pool or cluster. You will probably have around 800 desktops in a pool/cluster if we assume you have 10 hosts in a cluster. What happens if we lose the cluster? Depending on the type of failure, you will have one of the following:
- Connection Failure: If you have a failure where the pool/cluster controller fails, you won’t be able to launch new desktops, but currently active users will be unaware of any issues.
- Pool/Cluster Failure: If you lose an entire pool/cluster, you have to find a place for those 800 desktop users. Again, if you have N+1 fault tolerance, you probably have spare capacity within your entire environment. You also need to make sure your infrastructure can support 800 users trying to connect simultaneously. This still isn’t that big of a connection storm.
- XenDesktop Site Risk: One level higher that the pool/cluster is a XenDesktop Site. A site could contain 20,000 desktops or more. But what happens if we lose an entire site for some unknown reason? This is rare, but anything can happen. Remember, once users are connected, they can work unless their host fails. But if the site experiences a catastrophic issue during the logon storm we should have an N+1 fault tolerant solution, which means we have to find a place within our environment to support 20,000 extra desktops that will only be used for fault tolerance.
Hopefully, this all makes sense so far. But 20,000 desktops is a huge number. The amount of hardware required to support an N+1 solution for 20,000 desktops is a lot. What if we create four XenDesktop sites with only 5,000 desktops? I’m still supporting 20,000 desktops, but because they are in different XenDesktop sites, the overall risk is greatly reduced. If something happens to one site, it shouldn’t impact the other three sites. Those 5,000 users in the failed site can be balanced across the other sites or into a 5th site that is only used in the event of a major failure (active/passive deployment).
A comment I always hear with this approach is now I have to manage 4 or 5 XenDesktop sites. You do have to manage more sites, but you really aren’t managing additional components. With proper processes and scripts, many of these management tasks can be simplified.
Just because XenDesktop 5.x can support tens of thousands of desktops, you need to determine if that is indeed the best approach for your business.