High Availability for Citrix XenDesktop and XenApp

Transcription

1 Worldwide Consulting Solutions WHITE PAPER Citrix XenDesktop High Availability for Citrix XenDesktop and XenApp Planning Guide for High Availability

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 Active Directory and DNS services DHCP Services XML Service Virtual Desktop Agent (VDA) Desktops Layer OS Image Applications Personalization Access Layer Web Interface StoreFront Server NetScaler/Access Gateway Users Layer Planning Product Versions Revision History Page 2

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 3

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 4

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 5

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 CTX 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 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 CTX 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

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 7

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 8

9 options are detailed below. For more information, refer to the Citrix Support article CTX 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 CTX 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

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 10

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 11

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 12

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 13

14 Personalization redundancy (N+1) within each worker group to ensure delivery of the applications to all users with adequate performance and availability. 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 14

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 15

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 16

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 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 CTX 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

18 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 CTX 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

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