Worldwide Consulting Solutions | WHITE PAPER | Citrix XenDesktop

High Availability for

Citrix XenDesktop and XenApp
Planning Guide for High Availability

www.citrix.com

Overview ............................................................................................................................................................. 3
Guidelines ........................................................................................................................................................... 5
Hardware Layer .........................................................................................................................................................5
Control Layer .............................................................................................................................................................7
XenDesktop Controllers .........................................................................................................................................7
XenApp Controllers ................................................................................................................................................7
Provisioning Servers ..............................................................................................................................................8
License Server ........................................................................................................................................................9
SQL Servers ..........................................................................................................................................................10
Active Directory and DNS services .......................................................................................................................10
DHCP Services ......................................................................................................................................................10
XML Service .........................................................................................................................................................10
Virtual Desktop Agent (VDA) ...............................................................................................................................11
Desktops Layer.........................................................................................................................................................12
OS Image ..............................................................................................................................................................12
Applications .........................................................................................................................................................13
Personalization ....................................................................................................................................................14
Access Layer .............................................................................................................................................................14
Web Interface ......................................................................................................................................................15
StoreFront Server ................................................................................................................................................15
NetScaler/Access Gateway ..................................................................................................................................15
Users Layer ..............................................................................................................................................................16

Planning .............................................................................................................................................................17
Product Versions..............................................................................................................................................19
Revision History ...............................................................................................................................................19

Page 2

Overview
As organizations deploy desktop virtualization to ever increasing numbers of end-users, ensuring
that the XenDesktop architecture is highly available becomes more critical to delivering
uninterrupted service. High availability (HA) solutions ensure that within a given configuration,
single points of failure are eliminated, and failover between redundant components is as seamless as
possible, in order to maintain service and deliver the required user experience. With a XenDesktop
or XenApp solution, the five major layers of the infrastructure model need to be considered to
deliver a highly available solution are as follows.

Figure 1: Infrastructure Layer Model

Hardware: The hardware layer includes the physical hardware devices and hypervisor
technologies that form the basis for XenApp and XenDesktop delivery.

Control: The control level covers all of the individual components required to manage the
delivery of desktops to users, which includes XenApp and XenDesktop Controllers,
Provisioning Servers, License Servers, SQL databases, Active Directory, DHCP and DNS
components.

Desktops: The Desktop layer focuses on the desktop image, optimizations, and the delivery
mechanism. It is subdivided into three components:
o OS Image
Page 3

o Applications
o Personalization

Access: The access layer contains the components used to access the Citrix environment:
NetScaler, Access Gateway, Web Interface and StoreFront services.

Users: The user layer encompasses the users who access the Citrix system and the support
tier to provide help for said users.

This white paper focuses on creating highly available XenDesktop and XenApp architectures within
a single datacenter, based on the XenDesktop Modular Reference Architecture. Disaster recovery
requirements are not considered within this document. The document covers the following key
areas:

Guidelines: How do the various layers impact desktop availability? Building the layer
cake of hardware, control, desktops, access and users. What are the impacts of a
component or service failure?

Planning: What are the design decisions for creating a highly available infrastructure across
the components and services required to deliver XenApp and XenDesktop?

To help architects design a XenDesktop and XenApp solution based on real-world projects,
organizations can refer to the Citrix Desktop Transformation Accelerator for step by step
assessment, design and deployment guidance, and the XenDesktop Design Handbook for reference
architectures, planning guides and best practices.

Page 4

Guidelines
When delivered via XenApp and XenDesktop, a users desktop environment is built around the
aforementioned five distinct layers. In order to provide a resilient solution, each one of the desktop
layers must be highly-available. The focus of this whitepaper is on delivering high availability for
XenApp and XenDesktop environments, with guidelines for each layer. As infrastructures start
with a build of the hardware, and work up to user and user access, the discussion on high availability
of the layers will take a bottom up approach with each layer building upon the last.

Hardware Layer
Within the hardware layer, two things must be considered; redundancy at the physical hardware
level and high availability at the hypervisor level. From a physical hardware perspective,
Architects should ensure that there is redundancy across all major hardware components to avoid
single points of failure within the datacenter. Considerations for hardware redundancy include:

Redundant backplane on blade chassis or redundant chassis

Redundant power supplies and fans

Uninterruptible power supplies (UPS)

Multiple, diversely routed, network interfaces and switches, link aggregation

Multiple fiber connects/HBAs

Hardware RAID levels for disk subsystems

ECC memory

Hardware Monitoring

