Provisioning server high_availability_considerations2
2 likes2,318 views
This document provides an overview of high availability considerations for Citrix Provisioning Server infrastructure, targeting IT specialists involved in its design and planning. Key areas discussed include vdisk storage options, write cache placement, SQL database configurations, TFTP, and DHCP service for ensuring reliability. Acknowledgment is given to DSV-Gruppe for their contributions in testing common challenges faced by customers.
![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.
• Hardware-based load balancing (NetScaler): When using hardware-based load balancers (such as NetScaler)
all load balanced services can be checked for availability and functionality at regular intervals. If you experience
an outage on one of the servers or services, it gets automatically removed from the load balancing list. So instead
of configuring DHCP option 66 for a FQDN or referring directly to a TFTP server, a NetScaler vServer could be
created to provide all levels of redundancy for this service and its IP address would be used for this DHCP option.](https://image.slidesharecdn.com/provisioningserverhighavailabilityconsiderations2-130919054713-phpapp01/85/Provisioning-server-high_availability_considerations2-10-320.jpg)
Provisioning server high_availability_considerations2
- 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 Citrix Consulting would like to thank the customer DSV-Gruppe Deutscher Sparkassenverlag (www.dsv-gruppe.de) for providing the test environment and test cases in order to validate typical customer challenges, which were essential for the creation of this white paper. Citrix Provisioning Server Design Considerations
- 2. 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: • Network Interface Card (NIC) – Teaming should be used to increase the reliability and to I/O between the Provisioning Servers and the Target Devices
- 3. 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 The following diagram outlines a basic Provisioning Server + Windows File Share (CIFS) architecture:
- 4. 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. Pros for this solution are: • 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 Cons for this solution are: • 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 • 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 The following diagram outlines a basic Provisioning Server + Windows File Share (CIFS) architecture:
- 5. 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. Pros for this solution are: • 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 Cons for this solution are: • 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 • 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 • Dedicated NIC - Teams should be used for loading the vDisks and for delivering the vDisks to the Target Devices
- 6. 6
- 7. 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. Pros for this solution are: • 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 Cons for this solution are: • 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: • Network Interface Card (NIC) – Teaming should be used to increase the reliability and to I/O between the Provisioning Servers and the Target Devices
- 8. 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. o This option generally provides the fastest performance, as the client is using its own physical resources to store the cache file on the local hard disk.
- 9. 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 automated as well.
- 10. 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. • Hardware-based load balancing (NetScaler): When using hardware-based load balancers (such as NetScaler) all load balanced services can be checked for availability and functionality at regular intervals. If you experience an outage on one of the servers or services, it gets automatically removed from the load balancing list. So instead of configuring DHCP option 66 for a FQDN or referring directly to a TFTP server, a NetScaler vServer could be created to provide all levels of redundancy for this service and its IP address would be used for this DHCP option.
- 11. 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. The Provisioning Server and TFTP service architecture of such a configuration is outlined below:
- 12. 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 communication issues due to inconsistent DNS (FQDN) resolutions. This can be caused by TTL settings of DNS records.
- 13. 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. Copyright © 2008 Citrix Systems, Inc., 851 West Cypress Creek Road, Ft. Lauderdale, Florida 33309-2009 U.S.A. All rights reserved. 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 851 West Cypress Creek Road Fort Lauderdale, FL 33309 954-267-3000 http://www.citrix.com Copyright © 2008 Citrix Systems, Inc. All rights reserved. Citrix, the Citrix logo, Citrix ICA, Citrix MetaFrame, and other Citrix product names are trademarks of Citrix Systems, Inc. All other product names, company names, marks, logos, and symbols are trademarks of their respective owners.