How to Implement High Availability Features in XenDesktop 5
This article describes High Availability (HA) features new to XenDesktop 5 and how to implement them.
This article is for single farm deployments.
Background
XenDesktop 5 includes quite a few technology changes from previous versions and as such this article shows some of the new features as well as using XenDesktop with other Citrix products to create an HA environment. See CTX127563 – Disaster Recovery Guide for XenDesktop 5 using NetScaler for how to use XenDesktop 5 within a Disaster Recovery configuration.
XenDesktop HA Features
Features specific to XenDesktop 5 include:
- High Availability features in the Virtual Desktop Agent
- No zone master controller
The High Availability feature in the Virtual Desktop Agent (VDA) allows users to connect directly to the VDA should the controllers fail. In this mode, the VDA accepts direct ICA connections from users, rather than the normal connections brokered by a controller. This feature is designed for use on the rare occasion that a controller fails and is not an alternative to other forms of HA. Note the following limitations. VDA HA only works with dedicated desktops; it cannot be configured to work with pooled desktops.
Some normally available features become unavailable:
- User Roaming. The desktop only accepts one connection and does not allow connections from another device while connected.
- Power Management. The desktop powers up, attempts to register with the controller, and once the registration fails, then enters HA mode.
- Controller originated policies. Because HA mode is only triggered by a failure to register with a controller, it is not possible to apply controller based policies. Domain controller and Local Group Policies are unaffected.
- Access Gateway and Remote Access
HA mode persists for 30 days then the desktop is no longer be available.
The XenDesktop 4 zone master no longer applies to XenDesktop 5. This means that there is no longer a single point of failure for desktop brokering. Controllers communicate directly with the database and not with each other. This means a single controller failure has no effect on other controllers but also means that the database becomes a single point of failure. If the database server fails, existing desktop connections continue to function; however, once a user logs off or disconnects, the user cannot re-connect. It also means new connections fail. See the SQL HA section for increasing resilience of SQL server.