Provisioning Server High Availability Considerations

(1)

Citrix Consulting

Provisioning Server High Availability Considerations

Overview

The purpose of this document is to give the target audience an overview about the critical components of a Citrix Provisioning Server infrastructure with regards to a high availability implementation. These considerations focus on the following areas:

• Virtual Disk (vDisk) Storage • Write Cache Placement • SQL Database • TFTP Service • DHCP Service

Target Audience

This document was written for information technology (IT) infrastructure specialists who are responsible for planning and designing Provisioning Server infrastructure. These specialists include consultants, internal IT architects, and others who are concerned with design decisions related to dynamic server provisioning.

Acknowledgement

(2)

vDisk Storage Considerations

The following chapter outlines different options for configuring the Provisioning Server vDisk store.

Local vDisks

Using the local hard disk subsystem of the Provisioning Servers to store the vDisks provides the easiest way of implementing vDisk high availability without additional cost.

Note: When configuring a vDisk store pointing to a local directory of multiple servers (that is, C:\vDisks) only one item is

showed per vDisk, which allows some degree of central vDisk management. Pros for this solution are:

• No additional cost

• Easy to implement and maintain Cons for this solution are:

• vDisks must be manually synchronized between the Provisioning Servers

• I/O performance depends on the capabilities of the hard drive subsystem (usually equal to Network Attached Storage (NAS))

Recommendations:

(3)

Windows Network Share

Using a single Windows network share (Common Internet File System (CIFS)) to store the vDisks is a very easy way of implementing a central vDisk store for a Provisioning Server implementation at minimal cost.

Pros for this solution are:

• Minimal cost to purchase, implement, and maintain • Easy to implement and maintain

Cons for this solution are:

• No redundancy for file server outages (all Provisioning Server Target Devices stop responding) • I/O performance not as good as NAS, an iSCSI or Fibre Channel (FC) Storage Area Network (SAN) • Limited scalability to support a increasing number of Target Devices

• I/O for vDisk input (loading from the share) and vDisk output (delivering to the Target Devices) is handled by the same network link. This affects the overall performance of the solution.

Recommendations:

• Network Interface Card (NIC) – Teaming should be used to increase the reliability and the I/O between the Provisioning Servers, file server and Target Devices

• Where feasible dedicated NICs should be used for loading the vDisks and for delivering the vDisks to the Target Devices

(4)

Network Attached Storage (NAS)

Using a single NAS to store the vDisks is an easy way to implement a central vDisk store for a Provisioning Server implementation at moderate cost.

• Moderate cost to purchase, implement, and maintain • Easy to implement and maintain

• Enhanced reliability

• Greater degree of scalability to support a increasing number of Target Devices

o The combination of an NAS head/aggregator and additional storage arrays can be used to effectively load balance the increase in I/O demands

• More expensive than a Windows network share

• No redundancy for NAS outages (all Provisioning Server Target Devices stop responding), whereas NAS devices themselves usually provide high reliability

• Requires software to manage the storage array

• I/O performance not as good as an iSCSI or Fibre Channel SAN

• RAID arrays must be configured on the storage array and assigned to each Provisioning Server

Recommendations:

• Network Interface Card (NIC) – Teaming should be used to increase the reliability and the I/O between the Provisioning Servers, File Server and Target Devices

• Where feasible, dedicated NICs should be used for loading the vDisks and for delivering the vDisks to the Target Devices

(5)

Storage Area Network (SAN) – iSCSI

Using a Storage Area Network (SAN) to store the vDisks and accessing it by means of the iSCSI protocol provides a reliable way (with good performance) to implement a central vDisk store for a Provisioning Server implementation at higher cost.

• Moderate cost to purchase, implement and maintain

• Highest levels of reliability through built-in redundant components and features • High degree of scalability to support a increasing number of Target Devices

o Multiple partitions/LUNs can be created on multiple RAID arrays and combined into a single stripe-set, utilizing the additional disk heads to support the increase in I/O demands

• More expensive than a Windows network share or NAS • Requires software to manage the storage array. • More software required to implement an iSCSI SAN:

o iSCSI Initiator and MultiPath software must be installed and configured on each Provisioning Server. o iSCSI Target software must be installed and configured on the file server(s).

• A cluster or parallel file system (that is, Sanbolic MelioFS) is required to ensure the integrity of the partition/Logical Unit Number (LUN) containing the vDisks.

• I/O performance not as good as a Fibre Channel SAN

Recommendations:

• Network Interface Card (NIC) – Teaming should be used to increase the reliability and the I/O between the Provisioning Servers, File Server and Target Devices

(6)

(7)

Storage Area Network (SAN) – Fibre Channel

Using a Storage Area Network (SAN) to store the vDisks and access them by means of Fibre Channel provides a very reliable way, with the highest level of performance, to implement a central vDisk store for a Provisioning Server implementation at highest cost.

• Highest levels of performance

• Highest levels of reliability through built-in redundant components and features • High degree of scalability to support a increasing number of Target Devices

