VMware Horizon

Debunking the 5+2 Myth About Horizon View Connection Servers

By Frank Taylor, Lead Architect for VMware Horizon View, VMware

Executive summary

5+2 is a sizing model for VMware Horizon View Connection Servers, not a deployment model. Always make all your View Connection Servers live. Don’t deploy any as standby servers. That’s more effort for less gain.

vmware-horizon-view-debunk-cluster-myth-5-plus-2

Longer story

It’s surprising how folklore can build up. How something said years ago in a meeting in one context can be the taken as fact in a different context.

The folklore in question for this article is related to sizing a View Connection Server cluster. Word on the street is that the right way to deploy Horizon View at full scale is to have five live View Connection Servers and two “disabled” spares. These two are running, but not used to service users. However, they are ready to swing into action should one of the five live servers fail.

It all sounds feasible, but is it really the best way to work?

For a start, how do the servers swing into action? It sounds like some administrator operation is needed. A resiliency solution that needs manual intervention is not that desirable.

So let’s unpack this a little to see how this folklore came about and what the right answer is.

Horizon View supports 10,000 users per cluster, or pod as they are called in our reference architectures. Each View Connection Server is rated to support 2,000 concurrent users. So to build a 10K user environment, you need five View Connection Servers.

However, this does not take failures into account. Should one of these servers fail, you would end up needing to service 10K users with only four servers, which would theoretically leave the remaining servers overloaded.

To avoid this, you deploy an additional View Connection Server. A spare. Great! Five servers to handle the base load plus one spare to provide failover capacity: 5+1.

If you take the +1 spare to mean a standby server, this opens up several questions: How do I ensure my standby server is working? How do I detect a failure in one of my live servers? How do I change my configuration to make the standby server live? Who will do this at 2:00 a.m. when the pager goes off?

There is no need for all this. To make life simple, you should just deploy all six servers live and balance the load across them all. There is no better way to determine if a service is running than to actually use it. Now you have 10K sessions being load-balanced across six servers, each one handling approximately 1,666 sessions. Now if one fails, your remaining five servers can handle the full 10K load without being overloaded (each server handling 2,000 sessions).

But this article is about 5+2, not 5+1. What gives?

Typically, Horizon View is deployed with users connecting from both the internal network and from the Internet. Further, most organizations have different authentication policies when connecting from the Internet compared to the corporate network. External users may need to use two-factor authentication, whereas internal users need only use their AD password. Horizon View handles this by dedicating View Connection Servers either to handle internal traffic or external traffic and configuring these servers to require different authentication types.

If you expect 20 percent of your 10K users to come in from the Internet, then you can dedicate one View Connection Server for the Internet (for 2K concurrent users) and then leave the remaining four to handle the internal traffic (for 8K concurrent users). As before, if any of these servers fails, then the remaining ones will become overloaded. In fact, for the Internet channel there will be no remaining server. So you should deploy one extra server for each channel: 1+1 for the Internet channel and 4+1 for the internal channel. This leaves you with 5+2 in total for a 10K-user environment. Aha! The magic numbers!

As before, there is no need to place these spare servers on standby. They may as well be fully live: two Internet-channel servers and five internal-channel servers.

Now the confession: This confusion may have resulted from something I said about four years ago in a meeting! We were planning our scale testing. We wanted to show a full 10K pod in operation. We also wanted to ensure that as the cluster size grew above five View Connection Servers, cluster management overheads did not cause problems. But we didn’t want to do two separate tests due to time, money, etc. So I suggested we deploy seven servers, but only have five of them take user load. That way, we’d max out five servers at 2K users each, but have a seven-server cluster. This was a strategy to get two test results out of one test, not a strategy for how you deploy Horizon View in production.

Over time this test description has passed into folklore until we are where we are today.

So, let’s debunk it here and now: 5+2 is a sizing model, not a deployment model. If you have a View Connection Server in the cluster, you should use it to handle user load. Don’t leave it as a standby.