Once the redundancy requirements of the hardware has been met, the next step is to deliver a
highly available hypervisor platform in order to ensure that the virtual desktops, XenApp servers
and control layer components will run reliably. While this whitepaper deals with terminology
specific to Citrix XenServer, all major hypervisors used in desktop virtualization have similar
functionality with respect to HA features. Having sufficient redundancy in the hypervisor
infrastructure will allow the XenDesktop and XenApp architecture to continue to operate in the
event of a failure of a hypervisor server due to hardware or software problems. Typically N+1
redundancy allows for operation in the event of a single server failure.
In a XenServer environment, pools of hypervisor servers are created to protect virtual machines.
A HA pool ensures that mission critical virtual machines are continuously operating. High
Availability features at the hypervisor level are used to reliably detect if a hypervisor host has
failed, and computes a failover plan to deal with rapid recovery. Several elements go into the
pool solution to detect failures and address recovery:
Page 5

Heartbeats: Heartbeat mechanisms through the storage and network components of the
hypervisor solution are used to monitor the health of hosts and trigger a failover scenario
in the event that a host is unreachable. Multiple redundant heartbeat paths are used to
ensure that a false positive scenario is not created where a server is taken out of service
while it is still functioning properly. When a pool is created with two hypervisors it is
important to understand the implication of a loss of heartbeat communication between
the hypervisor servers. Details on this topic can be found in the Citrix support article
CTX129721.

Failover Plans: Hypervisor pools maintain a failover plan which details what to do if a set
of hosts in a pool fail at any given time, and calculate whether a pool has enough
redundancy to fail over virtual machines, or if the pool is overcommitted, and failover is
not possible. In XenServer, failover plans are dynamically created; there is no specific
action required. Administrators will be notified through alerts to the console or through
e-mail if a pool is deemed to be overcommitted, and can take action to maintain sufficient
redundancy within the pool to allow for high availability functions.

Restart Priority: Restart priorities determine the order in which the hypervisor attempts
to start virtual machines when a failure occurs. This allows some granular control on
which virtual machines start when a failure occurs. With XenServer, restart priorities can
be set to levels 0-3 and best-effort, where all machines with priority 0 start first, and then
VMs with priorities 1-3 and best-effort will attempt to start sequentially. Virtual
machines can also be configured to not restart after a failure. In a XenDesktop or
XenApp environment, infrastructure servers and dedicated desktops can take advantage
of restart priorities to ensure that these elements are available should a hypervisor server
fail. Pooled and streamed virtual desktops are controlled by the XenDesktop
infrastructure, and should be set to not restart after a failure.

XenMotion: XenMotion can be used to address imminent failures where a hypervisor

server needs to be taken offline to address an issue by allowing a running virtual machine
to be migrated to another XenServer within the same resource pool without disrupting
the user. In many XenDesktop architectures, only the infrastructure components
utilizing shared storage are protected with XenMotion while the virtual desktops are not,
as XenMotion cannot be used for some desktop delivery infrastructures, such as Machine
Creation Services with IntelliCache.

For more information on high availability with XenServer, refer to the Citrix support article
CTX119717 XenServer High Availability. Of course, it is also recommended that high
availability of the network and storage components be considered when designing and
building a hosting platform for virtual desktops. While beyond the scope of this whitepaper,
Citrix has developed best practices for planning and designing storage for XenDesktop.
Network infrastructure should always be deployed with redundant configurations, from the
server side (redundant NICs) through to the end user infrastructure to avoid single points of
failure.
Page 6

Control Layer
The Control layer provides the foundation to host virtual desktops, containing the infrastructure
needed to support the delivery of the XenDesktop and XenApp solution. Within the control
layer, each component should be highly available, to avoid a single point of failure which could
impact the environment. For XenDesktop and XenApp architectures, the following
infrastructure servers and services need to be considered:
XenDesktop Controllers
XenDesktop Controllers are responsible for managing the level of active and idle virtual
desktops and monitoring the state of online and connected desktops. A XenDesktop
Controller must be available to facilitate the connection of a user to their appropriate
desktop. Each XenDesktop Controller also contains the XML service, which is responsible
for authenticating users (when Citrix Web Interface is used), and enumerating resources.
High availability for the XML Broker service is detailed below. In a XenDesktop
environment, multiple controllers will automatically load balance to deliver a highly available
solution for this component. Providing N+1 redundancy based on the user load will ensure
that the XenDesktop Controller services are available for user connections.
XenApp Controllers
The XenApp Controller infrastructure consists of two components that manage connections
to hosted shared virtual desktops and virtualized applications. Zone Data Collectors (ZDCs)
maintain dynamic information about the XenApp application servers within a zone such as
server load, session status and published applications. XML Brokers authenticate users and
enumerate resources, and direct user launch requests to the appropriate application server.
High availability for the XML Broker service is detailed below. XenApp Controllers can be
integrated as part of an application server, or can be dedicated stand-alone servers when the
session-host only server mode is used to dedicate XenApp application servers. ZDC and
XML Controller functionality can also be split onto separate servers for performance as the
size of a XenApp farm increases.
Zone Data Collectors operate in an active-passive configuration. A single ZDC is primary,
and one or more backup ZDCs may be configured by defining the Zone Data Collector
election preferences in XenApp. At least two Zone Data Collectors should be defined to
provide N+1 redundancy. Multiple XML Broker servers should be configured to provide
N+1 redundancy and service the user load.