o Multiple partitions/LUNs can be created on multiple RAID arrays and combined into a single stripe-set, utilizing the additional disk heads to support the increase in I/O demands

• Most expensive to purchase, implement and maintain

• Additional Hardware (HBAs) required for every Provisioning Server • Requires software to manage the storage array.

• A cluster or parallel file system (that is, Sanbolic MelioFS) is required to ensure the integrity of the partition/LUN containing the vDisks.

Recommendations:

(8)

Decisions Matrix

The following table outlines a summary of all discussed solutions and their benefit areas for Provisioning Server implementations (1 = Least Benefit, 5= Most Benefit).

Cost Ease of

Use Performance Reliability Scalability

Local vDisks 5 4 3 3 2 Windows File

Share 4 5 2 1 1

NAS 3 3 3 3 3

iSCSI SAN 2 2 4 5 5

Fiber Channel SAN 1 1 5 5 5

Write Cache Placement

The size of the cache file for each provisioned workstation depends on several factors, including types of applications used, user workflow, and restart frequency. A general estimate of the file cache size for a provisioned workstation running only text-based applications (such as Microsoft Word and Outlook) that is restarted daily is about 300-500 megabytes (MB). If workstations are restarted less often that this, or graphic-intensive applications (such as Microsoft PowerPoint, Visual Studio, or CAD/CAM type applications) are used, cache file sizes can grow much larger. This estimate is based on past experience and may not accurately reflect each environment. Citrix recommends each organization perform an analysis to determine the expected cache file size in their environment.

Cache File Location

There are several options for storing the cache file for provisioned systems. Each of these options has benefits and limitations. Thus, it is important to evaluate the specific requirements of the organization before making the decision for the cache file location. The benefits and limitations of each option are described below.

• Client-side cache

o This option requires a local disk on each physical system.

(9)

o This option provides added resiliency in the event of a failure because only a single client will be affected if the local disk associated with the system runs out of space.

• Server-side cache

o The cache file can also be stored within a shared enterprise storage solution (SAN/NAS) accessed through the Provisioning Server. In this case, the Provisioning Server would act as a proxy between the clients and the storage solution.

o Proxying the cache traffic through the Provisioning Server in this manner impacts the network IO and reduces the scalability of each Provisioning Server. This will impact the performance of the desktops being supported by the Provisioning Server as well as reduce the number of active clients that can be supported by a single server.

o In this scenario, if the shared storage location fills up and no disk space remains for the cache, all virtual machines may experience performance issues.

Note: For enterprise deployments, Citrix does not recommend storing the cache file locally on the

Provisioning Server. • Client-side RAM cache

o RAM is faster than hard disk, so better performance will be seen if RAM is used.

o If RAM is used for the cache file, the file is limited in size by the amount of physical RAM available. o If the cache file is expected to grow larger than the amount of available physical RAM in the device, the

device’s hard drive should be used instead. If the target devices do not contain hard drives (diskless), cache files can be stored on shared enterprise storage, proxied through the Provisioning Server as described above.

o If the target devices have hard drives, there is generally more space available for the cache file on the hard drive than in memory.

Note: Citrix recommends leveraging the target device RAM or hard disk to store the cache files.

Determining Expected Cache File Size

Citrix recommends using a pilot/Proof of Concepts (POC) environment to determine the expected size of the cache files. To do so, within the pilot/POC environment, configure the write cache to be located on the Provisioning Server and have several different types of end users (graphical application users, text-based task workers, and so on) work on their provisioned desktops. After several full days of heavy use, the administrators can look at the size of each of the cache files on the Provisioning Server. This will give a rough estimate of how large the cache files can grow to in the production environment. In the production environment, gracefully restarting the desktops everyday will help reduce the size of the cache file.

Restart Provisioned Workstations Frequently

The cache file (write cache) for provisioned workstations can grow quite large, and will continue to grow until the

workstation is restarted. Depending on the applications used and the frequency of restarts, the write cache can grow as large as to impact an organization’s storage solution. The cache file gets cleared out upon workstation restart; thus, the more frequently the workstation is restarted, the less of an impact the cache files will have. Citrix recommends restarting workstations daily if possible. If daily restarts are not possible, Citrix recommends restarting workstations at least once per week to reduce the storage impact of cache files.

Note: A graceful shutdown or restart is required to clear the cache file. Turning off the machine without a graceful

shutdown does not clear out the cache file. XenDesktop allows configuration of logoff behavior so this process can be

(10)

SQL Database

With the release of Provisioning Server 5.0 the configuration database has been changed from a JET type database to the more robust Microsoft SQL Server. All editions of Microsoft SQL Server 2005 (even SQL Express, which is included with the Provisioning Server disbursement) are supported, as stated in the Citrix Knowledge Base article CTX114501. Unlike in XenApp implementations, the Provisioning Server configuration database is a highly critical component that must be available at all times for serving Target Devices. In case of an outage of the database, existing sessions will continue but new sessions cannot be established. Therefore the SQL database must be configured in a fully redundant manner. Further information about how to configure a high available Microsoft SQL Server environment can be found on Microsoft TechNet: http://msdn.microsoft.com/en-us/library/ms190202.aspx

