Worldwide Consulting Solutions | WHITE PAPER | Citrix XenDesktop

www.citrix.com

High Availability for

Citrix XenDesktop and XenApp

Planning Guide for High Availability

Page 2

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 3

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 4

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 5

Guidelines

When delivered via XenApp and XenDesktop, a user’s 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 6

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 7

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 8

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 9

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 10

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 11

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 12

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 13

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 14

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 user’s 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 15

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 16

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 node’s 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 17

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 Design Decision

Hardware/Physical Hardware

Chassis Blade Chassis should have redundant backplane if possible, or redundant chassis configured

Power Supplies and Fans Redundant Power Supplies/Fans per chassis for blade configurations

UPS based power (rack or datacenter level) should be provided

Network Interface 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).

Storage Network 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.

Storage RAID 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.

Memory ECC (Error Correcting) Memory should be used.

Hardware/Hypervisor

Heartbeat Multiple redundant heartbeat paths should be configured using both storage and management

networks.

Restart Priority 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

Control/XenDesktop Controllers

Controller Redundancy Use N+1 Redundancy for XenDesktop Controllers.

XML Broker Service Part of all XenDesktop Controllers (uses same N+1 Redundancy).

Load Balanced with intelligent balancing (NetScaler Load Balancing).

Control/XenApp Controllers

Zone Data Collectors A minimum of two dedicated Zone Data Collectors for enterprise deployments.

XML Controllers (Broker Servers) Dedicated XML Controllers with N+1 Redundancy

Load Balanced with intelligent balancing (NetScaler Load Balancing).

Control/Provisioning Servers

Provisioning Servers Use N+1 redundancy for Provisioning Servers

vDisk Store 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.

Provisioning Server Database Enable “Offline Database Support” on production environments.

Bootstrap Delivery 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

Control/License Server

License Server Redundancy 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

Control/SQL Server

SQL Server HA SQL Server infrastructure should be highly available. Methods to create a SQL Server HA

Configuration include:

Hypervisor High Availability (Restart Priority)

Page 18

High Availability Configuration

Layer/Component 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.

Control/Active Directory and DNS

AD/DNS Redundancy Multiple Active Directory and DNS servers should be available to service requests from the

XenDesktop infrastructure.

Control/DHCP

DHCP HA 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.

Control/Virtual Desktop Agent

Controller Addresses 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 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.

Desktops/Image

Delivery Model 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.

Desktops/Applications

Application Delivery 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

Desktops/Personalization

Personal Data Storage 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.

Access/Web Interface

Web Interface Redundancy Use N+1 redundancy for Web Interface Servers

Web Interface Load Balancing Load balanced with intelligent balancing (NetScaler Load Balancing)

Access/StoreFront

StoreFront Server Redundancy Use N+1 redundancy for StoreFront Servers

StoreFront Load Balancing Load balanced with intelligent balancing (NetScaler Load Balancing) using generic monitors

Access/NetScaler and Access Gateway

NetScaler Redundancy NetScalers should be configured in a high availability (active/passive) pair. For more information

review Citrix eDocs – NetScaler High Availability

Secure Ticket Authority (STA) A minimum of two STA addresses should be configured to avoid a single point of failure

Users/Support

Support Training Levels 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 19

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 Version

XenDesktop 5.x

XenApp 6.x

Provisioning Services 6.x

NetScaler 10.x

Revision History

Revision Change Description Updated By Date

1.0 Initial Release Rich Meesters 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.