Page 7

Provisioning Servers
Citrix Provisioning Servers are responsible for streaming the desktop operating system to the
virtual desktops and the server image to XenApp servers. Citrix Provisioning Services allows
a single vDisk to be used to deliver a consistent virtual desktop across the environment, and
to simplify image management and maintenance. High availability for provisioning services
involves several components; the Provisioning Server, the vDisk store, the Provisioning
Server database, and the bootstrap delivery. Each component is discussed below:

Provisioning Server: Within a Provisioning Server site, there should be sufficient

servers created to allow for the required performance and to provide N+1
redundancy. Provisioning Servers should be distributed across multiple hypervisor
hosts within a site, and configured with restart priority so that a host failure does not
result in a service outage.

vDisk Store: One element of high availability in Provisioning Services is the ability of
a target device to maintain an active connection to a vDisk. With a single vDisk
image, multiple Provisioning Servers can deliver streams to target devices in a
configuration that is load balanced and highly available. In order to accomplish this,
the Provisioning Servers must have access to the same vDisk source. The vDisk
source can be a local copy that is synchronized between Provisioning Servers using
either manual or automated synchronization, or it can be a shared copy on highly
available block level storage or shared network storage solution such as NFS or CIFS.
For details, see the XenDesktop and XenApp Best Practices Guide.

Provisioning Server Database: As with all Citrix databases, the SQL database
infrastructure should be highly available in order to guarantee full operations. SQL
database considerations can be found in the SQL Servers section below. Provisioning
Server can also use the Offline Database Support functionality to provide continuous
operation should the database server be unavailable. The Offline Database Support
option allows Provisioning Servers to use a local snapshot of the database which is
created at server startup and continuously updated by the Stream Service. If the
database becomes unavailable, Provisioning Server will use the snapshot to get
information about the server and target devices to remain operational. The ability to
make changes to the Provisioning Server configuration will be unavailable until the
database is brought back online.

Bootstrap Delivery: Provisioning Services requires a bootstrap file to be executed on

the target device to facilitate the stream of the operating system. At least two
Provisioning Servers should be configured within the bootstrap file for redundancy.
There are several mechanisms available for delivering the bootstrap file to the target
device. Options include using Provisioning Services PXE, DHCP options 66 and 67,
and using Citrix Boot Device Manager (BDM). Considerations for each of these
Page 8

options are detailed below. For more information, refer to the Citrix Support article
CTX134945 Provisioning Services Networking Planning Guide.
o Citrix provides a PXE service with Provisioning Server that can be used to
provide access to the bootstrap file. Multiple Provisioning Servers with the
PXE service configured can respond to PXE broadcast requests from the
target, avoiding a single point of failure. Provisioning Servers and target
devices must be part of the same broadcast domain, or DHCP relay must be
implemented to use this method.
o If DHCP options 66 and 67 are used with Microsoft DHCP, the TFTP server
can be a single point of failure and can inhibit the process of booting the
target device. The Microsoft DHCP infrastructure allows for only one TFTP
address to be added to its scope options. In order to load balance TFTP
services, a load balanced address must be used to point to multiple TFTP
instances. This may be accomplished using DNS round robin or an external
load balancing device. Details on options for load balancing TFTP can be
found in the Citrix Support article CTX131954 High Availability for TFTP.
o Boot Device Manager can be used to deliver the bootstrap file through an
attached bootable ISO image. When using an ISO file to provide boot
information to target devices, ensure that it is located on a fault tolerant CIFS
share to avoid a single point of failure. For more information refer to the
Citrix eDocs Using the Manage Boot Devices Utility.
Note that in order for Provisioning Server to be highly available, the target device write cache
must not be on the Provisioning Server.
License Server
The licensing server provides Citrix licensing for all components within the XenDesktop
architecture, with the exception of the NetScaler components in the Access pool, as they are
manually configured with license files. Citrix licensing has a 30 day grace period during
which the XenDesktop components will function normally should the license server become
unavailable. Because of this grace period, a single license server as a virtual machine or
virtual appliance which is configured for VM-level HA can be implemented. A failed license
server can easily be rebuilt and restored from backup without impacting operations of the
XenDesktop infrastructure.
Microsoft license servers are required to distribute Remote Desktop Services client licenses
which are used with XenApp services. A pair of Microsoft license servers should be
deployed in order to avoid a single point of failure.