TFTP Service High Availability

Within Provisioning Server implementations, the Trivial File Transfer Protocol (TFTP) service is used to deliver the Provisioning Server bootstrap. This file contains, besides various configuration settings, a list of available Provisioning Servers within the environment.

All information about location and name of the bootfile is delivered by the DHCP server upon request of the Target Devices (Dynamic Host Configuration Protocol (DHCP) options 66 [Boot Server Host Name] and 67 [Bootfile Name]).

Note: Alternatives to the usage option 66 and 67 in DHCP are:

• PXE Service: This service is a default component of all Provisioning Servers and uses a broadcasting technology similar to DHCP to deliver information about the bootstrap. For serving Target Devices in different subnets, DHCP Helper or Proxy DHCP entries (RFC1542, RFC3046) are required.

• Boot Device Management Utility: Can be leveraged to create an ISO file, which contains the bootstrap and various other configuration settings.

As the DHCP options required for this task are "single entry" options, which means that only one value per option is allowed, a limited number of configurations for providing High Availability are possible.

• DNS Round Robin: Instead of an IP address a fully qualified domain name (FQDN) (that is,

pvstftp.mycorp.local) can be configured within DHCP option 66. This FQDN can be configured for DNS Round Robin, which means that it contains a list of multiple IPs instead of a single IP. In this scenario all systems corresponding to the IPs configured, are used rotationally.

The downside to this is that DNS does not check whether the systems are operational or not. So if you experience an outage on one system in a two-system bond, 50 percent of the booting Provisioning Server Target Devices will not be served. To minimize the impact of an outage, a very short DNS time to live (TTL) for the FQDN can be configured.

(11)

Load Balancing Provisioning Server TFTP by means of NetScaler

Load balancing a TFTP service by means of Citrix NetScaler requires certain configuration steps outlined within the knowledge base article CTX116337. A very important part of this configuration is setting the IP address of the default gateway of the TFTP server to the IP address of the NetScaler MIP or SNIP. This means that all communication between the TFTP server and the TFTP clients will be handled by the NetScaler.

As within a standard Provisioning Server environment, the TFTP service is hosted on the Provisioning Server itself, and the vDisk deployment would be handled by the NetScalers as well. To prevent this additional network hop, to reduce the network load on the NetScaler and to minimize the complexity of a Provisioning Server environment, a standalone TFTP server (such as free TFTP from Solarwinds) can be used.

(12)

DHCP High Availability

Within a typical Provisioning Server environment, DHCP plays a very central role as it provides the Target Devices with the IP address configuration and information about the Provisioning Server bootstrap (location and filename). Therefore it is necessary to implement DHCP in a reliable way. Within this section we will focus on Microsoft based DHCP services, but the main concepts for fault tolerance remain the same even if hosted of other operating systems.

Typical concepts of a full, redundant DHCP implementation are: • DHCP Split Scopes

• DHCP Cluster • DHCP Stand-by Server

Further information about this topic can been gathered from Microsoft TechNet “Enterprise Design for DHCP” (http://www.microsoft.com/technet/solutionaccelerators/wssra/raguide/NetworkServices/ignsbp_3.mspx). Recommended for further information: Microsoft DHCP Best Practices

Note: Using dynamic DHCP for the Target Devices might cause in XenDesktop VDA Registration and XenApp XML

(13)

Notice

The information in this publication is subject to change without notice.

THIS PUBLICATION IS PROVIDED “AS IS” WITHOUT WARRANTIES OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING ANY WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE OR NON-INFRINGEMENT. CITRIX SYSTEMS, INC. (“CITRIX”), SHALL NOT BE LIABLE FOR TECHNICAL OR EDITORIAL ERRORS OR OMISSIONS CONTAINED HEREIN, NOR FOR DIRECT, INCIDENTAL, CONSEQUENTIAL OR ANY OTHER DAMAGES RESULTING FROM THE FURNISHING, PERFORMANCE, OR USE OF THIS PUBLICATION, EVEN IF CITRIX HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES IN ADVANCE.

This publication contains information protected by copyright. Except for internal distribution, no part of this publication may be photocopied or reproduced in any form without prior written consent from Citrix.

The exclusive warranty for Citrix products, if any, is stated in the product documentation accompanying such products. Citrix does not warrant products other than its own.

Product names mentioned herein may be trademarks and/or registered trademarks of their respective companies.

Version History

Author(s) Version Change Log Date

Thomas Berger Principal Consultant

Consulting Services Central Europe Tarkan Koçoğlu

Senior Architect

Worldwide Field Readiness & Productivity Bob Hesseltine

Principal Consultant Citrix Consulting Americas

1.0 Initial documentation December 1, 2008