Beware of VDI Defaults
Default configurations are great in that they make the setup and configuration easy. Unfortunately, they don’t work for all environments. In fact, if you simply use the defaults for an entire virtual desktop deployment, you will miss out on tons of optimizations to allow your environment to scale. Simply following the defaults is the 2nd most common mistake people make when implementing XenDesktop. The other 8 discussed so far are:
Let’s look at the XenDesktop controllers. At a high level, the XenDesktop controller is responsible for:
- Authenticating users against Active Directory
- Enumerating available resources
- Creating registrations for newly started virtual desktops
- Maintaining an active heartbeat with online virtual desktops
When XenDesktop is installed, many architects fail to optimize the controller and simply install with default configurations (farm master, XML broker, Web Interface). This configuration is perfectly reasonable. XenDesktop can function with a single controller (this is the configuration I have in my own lab). However, during boot and logon storms, where hundreds or thousands of users connect to the environment in a short amount of time, the controller can become a bottleneck.
The controller bottleneck can result in long logon times or even denied service. By separating controller functionality across multiple servers, the overall XenDesktop farm can support more virtual desktops and respond faster.
First, all XenDesktop implementations should have redundant controllers to provide fault tolerance. For environments that are expected to scale into the thousands of hosted VM-based VDI desktops, it is often recommended to separate the controller functionality across a minimum of five servers all of which can be virtualized. The role designation across the five servers would be as follows:
|Master Controller||The master controller is in charge of the overall XenDesktop farm operations. It also maintains the correct number of idle desktops within the workstation groups by communicating with the virtualization layer (XenServer, Hyper-V or ESX).
If the Master fails, a secondary, dedicate server can be used. If one is not defined, one of the XML brokers will be used.
|Specify the XML controllers as backup controllers by modifying the registry:
To disallow the Master controller from accepting virtual desktop registrations, modify the following registry key:
|XML Controller (x2)||The XML controllers are responsible for registering virtual desktops, authentication and enumerating users.||Configure Web Interface to use the XML Controllers as the farm servers. This will only use these two servers for authentication and enumeration activities.
Specify the XML controllers as backup controllers by modifying the registry:
|Web Interface (x2)||The Web Interface servers provide the end user interface for authentication and desktop access.||Configure Web Interface on redundant servers t offload the processes from the Master and XML Controllers.|
By separating out the controller roles into three roles across five virtual servers, a XenDesktop farm is able to host 5,000+ hosted VM-based VDI desktops. Of course the maximum number for any implementation is based on numerous factors like logon rates, acceptable logon time, and hardware. What if you are creating a farm that is less than 5,000 desktops but more than 2,000 and you are looking at reducing the numbers of servers? The best option would be to combine the XML Controllers and Web Interface servers.
But in the end, the point to remember is that you need to optimize your environment and done just rely on the defaults.
Daniel – Lead Architect
Posted on July 26, 2010, in Top 10 Virtual Desktop Mistakes and tagged best practices, citrix, design considerations, desktop virtualization, optimization, vdi, xendesktop. Bookmark the permalink. 4 Comments.