Page 9

SQL Servers
The SQL database provides the foundation for all configuration information in the
XenDesktop site, XenApp Farm, Provisioning Services Farm, and StoreFront services.
Configuration and current utilization information is stored in the database. The databases
contained within a SQL server infrastructure are crucial to the continuous operation of the
XenDesktop architecture and if it fails, affects ranging from loss of the ability to administer
the XenApp farm to the inability to connect to XenDesktop virtual desktops. SQL Server
can be made highly available through a number of technologies, including hypervisor level
HA, Clustering technologies, and SQL Mirroring. For XenDesktop architectures, it is
recommended that the SQL database be made highly available through a SQL Mirroring with
Witness configuration as it provides automated failover with the least amount of downtime.
For more information on SQL mirroring and clustering see the Microsoft whitepaper on
High Availability with SQL Server 2008 R2.
Active Directory and DNS services
Active Directory (AD) and DNS services are required to authenticate both virtual desktop
machine accounts and user access to the virtual desktops and to resolve FQDNs. As AD and
DNS services are critical components of an enterprise IT architecture, they are usually
designed with high availability in mind. Active Directory has built in availability features such
as multi-master replication and Active Directory integrated DNS. Generally, using these
features will address availability needs for AD and DNS.
DHCP Services
When a new virtual desktop is started, it requests an address from DHCP. The DHCP
system used within the organization must be designed so the loss of one server will not
prevent new DHCP requests from being fulfilled. Typically, enterprise DHCP solutions are
built with high-availability options included. The most common methods for redundant
DHCP are to utilize split scopes or to cluster DHCP servers. Specific pros and cons can be
found in Microsoft TechNet under Design Options for DHCP Availability and Fault
Tolerance. This should be analyzed and reviewed before production rollout.
XML Service
A critical component of any XenDesktop or XenApp environment is the XML Service, which
is a part of the XenDesktop Controller or XenApp Controller infrastructure. The broker
service is responsible for user authentication when Citrix Web Interface is used, as well as
resource enumeration and resource launching processes. A failure in the broker will result in
users being unable to start their virtual desktop or virtualized applications. The following
diagram shows how critical the XML Service is to users.

Page 10

Figure 2: XML Broker Process Flow

The broker service is the link between the users and the XenDesktop and XenApp
infrastructure, which makes it critical. Monitoring the broker service is not a trivial task as the
monitoring must go beyond simply identifying if the service is running to identifying if the
service is responding appropriately. If the broker responds incorrectly, the Web Interface
server could get stuck in a request/response loop resulting in users not gaining access to their
resource.
Multiple XML Broker instances can be load balanced to provide high availability. The
number of XML Broker instances should take into consideration both the required load and
N+1 redundancy. Citrix Web Interface provides basic round-robin based load balancing of
the XML Broker. This however can create issues if a XML Broker is running but not
responding. NetScaler provides more intelligent monitoring of the XML Broker through the
use of pre-configured monitor templates. This monitoring determines if the XML Broker is
running and if it responds in a timely manner and with expected information. If the monitor
determines an unexpected result or complete failure to respond, NetScaler creates an alert,
which is used in the load balancing algorithm. NetScaler dynamically adjusts the environment
to bypass the failed Broker. If the XML Broker functionality is restored, NetScaler
automatically detects and incorporates it back into the environment.
Virtual Desktop Agent (VDA)
The Virtual Desktop Agent is a software component installed on XenDesktop virtual
desktops that enables the virtual machines to register with the XenDesktop Controllers, and
manages the HDX connection between the virtual desktops and user devices. The VDA uses
a list of controller addresses that are provided during installation or through group policy,
and will attempt to connect to a XenDesktop Controller randomly selected from the list. If
that controller cannot be contacted, it will select another from the list. Controller addresses
should not be externally load balanced as the VDA is dynamically registered with a single
Page 11

controller and expects to communicate with that controller through the life of the
connection.
The VDA also has a high availability option which will allow users of dedicated virtual
desktops to connect to their virtual machines in rare cases where all XenDesktop Controllers
are unavailable. The connection is limited to a single device (no roaming) and other features
such as Citrix policies, power management, and remote access (via Access Gateway) will be
unavailable. It requires an administrator provided ICA launch file, and has 30 day
persistence.

Desktops Layer
The desktop layer consists of three basic components; image, applications, and personalization.
Within the desktop layer, each of these components should be reviewed for high availability.
When a desktop fails to boot, or blue screens and crashes, users experience a loss of productivity.
Desktop and application virtualization, designed properly, mitigates the impact of a desktop or
application failure by delivering a consistent, controlled environment that is less prone to failures,
as well as a solution that is able to recover quickly when a failure occurs. Each component in the
desktop layer is discussed in more detail below:
OS Image
The desktop image contains the operating system and core applications that all users will
require to perform their roles. XenApp server images contain the server operating system as
well as published applications. Delivering a virtual machine with an image that is both
resilient to failure and allows for quick recovery in the event of an issue is key to providing
high availability at the image level.
For virtual desktops, Citrix FlexCast models allow for the delivery of a standardized and
optimized virtual desktop to users using the Hosted VDI and Hosted Shared desktop models.
For more information on Citrix FlexCast models, visit flexcast.citrix.com.
With Citrix FlexCast, particularly streamed and pooled delivery models, a single instance of
the image can be delivered to multiple end users. These models allow for a non-persistent
image in which the image is reset to a pristine state on every reboot. This allows for the
delivery of a new image every time a user accesses the environment, and virtually eliminates
any chance of a user corruption of the image. If a user makes a change that causes their
instance of the image to corrupt, a restart will connect them to a new clean image, and the
corrupt instance will be destroyed. This allows a user to reconnect and continue working
with minimal disruption, and provides the highest availability for desktop image. When users
require a dedicated desktop, administrators can create snapshots of individual virtual
desktops as required, thus allowing for rapid recovery to a known good state in the event of
an issue with the specific virtual desktop image.

Page 12

For XenApp servers, images can be either installed or streamed. With traditional installation,
XenApp application servers are individually installed and managed. Streaming the XenApp
server image via Provisioning Server allows for the ability to quickly recover a XenApp server
in the event of a failure, provision new XenApp servers to scale operations, and also provides
single instance management for XenApp servers; a single vDisk image can be updated with
hotfixes or new published applications and quickly deployed to all servers in the
environment. This increases availability as server issues can be addressed quickly with
minimal downtime.
Applications
Applications can be delivered to end-users as locally installed, hosted or streamed.
Application delivery technologies apply equally to virtual and physical desktop instances.
Users can be protected from failures within the application due to corruption, deletion, or
other means via the processes used to deliver those applications, particularly when dealing
with pooled or dedicated desktops with streamed or hosted applications. Virtualized
applications can be delivered by XenApp. Using XenApp provides the ability to deliver
applications from a single instance to multiple end-user devices simultaneously. Application
management and maintenance can be centralized, reducing downtime and increasing
availability. An outline of the three application delivery methods is found below:

Installed: Installed applications are part of the base desktop image. In a pooled or
streamed model, the image is delivered as read-only, where user-level changes are
stored in a temporary cache. When the virtual desktop is restarted, the changes are
lost and the virtual desktop reverts to the base image. This keeps the operating system
and the installed applications in a pristine format, free from any corruptions or
misconfigurations by the user. Dedicated virtual desktops and physical desktops
manage installed applications through a traditional systems management model.

Streamed: Streamed applications are delivered to the desktop over the network as
requested. The applications are stored on a file server (Application Hub) as an
application profile. When users launch the application, portions are delivered to the
virtual desktop. The streaming process verifies the files exist in the correct state
during launch. If not, the correct files are streamed from the Application Hub
automatically and seamlessly. Application Hubs should be protected through
clustering or replication technology to ensure that they are available to serve the
application profile to the streaming solution.

Hosted: Hosted applications are virtualized and executed on a XenApp server;

therefore the application does not impact the virtual desktop. Hosted applications
can either be installed or streamed. If the applications are streamed to the XenApp
servers, they will self-heal due to the file checks built into the application streaming
process. XenApp application servers need to have sufficient capacity and

Page 13

redundancy (N+1) within each worker group to ensure delivery of the applications to
all users with adequate performance and availability.
Personalization
In a XenDesktop environment, personalization is used to minimize the number of desktop
images and create a consistent user experience across devices. Personalization applies to user
profile information; settings and document folders that need to be available to users across
physical and virtual desktops and XenApp servers, and Personal vDisk (PvD) space where
users can install one-off or departmental applications for personal use. Personalization
configuration should be kept as available as possible to preserve user configurations and
customizations. If personalization is not available, users will receive a default profile and may
have access to a standard virtual desktop but without customizations. Users may also not
have access to files stored in redirected folders if the personalization system is not available.
With Citrix Profile Manager, user profile information is stored on a networked user store
(NUS). This user store is a Microsoft Windows file share which contains the users profile
data and redirected folders. Providing high availability for the NUS can be accomplished
through two mechanisms; making sure the data is available through RAID levels on the data
store, and providing high availability for the file share through failover clustering. For more
information on how to accomplish this, refer to the Citrix e-Docs High Availability and
Disaster Recovery with Profile Management.

Access Layer
The Access layer is comprised of the components required to provide users access to the
XenDesktop or XenApp environments; Web Interface, StoreFront Server, and NetScaler
technologies. These components allow users access to their virtual desktops and applications
both locally and remotely. Without highly available infrastructures in the Access layer, the virtual
resources provided by the control and desktop layers could not be used. Each component within
the layer is discussed below:

Page 14

Web Interface
Web Interface servers are responsible for delivering the desktop and the applications to the
users. Whether used through web browser access or through Citrix Receiver (Services site),
Web Interface is a critical component for users. From the interface, users enter their
credentials and select their desktops or applications. Based on the user interactions, Web
Interface communicates with the XML Service for the XenDesktop sites to fulfill the user
request. In situations where the sever hosting Web Interface fails, or the IIS service fails or
Web Interface encounters issues, users would be unable to connect to the environment. High
availability for Web Interface is achieved by having multiple servers configured, and load
balanced through an external load balancer. As with XML Broker servers in the control layer,
simple round-robin load balancing or intelligent load balancing provided by Citrix NetScaler
can be used. Sufficient Web Interface servers should be configured to handle the user load, as
well as providing N+1 redundancy to guard against loss of service due to a server failure.
StoreFront Server
Similar to Web Interface, Citrix StoreFront servers are responsible for delivering the desktop
and the applications to the users. StoreFront servers provide user access through both native
Receiver clients on desktops, laptops and tablets, or web based access through Receiver for
Web infrastructure. StoreFront servers also offload the authentication requirement from the
XML Broker servers, performing the authentication before passing the request. StoreFront
servers also have a database component, which provides application synchronization across
multiple devices. The SQL database component of StoreFront server should be protected to
maintain availability (see the SQL Server section of the Control layer). Like Web Interface,
high availability for StoreFront is achieved by having multiple servers configured, and load
balanced through an external load balancer, providing simple round-robin or intelligent load
balancing. Sufficient StoreFront servers should be configured to handle the user load, as well
as providing N+1 redundancy to guard against loss of service due to a server failure.
NetScaler/Access Gateway
The NetScaler performs two major roles in the XenDesktop and XenApp architecture. It
provides intelligent load balancing for components such as the XML Broker and Web
Interface servers, and provides the platform to host the Access Gateway Enterprise
configuration. NetScaler uses intelligent monitors to load balance Web Interface and XML
Brokers. By launching a connection to the component, the monitor determines if the server is
available, if the appropriate service is running and if the component is functioning and
responding. If disruptions in the service are identified, NetScaler generates an alert. The alert
is then used as part of the NetScaler load balancing algorithm. If a server is not responding
correctly, the server is removed from the load balancing pool until the problem is corrected.
New user requests are routed only to the available servers.
With Access Gateway configurations, at least two Citrix Secure Ticket Authority (STA) servers
should be specified to prevent this component from becoming a single point of failure. Also,
Page 15

to prevent issues with logons and to optimize logon times, ensure that the addresses specified
within the Access Gateway configuration match the STA entries on the Web Interface servers.
When configuring the environment, the NetScaler and Access Gateway Enterprise
configuration should be configured for high availability. NetScaler devices, physical or virtual
appliances, can be setup in an active/passive pair to provide availability of the NetScaler load
balancing and Access Gateway configuration in the event of a component failure. To setup a
high availability configuration for NetScaler, two nodes are created, each of which defines the
other nodes NetScaler IP (NSIP) address as a remote node. An algorithm within the
NetScaler then determines which node becomes primary, and which node becomes secondary.
For more information on configuring high availability for NetScaler, see the Citrix e-Docs for
NetScaler High Availability.

Users Layer
The User layer represents the users who access the Citrix environment. These users will see
impact to their productivity if the environment is not available. Users themselves cannot be
made highly available, but will be productive proportionally to the availability of the XenApp or
XenDesktop environment. A solid support structure, including support tiers from Level 1 (Help
Desk) to Level 4 (Architect), with appropriately trained staff, will provide the basis for user
productivity, and assistance when problems arise. Support staff should be adequately trained to
fulfill the roles that are required. Citrix recommends the following levels of training as best
practice:

Level 1 (Help Desk): Citrix Certified Administrator (CCA) on XenApp and XenDesktop

Level 2 (Production Support Engineer): Citrix Certified Advanced Administrator

(CCAA)

Level 3 (Build Engineer): Citrix Certified Enterprise Engineer (CCEE)

Level 4 (Architect): Citrix Certified Integration Architect (CCIA)

Page 16

Planning
The following table provides a set of design decisions based on providing high availability within
each layer and component of the XenDesktop architecture. These design decisions are for planning
purposes and should be tested thoroughly prior to implementation in a production environment to
ensure that the environment performs as expected.
High Availability Configuration

Layer/Component
Hardware/Physical Hardware
Chassis
Power Supplies and Fans
Network Interface

Storage Network

Storage RAID
Memory
Hardware/Hypervisor
Heartbeat
Restart Priority

Control/XenDesktop Controllers
Controller Redundancy
XML Broker Service
Control/XenApp Controllers
Zone Data Collectors
XML Controllers (Broker Servers)
Control/Provisioning Servers
Provisioning Servers
vDisk Store

Provisioning Server Database

Bootstrap Delivery

Control/License Server
License Server Redundancy
Control/SQL Server
SQL Server HA

Design Decision
Blade Chassis should have redundant backplane if possible, or redundant chassis configured
Redundant Power Supplies/Fans per chassis for blade configurations
UPS based power (rack or datacenter level) should be provided
Multiple redundant network paths (NICs, Switches) should be configured. See Network section of the
Best Practices Guide for recommended NIC configuration.
NICs should be link aggregated to provide redundancy and increased throughput (where available).
Link aggregation should span physical NICs (two ports on the same NIC should not be aggregated if
possible).
Fiber Interconnects and HBAs, network paths and storage shelves should be redundant. See the
Storage Best Practices Planning Guide for more information.
Storage should use multipath communications where possible.
RAID should be used to eliminate hard drives as a single point of failure. RAID 1 and 10 should be
considered for components where write performance is required.
ECC (Error Correcting) Memory should be used.
Multiple redundant heartbeat paths should be configured using both storage and management
networks.
Infrastructure Servers should be configured to restart on hypervisor failure.
Highest Priority: SQL Servers, Active Directory, DNS and DHCP servers/services.
Medium Priority: XenApp and XenDesktop Controllers, Provisioning Servers, Web
Interface/StoreFront Servers, NetScaler (if virtual appliance used)
Low Priority (Restart if Possible): License Servers
Use N+1 Redundancy for XenDesktop Controllers.
Part of all XenDesktop Controllers (uses same N+1 Redundancy).
Load Balanced with intelligent balancing (NetScaler Load Balancing).
A minimum of two dedicated Zone Data Collectors for enterprise deployments.
Dedicated XML Controllers with N+1 Redundancy
Load Balanced with intelligent balancing (NetScaler Load Balancing).
Use N+1 redundancy for Provisioning Servers
vDisk store should be hosted on shared storage that is highly available.
Hosted on a shared storage infrastructure (e.g. NFS, CIFS) that is accessible by all Provisioning
Servers to facilitate automated failover between PvS servers.
Enable Offline Database Support on production environments.
Select the most appropriate method for bootstrap delivery
If using Provisioning Services PXE, the servers and targets should be on the same broadcast domain
If using DHCP Options, the TFTP service should be load balanced using one of the methods outlined
in CTX131954 High Availability for TFTP
If using Boot Device Manager, the ISO file should be on a CIFS share that is highly available
Include multiple Provisioning Server addresses in the bootstrap file to avoid a single point of failure
A single license server with Hypervisor level HA (Restart if possible)
Two Microsoft License servers (for RDS CALs) should be configured to avoid a single point of failure
SQL Server infrastructure should be highly available. Methods to create a SQL Server HA
Configuration include:
Hypervisor High Availability (Restart Priority)

Page 17

High Availability Configuration

Layer/Component

Control/Active Directory and DNS

AD/DNS Redundancy
Control/DHCP
DHCP HA

Control/Virtual Desktop Agent

Controller Addresses
VDA High Availability
Desktops/Image
Delivery Model

Desktops/Applications
Application Delivery

Desktops/Personalization
Personal Data Storage

Access/Web Interface
Web Interface Redundancy
Web Interface Load Balancing
Access/StoreFront
StoreFront Server Redundancy
StoreFront Load Balancing
Access/NetScaler and Access Gateway
NetScaler Redundancy
Secure Ticket Authority (STA)
Users/Support
Support Training Levels

Design Decision
SQL Clustering
SQL Mirroring (with Witness)
SQL Mirroring with Witness is the recommended configuration for XenDesktop as it provides the
highest availability for SQL Server with automatic failover in the shortest period of time. For more
information review CTX127939 XenDesktop 5 Database Sizing and Mirroring Best Practices.
Multiple Active Directory and DNS servers should be available to service requests from the
XenDesktop infrastructure.
DHCP should be configured with HA features such as a split scope or clustered DHCP
implementation. Consult the Microsoft TechNet article Design Options for DHCP Availability and
Fault Tolerance.
Provide multiple XenDesktop Controller addresses during VDA install or through GPO.
Do not use external load balancing for controller addresses with VDA
VDA High Availability can be configured if there is the possibility of loss of connectivity to all
XenDesktop Controllers, but this is a rare occurrence.
Desktop delivery model should be determined based on user requirements, taking into consideration
availability and delivering the appropriate experience while minimizing downtime through FlexCast
model. Streamed and Pooled delivery models allow for a single instance image providing rapid
recovery in the event of an operating system crash.
XenApp application server images can also be streamed, minimizing downtime and allowing for rapid
provisioning of new XenApp servers.
Chose the most appropriate application delivery model taking into consideration application
availability and recovery:
Core Applications and Utilities: Common to all users, installed on desktop image
Major Applications: Common to large groups of users, delivered by XenApp - streamed if possible,
otherwise published
Departmental and One-Off Applications: Installed on Personal vDisk or delivered by XenApp
Personal data should be stored on protected shared storage with appropriate RAID configuration to
guard against disk failure, and clustering or replication to ensure that the shared storage is always
available.
Use N+1 redundancy for Web Interface Servers
Load balanced with intelligent balancing (NetScaler Load Balancing)
Use N+1 redundancy for StoreFront Servers
Load balanced with intelligent balancing (NetScaler Load Balancing) using generic monitors
NetScalers should be configured in a high availability (active/passive) pair. For more information
review Citrix eDocs NetScaler High Availability
A minimum of two STA addresses should be configured to avoid a single point of failure
Citrix recommends the following training levels for support personnel:
Level 1 (Help Desk): Citrix Certified Administrator (CCA) on XenApp and XenDesktop
Level 2 (Production Support Engineer): Citrix Certified Advanced Administrator (CCAA)
Level 3 (Build Engineer): Citrix Certified Enterprise Engineer (CCEE)
Level 4 (Architect): Citrix Certified Integration Architect (CCIA)

Page 18

Acknowledgments
Citrix Consulting Solutions would like to thank all of the individuals that offered guidance and
technical assistance during the creation of this whitepaper who were extremely helpful answering
questions, providing technical guidance and reviewing documentation:

Andy Baker
Adeel Arshed
Daniel Feller
Matthew Brooks

Product Versions
Product
XenDesktop
XenApp
Provisioning Services
NetScaler

Version
5.x
6.x
6.x
10.x

Revision History
Revision
1.0

Change Description
Initial Release

Updated By
Rich Meesters

Date
9/14/12

About Citrix
Citrix Systems, Inc. (NASDAQ:CTXS) is a leading provider of virtual computing solutions that help
companies deliver IT as an on-demand service. Founded in 1989, Citrix combines virtualization,
networking, and cloud computing technologies into a full portfolio of products that enable virtual
workstyles for users and virtual datacenters for IT. More than 230,000 organizations worldwide rely
on Citrix to help them build simpler and more cost-effective IT environments. Citrix partners with
over 10,000 companies in more than 100 countries. Annual revenue in 2011 was $2.20 billion.
2012 Citrix Systems, Inc. All rights reserved. Citrix, Access Gateway, Branch Repeater,
Citrix Repeater, HDX, XenServer, XenApp, XenDesktop and Citrix Delivery Center
are trademarks of Citrix Systems, Inc. and/or one or more of its subsidiaries, and may be registered
in the United States Patent and Trademark Office and in other countries. All other trademarks and
registered trademarks are property of their respective owners.

Page 19