Embed Size (px)
Citation preview
XenDesktop - Design Handbook
Your guide to design areas, recommendations and overall architectural best practices for XenDesktop
Citrix Consulting
White Paper
Contents
Introduction ................................................................................................. 1
Overview .......................................................................................................................................... 2
Executive Summary ......................................................................................................................... 3
User Community ......................................................................................... 4
Overview .......................................................................................................................................... 5
User Groups ..................................................................................................................................... 5
Endpoints ......................................................................................................................................... 5
Replaced Endpoints ............................................................................................................ 5
Repurposed Endpoints ....................................................................................................... 6
Reused Endpoints ............................................................................................................... 6
Usage Habits .................................................................................................................................... 7
User locations .................................................................................................................................. 8
Infrastructure............................................................................................... 9
Overview ........................................................................................................................................ 10
Virtualization Infrastructure ............................................................................................................ 10
Virtualized Components .................................................................................................... 10
Resource Pools ................................................................................................................. 11
OS Delivery .................................................................................................................................... 12
Antivirus ............................................................................................................................ 12
Bootstrap Redundancy ..................................................................................................... 13
Device Collections............................................................................................................. 14
High-Availability ................................................................................................................. 14
Optimization ...................................................................................................................... 15
SQL Database ................................................................................................................... 15
vDisk Storage Location ..................................................................................................... 16
vDisk Type ........................................................................................................................ 17
Write Cache Encryption .................................................................................................... 18
Write Cache Location ........................................................................................................ 18
Application Delivery ........................................................................................................................ 21
Application Controller (Web Interface) .............................................................................. 21
Application Integration ...................................................................................................... 22
Application Streaming Cache ............................................................................................ 24
Desktop Delivery ............................................................................................................................ 27
Desktop Delivery Controller .............................................................................................. 27
Farm Design ...................................................................................................................... 28
Access Design ............................................................................................................................... 30
Resource Delivery ............................................................................................................. 30
Internal Site Access .......................................................................................................... 31
Personalization ......................................................................................... 33
Overview ........................................................................................................................................ 34
Virtualization Infrastructure ............................................................................................................ 34
Desktop Design .............................................................................................................................. 34
Virtual Machine Specifications .......................................................................................... 34
Desktop Images ................................................................................................................ 34
Profiles Design ............................................................................................................................... 35
Policy Design ................................................................................................................................. 36
Implementation & Support ........................................................................ 38
Maintenance ................................................................................................................................... 39
Antivirus ............................................................................................................................ 39
Revision History ............................................................................................................................. 40
1
Part I
Introduction
2
Overview The XenDesktop Design Handbook contains a collection of the best practices for designing a XenDesktop solution. The handbook is meant to be used by consultants and architects in the designing of an appropriate XenDesktop solution. This handbook was put together based on the experiences and commitment from the following people:
Daniel Feller: Daniel is a Lead Architect within the Worldwide Consulting Solutions group at Citrix. Daniel has worked with enterprise customers for more than 10 years around application and desktop delivery. Daniel authored several well-known whitepapers including “Designing an Enterprise XenDesktop Solution for 10,000 users”, “Provisioning Services for XenApp”, and “Taking XenApp to the Next Level of Availability with NetScaler”. Currently, Daniel focuses on continuing development of design best practices for XenDesktop, Provisioning Services for XenApp, and Virtualizing XenApp. You can follow Daniel in his blog posts (http://community.citrix.com/blogs/citrite/danielf) and with Twitter (http://www.twitter.com/djfeller).
Thomas Berger: Thomas is a Principal Consultant within the Citrix Consulting Central Europe team and is based in Switzerland. Thomas is currently focusing on XenDesktop, Provisioning Services, XenApp and XenServer practices for enterprise customers. Thomas played a major role in the development of the XenDesktop best practices based on his experiences with enterprise customers.
Nick Rintalan. Nick is currently an Architect with the Citrix Consulting organization. He has spent the last five years assisting customers with the analysis, design and implementation of various Citrix products and technologies. Nick has spoken at iForum conferences on topics such as EdgeSight for Load Testing and Application Streaming. He has authored several well-known whitepapers such as “Top 10 Items Found by Citrix Consulting on Assessments” and “Application Streaming Best Practices”. In addition to holding his CCIA, MCSE, MCITP, CCNA and PMP certifications, Nick holds a Bachelor‟s and Master‟s Degree in Computer Engineering from Tulane University.
Elisabeth Teixeira: Elisabeth is a Principal Product Specialist within the Worldwide Technical Readiness group and has been a Citrix employee since 2000. Before joining the Worldwide Technical Readiness Group, she worked in Technical Support as a team lead for the XenApp group for North America and Latin America. Currently she is focused on the technical readiness aspects of Provisioning services and the integration of it into XenApp, XenDesktop, and Citrix Essentials. Elisabeth participated in early stages of Provisioning services implementations at customers to provide best practices and expertise to ensure a scalable and high performing environment.
Tarkan Koçoğlu: Tarkan is a Senior Architect within the Worldwide Technical Readiness group and has been a Citrix employee since 2001. Tarkan has worked as a Citrix consultant at numerous customer projects in EMEA by assessing, designing and building enterprise-level architectures to successfully deliver applications using Citrix technologies. Moving over to headquarters in 2007, Tarkan has been heavily involved in technologies related to server virtualization and desktop virtualization. You can follow Tarkan in his blog posts (http://community.citrix.com/blogs/citrite/tarkank) and with Twitter (http://twitter.com/TarkanK).
Scott Campbell. Scott is currently a Principal Consultant for Citrix. Over the past five years, he has assisted many enterprise level customers implementing Citrix solutions in correspondence with Citrix best practices. Scott has been focused almost exclusively on XenDesktop and related technologies since mid 2008. Scott holds his CCIA and MCSE certifications as well as a Bachelors degree in Electrical Engineering with the Computer Engineering option from UCLA.
3
Executive Summary Welcome to the XenDesktop Design Handbook.
Virtual desktop delivery is a new enterprise initiative whose goal is to simplify, secure and deliver optimized desktops. Virtual desktops are a massive change to the way organizations manage and deliver desktops. The Citrix XenDesktop solution provides an approach for creating, building and delivering virtual desktops by virtualizing a standard desktop into different layers. However, in order to create a XenDesktop environment, requirements, goals and a complete design must be completed.
The subsequent sections of the XenDesktop Design Handbook identifies the core design considerations and offers options, recommendations and justifications to be used with every XenDesktop design project. With a proper analysis and design, a XenDesktop solution will be manageable, extensible and maintainable. The handbook is broken down into the following parts with appropriate subsections:
User Community: This section identifies the different user groups, their needs and their current challenges. This information provides insight into deciding if a virtual desktop solution is the correct solution to solve the challenges.
Infrastructure: This section focuses on the underlying components used to support the infrastructure based on the XenDesktop layered approach. Delivery aspects of the solution, which includes operating system, applications and the overall desktop are discussed. Areas such as XenServer, XenApp, XenDesktop and Provisioning Services are detailed in this section.
Personalization: This section focuses on those concepts that creates a personalized environment for each user. Items of importance are around policies, profiles, printing, and access design.
Maintenance: This section focuses on the processes and tasks required to build, maintain and migrate into and within a virtualized desktop environment. Areas of focus include physical/virtual migrations, application and operating system updates and infrastructure migrations.
This is the second release of the XenDesktop handbook and has been expanded to include more design areas.
4
Part II
User Community
5
Overview Before the architecture can be designed, there must be a thorough understanding of the user environment. Without knowing the number of users, the type of applications, the locations of users, it becomes difficult, if not impossible, to design a solution meeting the needs of the organization.
This section focuses on the user community. It discusses the key requirements having a direct impact on the overall XenDesktop design. The identified sections are as follows:
User Groups
Endpoints
Usage Habits
User Locations
User Groups Determining the user groups, requirements, locations and population helps define the overall requirements for a virtual desktop deployment. The initial identification and definition of the users groups gives the design a starting point. Once this information is obtained, the design can drill down into more of the details around endpoints, location requirements and desktop requirements.
As the user group discussion focus is at a high-level, it is necessary to get a general understanding of each major group. The information obtained for each user group should include the following
Description: A brief overview of the user group. What is their role within the organization and how do they operate.
Location: A general overview of the location for the user group. This should include information like headquarters, regional office(s), branch office(s) and remote user(s).
Population: In order to determine the infrastructure required to support each user group, a general population is required, ideally broken down by primary data center.
Requirements: An overview of the group‟s technical requirements. This should include applications, specialty hardware and any other need in order to be productive.
Current Challenges: A list of current challenges experienced with the current environment. This information helps provide insight into the organization and offers suggestions for not introducing the same challenges into the new environment.
Endpoints The endpoints connecting to the XenDesktop environment must be assessed and categorized in order to create a proper design. XenDesktop supports numerous endpoints, each having a direct impact on scalability, architecture, and delivery.
Replaced Endpoints
Certain endpoints have reached the age where they are no longer able to function. Many of these devices are experiencing hardware failures due to their age and must be replaced. Instead of purchasing a high-power endpoint device, a much lower-priced desktop appliance is a suitable option. When the desktop appliance starts, the user authenticates and is delivered a virtual desktop hosted within the data center, which requires the following infrastructure:
XenServer - hosts the virtual desktop
Provisioning Services – delivers the desktop image to the virtual machine
6
XenDesktop Controller – maintains hosted desktop status
Although more hardware is required to support a hosted desktop for each replaced endpoint, the endpoint requires little in terms of management and maintenance, if implemented correctly. The following are recommendations for replaced endpoints:
Centralized Image Management: The desktop appliances must be maintained with the latest updates. A centralized tool should be made available that can keep all desktop appliances in sync with the organization‟s standard.
Limited Functionality: The desktop appliance should be simple and easy for the user to gain access to the virtual desktop. This means that the desktop appliance should request credentials then auto-launch the user‟s approved virtual desktop. This creates a simplified and fast user experience.
Repurposed Endpoints
Older endpoints that have reached the end of their usefulness can have their lifetimes extended by being repurposed as desktop appliances. These repurposed desktops are locked down and configured to only access a hosted virtual desktop within the XenDesktop environment. Repurposed endpoints require a hosted virtual desktop, which requires the following infrastructure:
XenServer - hosts the virtual desktop
Provisioning Services – delivers the desktop image to the virtual machine
XenDesktop Controller – maintains hosted desktop status
Although more hardware is required to support a hosted desktop for each repurposed endpoint, the endpoint requires little in terms of management and maintenance, if implemented correctly. The following are recommendations for repurposed endpoints:
Operating System: Enable the operating system to automatically download and install new updates.
Antivirus: Although the operating system is locked down, it is still recommended to install an antivirus solution on the repurposed endpoint. The antivirus should be configured in a hands-off mode where all updates occur automatically.
Citrix Receiver: As the repurposed endpoint is taking on the role of desktop appliance, the Citrix Receiver should be configured to utilize the locally logged in credentials to receive the hosted desktop. With proper configuration, the Citrix Receiver allows the support staff to view the repurposed endpoint with Citrix GoToAssist if the user runs into local issues.
Reused Endpoints
Reused endpoints are workstations that have already gone through an organization‟s desktop refresh cycle. These devices have more powerful processers, larger amounts of RAM and greater hard drive capacity. They can run the latest operating systems and applications without problems. If these devices were to use a hosted desktop, the local hardware would be idle, wasting the investment of the organization. For reused endpoints, a provisioned desktop image is recommended in that it provides an identical operating environment as repurposed endpoints except that local hardware is used instead of the hardware in the hosting environment. Reused endpoints place a smaller burden on the XenDesktop infrastructure as compared with repurposed endpoints. In fact, reused endpoints only require the following infrastructure components:
Provisioning Services – delivers the desktop image to the physical endpoint
A reused endpoint does not communicate with the XenDesktop backend or the virtualization infrastructure. Provisioning Services streams the desktop image to the reused endpoint. All processing and functionality is contained on the endpoint. In order to function properly, these devices should be configured as follows:
7
BIOS: The reused endpoints should be configured with a network startup using PXE or another approved method.
Network: If multiple reused endpoints are on the same network, the endpoints should be connected to the Provisioning Services through a high-speed network of at least 1 gigabit Ethernet. Utilizing a 100MB network would slow down Reused Endpoint<->Provisioning Services communication, potentially impacting the user experience.
Usage Habits One of the biggest deciding factors when identifying if a user requires a virtual desktop or an application is focused on how the users interact with the system. Many users focus on a specific task, completely contained within a single application, while others work across many different applications, modifying components within the environment thereby creating a fully personalized environment. Identifying who should be delivered a virtual desktop and the functionality required plays a large impact in the overall design of the environment from a disk image and scalability perspective.
The following table outlines different user examples and how they align with the respective application/desktop solution.
Description Virtual Apps
Hosted Desktop
Streamed Desktop
Installed Desktop
Structured Workflows
Follows same process and often uses a few applications. This group of users typically includes order entry, nurses and supervisors.
X
Unstructured These users interact with any number of applications and often obtain different tools/plugins in order to create appropriate materials. This group typically includes consultants, marketing, middle/senior managers.
X
Mobile Users These users, due to their job, must continue to operate and work with applications while disconnected. This group typically includes consultants, sales, and executives.
X
Heavy System Usage
Certain users require extensive system resources in order to analyze, utilize and develop high-definition/complex content. This group typically includes graphics designers,
X
Hardware Integration
Certain users require a direct link between their workstation and a local piece of hardware. For example, call center employees have their desktop linked with their phone number. When a person calls the call center employee, the application retrieves the caller‟s information and displays it on the correct desktop.
X
Developers Users who create new systems and applications for an organization utilize development environments that can compromise the stability of the operating system. These users typically include programmers, engineers and support.
X
Many users fall into different categories based on the particular function they are performing. Although a user might be aligned with a hosted desktop solution, there is still the possibility that certain portions of their job are best performed in a hosted application fashion. Most users should be given the freedom to choose the best operating environment based on their current need.
8
User locations User locale is a major design consideration for any virtual desktop design. Not only will the user locations impact the security and remote access design, but it also impacts the architecture if streamed desktops are used. The ability to centrally manage and maintain desktops is one of the key driving factors for any virtual desktop infrastructure (VDI). When looking at the user environment, the following details must be taken into account, which are used during the design of the virtualization infrastructure, desktop delivery and OS delivery sections.
Each regional office within the organization should have the following identified:
Data Center:
o Primary: Each regional office is typically defined with the most preferred data center. This information will help in determining the size and scope of the XenDesktop solution within the data center.
o Secondary: Each regional office typically has a business continuity plan in place identifying the preferred backup data center. This information helps determine the levels of fault tolerance and extra capacity needed in the backup data center.
Virtual Desktop Type
o Hosted: Users within regional offices utilizing a hosted virtual desktop help determine the size requirements for the XenDesktop infrastructure at the data center.
o Streamed: Users who need and whose hardware is capable of supporting a streamed virtual desktop must be identified. If the WAN connections between the regional offices and the data center are not large enough, a distributed Provisioning services solution is required – although it can still be managed centrally.
9
Part III
Infrastructure
10
Overview The second area of focus for a XenDesktop design is on the overall infrastructure. The XenDesktop environment is broken down into 6 layers:
Virtualization Infrastructure
Operating System Delivery
Application Delivery
Desktop Delivery
Access Design
These layers are merged together to create a unique desktop based on common components running on top of a common infrastructure. Deciding on the best decision for each of the key decisions should be based on user requirements and business requirements. Also, each decision will, in turn, have an impact on the rest of the architecture. The follow sections will help identify, define, explain and propose options for each of the core design decisions.
Virtualization Infrastructure The virtualization layer of XenDesktop is a crucial component to the overall architecture. This layer allows the environment to scale without requiring a 1:1 relationship between component and physical server. By properly designing the XenDesktop environment, one can not only better utilize the hardware but also improve availability and simplify management. This section focuses on
Virtualized Components
Resource Pools
Virtualized Components
Determining which components to virtualize requires a balance of performance with better utilization and fault tolerant capabilities. Regardless of the XenDesktop component, the following are the expected benefits with virtualization with XenServer:
Better utilized hardware resources: Many of the XenDesktop components only stress one aspect of a server. Provisioning services impacts the network interface card while the XenDesktop controller impacts the processor. By virtualizing the components, all aspects of a server are better utilized.
Better fault tolerant options: XenServer virtualization allows for greater levels of fault tolerance through the use of XenMotion and High-Availability.
o XenMotion: By virtualizing the XenDesktop components, each server can be moved to another physical server without incurring downtime for the environment. This allows the organization to provide ongoing hardware maintenance before a hard failure appears.
o High-Availability: If a hard failure is experienced, XenServer will automatically restart critical components as needed across any other physical server. This helps reduce the impact of an unexpected failure to the environment.
By adding the virtualization layer underneath the server‟s operating system, there is the impact of slightly poorer system performance. Adding any virtualization layer will incur a performance hit, the hit is dependent on the system being virtualized.
11
Based on these aspects, the following are the general recommendations for XenDesktop component virtualization:
Component Virtualize Justification
XenDesktop Controller
Yes The primary XenDesktop controller incurs a significant processor impact when many (hundreds/thousands) virtual desktops are started concurrently. Once the startup sequence completes, the overall processor utilization falls to negligible levels.
During the same time, the secondary XenDesktop controllers experience minimal utilization, regardless of the time. The secondary controllers are responsible for virtual desktop registrations.
Each one of these functions occurs without user involvement or interaction. Any performance impact virtualization adds to the controllers is not experienced by the user.
Provisioning services
No/Yes In enterprise-level environments, Provisioning services maximizes usage of the network layer on the server. Adding a layer of virtualization to the server will have a negative impact on Provisioning service scalability, resulting in additional hardware for the environment. Also, Provisioning services provides its own high-availability options. If one Provisioning services server fails, the streamed desktops reestablish a connection to another Provisioning services server. XenServer high-availability options only provide the server with the ability to automatically restart on a different physical server.
However, Provisioning services does not utilize large amounts of RAM or processor, even when the network is fully utilized. Virtualizing Provisioning services can allow other non-network impacting virtual servers to be co-hosted on the same physical server. The new virtual servers could consume the underutilized RAM and processors.
XenApp Yes XenApp servers, depending on the hosted applications, either maximize processor or memory, but rarely both at the same time. Also, if a single XenApp server fails, every user connected to that one server losses their session and potentially their data. The fault tolerant options incorporated with XenServer helps mitigate this risk by allowing for server migration while users are connected with XenMotion. This feature can help overcome impending hardware faults before they impact the user. Even though the XenServer has an impact on overall server scalability, many XenApp servers are not fully utilized, thus having little impact on the overall hardware requirements for the environment.
Web Interface Yes The Web Interface servers are typically idle, except for the morning surges in user connections. Adding a layer of virtualization has little impact on the overall hardware requirements as these servers are already underutilized. Besides allowing the Web Interface server to share hardware resources with other virtual servers, the other benefit of virtualizing is in the ability to dynamically move the Web Interface server to another physical server. This allows the server to continue to operate or be restarted on another device, even if the previous server fails.
Resource Pools
All virtualized XenDesktop components must belong to a XenServer resource pool if the high-availability options are to be utilized. The design decision typically revolves around whether to create resource pools for a shared infrastructure or a segregated infrastructure.
Description Benefits Concerns
Shared Each resource pool contains virtual servers for any XenDesktop component.
More likely that all server resources are utilized equally
If multiple resource pools are required, need to design multi-resource pool components
Segregated Each resource pool only contains virtual servers for a single or a few XenDesktop component(s).
Easier to manage multi-resource pool designs and high-availability options
End up not fully utilizing all aspects of a server as one component typically maximizes one resource
Depending on the size of the XenDesktop environment, the decision between shared and segregated might be a non-issue. With smaller environment, a single resource pool provides enough capacity for the entire XenDesktop environment. However, for larger implementations (5000+ hosted desktops), multiple resource pools might be required. In this situation, using a shared resource pool model
12
requires each component is available in each resource pool. Configuring high availability across resource pools is a challenge, especially when one needs to guarantee that a single component is always available. Based on the challenges with a shared resource pool model, a mixed resource pool model is recommended, which resembles like the following:
Shared Resource Pool: The shared resource pool includes all virtualized XenDesktop components except hosted desktops. The shared resource pool allows the servers to be better utilized and simplifies high-availability configurations for the XenDesktop infrastructure components. The XenDesktop infrastructure components are able to reside within a single resource pool with plenty of extra capacity available if required for other services.
Segregated Resource Pool: The segregated resource pool only includes hosted desktops. For larger environments (5000+ hosted desktops), additional resource pools might be required. Because the resource pool only contains hosted desktops, configurations, high-availability options and maintenance is simplified.
OS Delivery Delivering the virtual desktop image to any number of hosted and streamed desktops is the responsibility of the Provisioning services layer. Provisioning services delivers a vDisk to an endpoint, which can be a virtual machine or a physical PC. The same vDisk can be used across multiple types of physical and virtual devices, thus allowing a single vDisk image to be used for thousands of endpoints. Designing the Provisioning services layer requires an understanding of the organizational environment and user location. From there, the following are the core design decisions:
Antivirus
Bootstrap redundancy
Device Collections
High Availability
Optimizations
SQL database
vDisk storage location
vDisk type
Write cache encryption
Write Cache Location
Antivirus
An antivirus solution is important to protecting the user and the business from viruses that look to disrupt business operations and steal sensitive data. However, improperly configuring an antivirus solution can negatively impact Provisioning services. If many streamed and hosted desktops are configured to perform a full system scan at the same time, this process will have a large impact on Provisioning services resulting in decreased scalability. To optimize antivirus configuration for a hosted and streamed desktop, the following are the design recommendations:
Data Level: The first layer for virus protection is the data level. Any server storing user and business data must be protected with an antivirus solution. Data hosting servers often include database server, mail servers and file server – containing home directories, profiles, and mapped drives. The antivirus solution should be running on these systems to actively scan this highly dynamic data.
Application Level: Through the use of application virtualization, XenApp helps isolate the application from the data. Because the data is stored on separate file servers protected with
13
an antivirus solution, the XenApp servers only require monitoring of the local system. The following Citrix Support article describes the strategy, process and configuration. http://support.citrix.com/article/CTX114522
Desktop Level: The third layer for virus protection is the desktop layer. When the virtual desktops are booted from a common vDisk, the shared vDisk is read only. Once a clean vDisk is created and established as the source image for virtual desktops, target virtual desktops can be rebooted to the clean image. If a full scan is done before converting the vDisk to a standard image, then the vDisk can be considered free from virus infection and scanning files as they are read is not necessary. Because users are interacting with the desktop, based on a clean vDisk image, the following are some suggested antivirus strategies for the virtual desktop:
o Only scan create/modify activity of the files rather than scan any of the folders on the image
o Scan on write events only
o Scan local drives only
o Exclude the pagefile from being scanned
o Exclude the Print Spooler directory to improve print performance
o Exclude the heavily accessed local database such as EdgeSight if installed
o If ICA connections are used, exclude the Client bitmap cache and the Client folders
o Removing the antivirus-related calls from the HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\Current Version\Run registry key to improve performance
o More secure environments, may need to scan all incoming and outgoing data, whereas many enterprises find that only scanning incoming data is sufficient
Bootstrap Redundancy
Within a Provisioning services implementation, the Trivial File Transfer Protocol (TFTP) service is used to deliver the Provisioning Server bootstrap. The bootstrap file contains, besides various configuration settings, a list of available Provisioning services servers within the environment. All information about the location and name of the bootstrap file is delivered by the DHCP Server upon request by the Target Devices through DHCP options 66 (Boot Server Host Name) and 67 (Bootfile Name).The following options exist for providing redundancy within the bootstrap file:
Description Benefits Concerns
Provisioning Services PXE
Configure PXE + TFTP on every Provisioning services server. Put each Provisioning services address as first entry within the bootstrap config hosted on itself. Select 3 other Provisioning services spread through the whole environment as the other 3 entries within the bootstrap config.
Multiple parallel PXE services provide high level of redundancy
No additional hardware or configuration at other infrastructure systems required
The bootstrap needs to be maintained on every PVS
No control over which servers are delivering the bootstrap (first responding server wins)
Provisioning services servers and clients need to be within the same subnet
DNS Round Robin
A fully qualified domain name can be configured within DHCP option 66. The FQDN can be configured for DNS Round Robin, which means that it contains not a single IP address but a list of multiple IP addresses. In this scenario, all systems corresponding to the IPs configured are used rotationally.
Bootstrap file needs to be maintained on the TFTP servers only
No PXE required as Provisioning services can be hosted within another Subnet
Bootstrap delivery is limited to a known group of
DNS does not check whether the systems are operational before resolving the FQDN to an IP address. This could result in a situation where one of the two systems is down, which results in 50% of the booting Target Devices failing to receive their bootstrap file.
14
servers, which allows for easier troubleshooting
To minimize the impact of an outage, a very short DNS Time-To-Live (TTL) for the FQDN can be configured.
NetScaler Load Balancing
When using hardware based load balancers (i.e. Citrix NetScaler) all load balanced services can be checked for availability and functionality at regular intervals before requests are sent to the service. In the event of an outage of one service, NetScaler will automatically detect and reroute requests to the remaining available services. Instead of configuring DHCP option 66 for a FQDN of a TFTP server, the NetScaler load balanced virtual IP address would be used.
Bootstrap file needs to be maintained on the TFTP servers only
No PXE required à PVS can be hosted within another Subnet
Bootstrap delivery is limited to a known group of servers à easier troubleshooting
Very complex configuration
Additional cost (Hardware / TFTP + OS licenses)
ISO File Create a ISO file containing the bootstrap and all required configuration (incl. 4 PVS boot servers) by means of the BDM tool
Put this file on a redundant CIFS / NFS File Share
Connect this file share to your XenServer Resource Pool
Attach the ISO file as virtual CDROM to your virtual machines and configure them for boot from CDROM
Easy setup
No additional cost (assuming a redundant file server is already in place)
No PXE required à PVS can be hosted within another Subnet
ISO file needs to be maintained on the network share only
Limited to virtual environments
Mapped CDROM might confuse users (if drive is not hidden by means of GPOs)
Note: Due to current limitations of how NetScaler load balances TFTP servers, it is required that the NetScaler MIP / SNIP is set as the default gateway on the TFTP servers. This means that all communication between the TFTP servers and the TFTP clients will be handled by the NetScaler. Therefore it is required to use stand alone TFTP servers rather than the build-in TFTP service on a PVS server. Please refer to CTX116337 for further information.
Device Collections
The number of defined target devices within a production environment could include thousands of desktops. Trying to remember the purpose, role, configuration of each target device is an impossible task without proper organization. Within the Provisioning Server console, target devices can be grouped into different folders, called device collections.
Recommendations
To better organize the target devices, it is advantageous to use device collections. Creating a single collection for each vDisk might appear to be the best practice at the outset of a XenDesktop deployment, but it will limit possibilities later on. Initially, a single vDisk will be used for multiple groups of users across many different business units. As time progresses and each business unit has specific requirements, the chances are high that additional target device settings will be required. Also, if a single vDisk image is used for many different business units, that one device collection will contain thousands of target devices. The recommendation is to:
Create a device collection for each business unit.
Create a template target device within each device collection and configure the template target device with the appropriate class, vDisk assignment, personalization settings, etc.
Set the template target device for the device collection. Setting a template for the collection will make all other target devices within the collection take on the same parameters and settings, helping to guarantee consistency within the business unit.
High-Availability
15
Providing high-availability to the Provisioning services component of XenDesktop can be designed with many different configurations and options. These design decisions can be found in the Citrix article: Provisioning Server High Availability Considerations (CTX119286)
Optimization
Provisioning services acts like a network switch, all traffic that occurs between the vDisk and the Provisioning services client (target device) passes through Provisioning services regardless of where the vDisk resides. The operating system offers file caching and can improve vDisk deployment efficiency. The OS caches file read data at the block-level. If a single target device is booted from a shared vDisk - subsequent clients will not require disk read IO to do similar operation. The OS caching mechanism only caches the blocks that were accessed, NOT the whole vDisk file. The file read data stays in the cache until it is forced out to make space for other data. If the Provisioning services
server is optimized for file caching and has the largest file cache as possible, then the streaming of the vDisk is faster as it won't come from disk (HDD) but instead be accessed from cache (RAM).
Hosting Provisioning services on a Windows 2008 Server allows for greater file cache as operating system limitations have been significantly increased between Windows 2008 and 2003. Using Windows 2008 and allocating additional RAM to the server, more of the vDisk file can reside within the file cache, thus optimizing vDisk delivery.
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. Further information about how to configure a highly available Microsoft SQL Server environment can be found at the Microsoft TechNet: http://msdn.microsoft.com/en-us/library/ms190202.aspx.
Unlike Citrix XenApp implementations, the Provisioning services configuration database is a highly critical component which needs to 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 needs to be configured in a fully redundant manner.
With the release of Provisioning Server 5.1 the new Offline Database Support feature was introduced, to solve this challenge.
The Offline Database Support option allows Provisioning services to use a snapshot of the Provisioning services database in the event that the connection to the database is lost. This option is disabled by default and is only recommended for use with a stable farm running in production. It is not recommended when running an evaluation environment or when reconfiguring farm components „on the fly‟. Only a farm administrator can set this option.
When offline database support is enabled on the farm, a snapshot of the database is created and initialized at server startup. The snapshot is continually updated by the Stream Process. If the database becomes unavailable, the Stream Process uses the snapshot to get information about the Provisioning services and the target devices available to the server. When the database connection becomes available, the Stream Process synchronizes any Provisioning services or target device status changes made to the snapshot, back to the database.
Considerations
The following features, options, and processes remain unavailable when the database connection is lost; regardless if the Offline Database Support option is enabled:
Auto Add target devices
User Groups
Auto Update or Incremental vDisk updates
16
vDisk creation
Active Directory password changes
Stream Process startup
vDisk Storage Location
Each Provisioning Server within the farm must access the appropriate vDisk and stream portions of the vDisk to the target devices as needed. The location of the vDisk will have an impact on Provisioning Server functionality and speed.
Common Options:
There are essentially two different options for the vDisk storage location, but both options will have an impact on items like Provisioning Server high-availability.
Shared Storage
o The shared storage option uses an enterprise storage solution to host the vDisk images. The shared storage solution should have ample storage to host as many vDisk images as needed for the organization. Also, the enterprise storage solution is optimized for file hosting, which will help improve speed of delivery. However, using shared storage requires the Provisioning Server streaming service to cross the network or channel to get to the vDisk. This might take extra time and resources as opposed to the local storage option.
o Using the shared storage solution makes the setup and maintenance of Provisioning Server high-availability easy. Each Provisioning Server within the farm will be configured to use the same shared storage device. Because each server can get to the vDisk, all servers can participate in high-availability.
o Using shared storage guarantees that each Provisioning Server is using the correct vDisk image, as each server is looking at the same location.
o Recommendation: Using a SAN (iSCSI / FC) as shared storage requires a distributed or clustered file system to be installed on all Provisioning services servers. This might introduce additional cost and complexity. With the release of Provisioning services 5.1, a feature called Read-only LUN has been introduced. This option allows the mapping of a certain LUN as a read only vDisk storage repository for all Provisioning services in a Farm without the need for a distributed or clustered file system. In such a scenario, server-based write cache needs to be stored on a central store separate from the vDisk store.
Local Storage:
o Setting up a local storage solution for Provisioning Server is the easiest and least expensive option. Essentially, all vDisks that the Provisioning Server will deliver are stored on the local disks of the Provisioning Server. Provisioning Server's streaming service will access each vDisk and deliver the appropriate portions of the vDisk to the target devices.
o Although at first glance it would appear that shared storage is required for Provisioning Server high-availability, which is not the case. Each Provisioning Server within the farm must be able to get to the vDisks via the same path. If the vDisks are copied to each Provisioning Server and placed in the same local path, high-availability will be possible.
Recommendations:
To help keep costs in check, the best option for vDisk storage location is Local Storage
Each Provisioning Server will have ample storage space that should not be wasted.
17
Using local storage will provide adequate speed and still allow for the high-availability option.
Processes must be put in place that guarantees the vDisks on each Provisioning Server are in sync with each other.
Alternatives:
Although the general recommendation is to use local storage for the vDisk, large scale implementations will be better served using shared storage. As most enterprise deployments of XenDesktop will utilize a shared storage solution for other aspects, integrating a portion of the infrastructure for the storage of Provisioning services vDisks should not impact the bottom line, while providing easier supportability.
vDisk Type
Provisioning Server allows for the delivery of a vDisk in three different modes: Private, Standard and Differential. Each option has benefits and consequences to the larger XenDesktop solution.
Common Options:
Private Image: The first vDisk type is Private Image vDisk, where each target device will have its own vDisk. The vDisk is configured in a read/write fashion, where all changes are stored within the vDisk for future use.
o Benefits:
Complete personalization of the environment because all changes are stored, but at a cost of storage and support.
o Considerations:
Support of the vDisk will become increasingly difficult as each vDisk will take on a completely different personality based on user behavior.
Private images are a one-to-one relationship with users, which can require an extensive amount of disk space.
Standard Image: The second vDisk type is a Standard Image vDisk, where multiple devices share the same base vDisk image. The vDisk is a read-only and target device changes are stored in a write cache file. Upon reboot of the target device, the write cache is destroyed, resulting in the target device starting with the same base image time-after-time.
o Benefits:
Server revert back to a consistent, optimized and approved state after each reboot
Storage requirements are reduced as the write cache is reset after each reboot
o Considerations:
Any user-installed application is not kept, resulting in potential user frustration if important updates are not part of the base vDisk image or delivered via XenApp.
Any application or system-level automatic updates will start after each reboot, unless this functionality is disabled at the OS and application level.
Differential Image: The third vDisk type is a Differential Image vDisk, where multiple devices share the same base vDisk image. The vDisk is read-only and the target device changes are stored in a differential cache file. Upon reboot of the target device, the differential cache is kept and reused by the target device after reboot.
o Benefits:
18
Allows for greater levels of system personalization by not discarding changes upon subsequent reboots.
o Considerations:
Once the base vDisk is modified, the differential image is destroyed and the user must rebuild their personality into the target device. This will cause confusion.
Supported vDisk type for XenDesktop 3.0 implementations.
Recommendations:
For the majority of XenDesktop use cases, a Standard image is the recommended approach. The standard image simplifies maintenance and maintainability of the images as well as uses the least amount of disk space. It is imperative that a proper application analysis is completed to identify all user-required applications. There should also be a process in place to allow users to request new applications into the environment.
Even though the Standard Image is the best approach for most XenDesktop implementations, there will be a few use cases where a Private Image is needed. This will most likely result in a small set of users who have such unique and changing requirements that it is easier to create private images with the acknowledgement that maintenance of the image will require additional time.
Write Cache Encryption
The data stream (along with the write cache) can be encrypted to provide additional security.
Common Options:
Normal
Encrypted
Recommendations:
Unless security guidelines require data to be encrypted, this should not be enabled as it adds extra load to the Provisioning Services processors.
Write Cache Location
Using a standard vDisk image (read-only) allows many desktops or servers to utilize the same vDisk image at the same time. Because the vDisk is read-only, the aggregate of these changes are stored in a write cache.
The write cache contains anything that has changed during the time between target device reboots. Each target device has its own write cache. Depending on what the target device is doing and how the environment is configured, the write cache could grow quite large. For instance, starting the target device adds to the write cache. If an application is streamed onto the target device, the streamed application profile will also increase the size of the write cache
The size of the cache file for each target device depends on several factors, including types of applications used, user workflow, and reboot 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 gets rebooted daily is about 300-500MB. If workstations are rebooted less often than 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.
Provisioning Server allows for numerous locations to store the write cache, each brining benefits on considerations. The options are:
Target Device – RAM
19
Target Device – Local Storage
Target Device – Shared Storage
Provisioning Server – Local Storage
Provisioning Server – Shared Storage
Common Options:
Target Device – RAM
Definition: The first option for write cache storage location is the target device‟s RAM. A portion of the target device‟s RAM is set aside and used for the write cache.
Benefits: The main benefit for using the target device‟s RAM is it provides the fastest type of write cache.
Concerns
o A portion of the RAM cannot be used for the target device workload. RAM is often better used for the operating system and applications than for write cache. Plus, using RAM to support the write cache is more expensive than using storage.
o Part of the challenge with using RAM as the write cache storage is determining the amount of RAM required. Provisioning Server can set aside a certain portion of RAM for the write cache, but what happens when the RAM runs out? The write cache is critical to the stable functioning of a provisioned target device. When available write cache is exhausted, the target device can no longer make changes, which results in a target device failure. If the write cache size is not estimated correctly, using a target device‟s RAM might pose detrimental to the stability of the environment.
Target Device – Local Storage
Definition: The second option for write cache storage location is the target device‟s local storage. This storage could be the physical disk drives on the physical server, or it could be the virtual disk on a virtual server
Benefits:
o This solution does not require additional resources, in that most target devices being purchased already have local disks installed and unused.
o Although target device local storage is not as fast as RAM, it still provides fast response times because the read/write to/from the write cache is local, meaning that the requests do not have to cross the network.
o Trying to estimate the size of the write cache is difficult and if done incorrectly, can result in target device failure. However, local storage typically provides more than enough space for the write cache, without requiring the administrator to estimate space requirements.
o This option provides added resiliency in the event of a failure since only a single target device will be affected if the local disk associated with the system should run out of space.
Concerns:
o If the target device is virtualized, using local storage will prevent live migration processes from succeeding because the storage is not shared across virtual infrastructure servers, like XenServer.
Target Device – Shared Storage
20
Definition: The third option for write cache storage location is on a shared storage device attached to the target device. This solution is usually only valid for environments virtualizing the target device with a solution like Citrix XenServer. This storage is assigned to each virtual machine from a shared storage repository.
Benefits:
o Although target device shared storage is not as fast as RAM or target device local storage, it still provides fast response times. If the shared storage infrastructure is a SAN or NAS, the reads/writes will still perform adequately because the optimized shared storage infrastructure will help overcome the time added for traversing the network.
o Although the configuration of this solution requires the identification of the shared storage size, the costs associated with over-estimating are not nearly as detrimental as overestimating with RAM. Storage costs are significantly cheaper than RAM so a sizeable buffer over the space estimates is of little concern.
o Because the target device‟s storage is accessible from multiple virtual machines, virtual machine live migration, like XenMotion, is viable.
Concerns:
o This solution requires the setup and configuration of a shared storage solution. Although if XenServer is already being utilized, the same shared storage solution can be used for the write cache storage.
Provisioning Server – Local Storage
Definition: The fourth option for write cache storage location is on the Provisioning Server‟s local storage. This storage uses the physical disks installed within the Provisioning Server.
Benefits:
o This solution is extremely easy to setup and requires no additional resources or configuration within the environment.
Concerns:
o Requests to/from the write cache must cross the network and be serviced by the Provisioning Server streaming service. Because the write cache is across the network, servicing write cache requests will be slower than the previously mentioned options.
o The streaming service is responsible for sending the appropriate parts of the vDisk to all target devices. Having the write cache on the Provisioning Server will negatively impact the server‟s scalability because the streaming service must also service the write cache requests.
o Provisioning Server includes a high-availability option, but in order for this solution to function, all Provisioning Servers must have access to the vDisk and the target device‟s write cache. When the write cache is stored on one Provisioning Server‟s local storage, this makes it impossible for other Provisioning Servers to gain access, thus denying the ability to enable Provisioning Server high-availability.
o Although disk space is fairly inexpensive, chances are the Provisioning Server does not have an extensive supply of storage space. With each Provisioning Server supporting a few hundred target devices, it is quite possible the total write cache could exceed hundreds of gigabytes of storage space. This could result in exhausting all local storage on the Provisioning Server causing a server failure.
Provisioning Server – Shared Storage
21
Definition: The fifth option for write cache storage location is on the Provisioning Server‟s shared storage. This option utilizes a share storage solution that is connected to the Provisioning Server.
Benefits:
o The shared storage solution allows for Provisioning Server high-availability as each Provisioning Server can access the vDisks and the write cache.
o Size concerns are mitigated because shared storage devices typically contain significant amounts of storage and can be expanded easily.
Concerns:
o This is one of the slowest solutions because requests to/from the write cache must cross the network and be serviced by the Provisioning Server streaming service. The Provisioning Server must then forward the write cache requests onto the shared storage, thus resulting in two network hops for the write cache.
o Provisioning Server scalability is impacted as the streaming service is responsible for handling Provisioning Server write cache requests and forwarding them onto the shared storage. „ The solution requires the installation and configuration of a shared storage solution into the environment. If one is already present, then this concern is mitigated.
Recommendations:
Selecting the right place for the target device's write cache should be based on expectations.
Fast: To give users a local desktop feel, the virtual desktop should operate as efficiently as possible. This means the write cache should be fast.
Dynamic: Each user has different needs, which will greatly impact the size of the write cache between virtual desktops. The write cache solution must be able to function with a wide array of possibilities.
Available: Disruptions in the delivery of a virtual desktop will cause user frustration. Organizations will want to select a write cache option that does not impact high availability options that are designed to protect users from impending disruptions.
Based on the aforementioned criteria and the explanation of the different options for the write cache, virtual desktops delivered with Provisioning Server are best suited for Target Device - Shared Storage. The virtual desktops will be on a virtualization infrastructure, like XenServer. In order to provide XenMotion capabilities, defined storage must be shared storage.
Application Delivery Creating a XenDesktop environment must take into account how the applications are integrated into the user‟s environment. This not only requires an understanding of the business applications used by each user group but also the capabilities of each application and the interactions with other applications. The Application delivery section focuses on the following design areas:
Application Controller
Application Integration
Application Streaming Cache
Application Controller (Web Interface)
22
The Web Interface component of XenApp focuses specifically on the Web Interface site that will be used to deliver resources to the Citrix Receiver embedded within the virtual desktop. This site will be the only method users will have to get to their applications, whether they are hosted or streamed.
Recommendations
Authentication: To provide simplicity and speed, the Web Interface site used to deliver applications to the virtual desktop should be configured for Pass-Through authentication. Users will have already entered their credentials before getting into their virtual desktop. Those credentials were passed to the virtual desktop and will be passed again to the XenApp Web Interface site to automatically get the application list. Providing pass-through authentication reduces the number of times a user has to enter credentials, while still customizing the environment based on the user.
Encryption: The Web Interface site should be encrypted with an SSL certificate to protect the transfer of user credentials. The certificate can be from an enterprise certificate server to help save money, but the enterprise root certificate must be installed into the virtual desktop.
Application Integration
Separating the application-layer from the operating system-layer allows for a fewer numbers of unique desktops images, as most organizations will have one or two base operating system images. Applications will then be added on top of the operating system based on the current user's identity and rights. This design decision focuses on the ways applications can be integrated and thereby selecting the best approach based on the application in question.
Common Options:
Installed: Applications installed into the operating system are part of the base virtual disk image. Every user that uses this particular virtual desktop image will receive the application.
Streamed: Streamed applications are only available to users that have been granted rights. When the application is selected, the bits are sent across the network to the virtual desktop and executed within the isolation environment.
Hosted: Hosted applications are only available to users that have been granted rights to run the application. Users who do not have access will not see the respective application icon. Upon launching the application, all execution occurs on a remote XenApp server.
Recommendations:
The approach selected should be based on the type of application.
Base Applications:
o Description: Common applications all users require.
o Example: Microsoft Office (Word, Excel, PowerPoint, Outlook), Adobe Acrobat, Instant Messenger
Anomalous Applications:
o Description: Home-grown applications, potentially not following standard application development standards.
o Example:
Resource Intensive Applications:
o Description: Require heavy system resources to perform adequately
o Example: CAD/CAM, data processing
Technically Challenging Applications:
23
o Description: Large, complex applications with many move parts and dependencies.
o Example: Epic, Cerner, SAP
This is not a one-size-fits-all model. The following are general recommendations based on the application-type:
Base Applications: Stream
Anomalous Applications: Stream
Resource intensive Applications: Stream
Technically Challenging Applications: Host
Justification
Base Applications: By streaming base applications, these applications will be managed and stored in the same place as other streamed applications. When an update is required for these applications, it will follow the same update process. If the base applications are installed as part of the virtual desktop image, then application updates will require an update to the virtual desktop image.
Anomalous Applications: Many times, these types of applications are not written as terminal services aware applications, so hosting them on XenApp could prove challenging. Also, as only a few users typically use anomalous applications, having them installed as part of the base image would mean all users receive the application, not an optimal solution.
Resource Intensive Applications: These applications are oftentimes recommended to be streamed to the virtual desktop. If these applications are hosted on XenApp, a small number of users would consume the entire XenApp server. However, if the applications are delivered to the virtual desktop, then the XenServer hypervisor would only allow a user to consume their allocated resources, thus limiting the impact to other users.
Technically Challenging Applications: These applications typically have unique configuration and dependencies. Because XenApp is a more tightly-controlled environment than a virtual desktop, an organization will be better able to guarantee the application is setup properly and always functions in a XenApp delivery model.
Alternatives
Base Applications: Installing the base applications within the virtual desktop operating system image is an alternative to streaming. Also, because application streaming adds another layer to application delivery, utilization will be slightly elevated with the streaming process.
Anomalous Applications: Sometimes the home-grown applications are built in a certain way that results in a failure to stream. In these circumstances, the application should be delivered through the hosting model, if possible.
The following table provides a quick summary for the application integration design consideration.
Base Applications
Anomalous Applications
Resource Intensive Applications
Technically Challenging Applications
Description Common applications all users require
Home-grown applications
Unique with potentially limited terminal services support
Heavy system requirements
Large, complex applications with many moving parts and dependencies
Examples Microsoft Office (Word, Excel, PowerPoint, Outlook), Adobe Acrobat
CAD/CAM, data processing
Epic, Cerner, SAP
Primary Stream Stream Stream Host
24
Recommendation Managed same way as other streamed apps
Updates made using the application update process instead of desktop update process
Can use application profile for hosted applications, hosted desktops, streamed desktops and installed desktops.
Need granularity in determining who can use the application
Does not require the application to be terminal services aware
Allows hypervisor to limit amount of resources the application can consume
Provides granularity in determining who can use the application
XenApp creates a highly-controlled operating environment for the complexity of the applications
Provides the best scalability for application delivery
Secondary Recommendation
Install
Want lowest amount of overhead for most common applications
Host
Application might not stream correctly
Host
Potential that resources can be better constrained on a XenApp server.
Critical Notes:
None at this time.
Application Streaming Cache
One option for delivering an application to the virtual desktop is through the use of XenApp application streaming. Because the streamed application is not installed on the target device's vDisk, part of the application is sent to the target device over the network as needed. The files are stored within the application cache on the target device. Because the target device will most likely be delivered with Provisioning Server, the application cache will directly impact the Provisioning Server write cache. Each streamed application will incur numerous changes to the vDisk, which will be stored in the write cache. This brings about two potential concerns:
Network usage
Write cache size
This potential concern can be mitigated by pre-caching streamed applications into the vDisk. This option brings about its own concerns that must be assessed before the correct option is selected.
Common Options:
The first option is in the default configuration with no pre-caching. This type of architecture looks like the following:
25
Figure 1: No Pre-Caching
When a streamed application is launched on a virtual desktop, whose image is delivered from a standard image vDisk, the launch request will start to receive the application profile. Even though the entire application might be 500MB in size, only the portion needed to start the application is sent to the virtual desktop.
The first thing that happens is that a portion of the application is delivered over the network. This will delay the start time of the application until enough of the application stream is delivered.
As the application is streamed, the write cache will continue to grow because the stream contains new files and settings that cannot be stored in a standard image vDisk. The stream will first contain the .CAB files, which are compressed files from the application profile. This will increase the size of the write cache. Before the files can be used, they must be decompressed, which increases the write cache size even more.
As the user continues to access more functionality within the application, more files are delivered to the target device, continuously increasing the size of the write cache. By not having the streamed applications part of the vDisk image, updating an application profile does not mean that the vDisk image must also be updated. This helps keep the process simplified, especially as many organizations will have one group manage application profiles and another group manage the vDisk images.
To overcome some of these challenges, streamed applications can be Pre-Cached into the vDisk, as shown in the following figure:
Provisioned
XenApp Server
Write Cache
Swap &
Temp File
App CAB
files
Decompressed App
Streaming Cache
vDisk Storage
XenApp
Hosts
Provisioning
Server
Application Hub
26
Figure 2: Pre-Caching
During the vDisk build process, streamed applications are pre-cached within the vDisk image. Even though the streamed application is part of the vDisk, users must still launch the application through the Citrix Receiver, just like with streamed applications that are not pre-cached.
When a user tries to launch a streamed application from the Receiver, the Receiver will validate that the local streamed files are current and launch accordingly. There is no delay in application launch because the files are local and do not have to cross the network. Also, as changes are not occurring on the target device, the write cache size is kept to a minimum. When updates are made to the application profile, the application cache also requires updates to keep it in line with the central application profile. If the cache is out-of-date, the application launch process will update the application profile as needed.
The third option is Cache Redirection. The overall goal is to keep the maintenance of the environment simple while providing an optimized environment for the user so they experience a high-definition experience. If the virtual desktops are designed in such a way that they are allocated storage to hold the Provisioning Services write cache, the same defined storage can also contain the application streaming cache, as shown in the following figure:
This type of architecture provides the following benefits over the other to previously mentioned options:
Faster application launch after server reboots because the application cache persists
Easier application maintenance because the application cache is decoupled from the vDisk
Provisioned
XenApp Server
Write Cache
Swap &
Temp File
Decompressed App
Streaming Cache
vDisk Storage
XenApp
Hosts
Provisioning
Server
Application Hub
27
This solution does require additional storage allocation for each hosted virtual desktop.
Recommendations:
Performance is one of the biggest factors in user acceptance. If it takes a noticeable amount of time to launch applications every day, user acceptance for the environment will wane. Because of the performance aspect, Cache Redirection is the preferred method.
Alternatives:
If cache redirection is not an option, then pre-caching the applications into the vDisk is recommended. This recommendation does not mean that all applications should be pre-cached. The following should be taken into consideration:
Pre-Cache
Applications that are used everyday should be pre-cached because these are the applications users always access and startup delays will cause frustration. Also, because these applications are always used, there will be a constant hit on the network and write cache every day.
Applications that are highly-utilized and undergo semi-frequent small updates should be pre-cached. Just like before, because the application is used often, the performance benefits of pre-caching is of value to the user. However, just because the application undergoes updates does not necessarily mean that the application cache on vDisk must be updated. If the application update is minor (a hot fix that changes a few files), letting the application streaming process update the new files will not impact startup time. However, if the update is major, like a service pack for an application, then it would be advantageous to update the application cache on the vDisk.
Do Not Pre-Cache
Applications that undergo constant large updates should not be included in the pre-caching of the application profile. Due to the update frequency and the size of each update, the required updates to the cached application would negate any advantages incurred with pre-caching.
Applications whose usage is sporadic should not be included in the pre-caching. Requiring a user to wait a little longer for an application only used from time-to-time will not be as noticeable as everyday applications.
Desktop Delivery Delivering the operating system and integrating the applications into the base image creates an desktop that is functional for the user. Each user must be able to access the desktop without requiring numerous steps and processes to follow. The delivery of the desktop must be as simple as possible without adding risk to the environment. The key design areas for delivering the desktop to the user are:
Desktop Delivery Controller
Farm Design
Desktop Delivery Controller
A Desktop Delivery Controller (DDC) plays a very central role within a XenDesktop infrastructure. Its main task is to deliver and control access to virtual desktops, which includes User authentication, VM power management, ICA policy decisions and License enforcement. All these tasks are performed during user session initialization. Afterwards a DDC is performing "out of band" monitoring and maintenance tasks only, which allows a DDC to handle many thousand desktops at the same time.
Nevertheless it is highly recommended to implement DDCs in a fault tolerant manner of at least two DDCs per XenDesktop farm.
28
By default, in a XenDesktop farm the initial Desktop Delivery Controller (DDC) installed is the farm master with specific duties including
Data collector
Performing desktop resolution operations during desktop launches
Managing the hosting infrastructure.
This single server has the role of Data Collector and Controller. When there are multiple servers in a farm, it is often desirable to separate the functions of Controller and Data Collector by delegating these functions to different servers. These other duties can be better performed by other Desktop Delivery Controller servers in the farm, leaving the farm master machine to concentrate on its own role requirements.
To separate the roles, the actions to be taken fall into two parts:
Ensure that a particular machine is chosen to be the farm master
Ensure that unnecessary duties are not performed by that machine
The following diagram outlines the Desktop Delivery Controller architecture, its communication pattern and a Virtual Desktop Agent (VDA) outline.
Note: Further information about separating DDC roles can be found in the following KB article: CTX117477 - Separating the Roles of Farm Master and Controller in the XenDesktop Farm
Farm Design
One farm or multiple farms is a common design decision that impacts the capabilities of a XenDesktop environment from a user, administrative and infrastructure perspective. Although one farm creates a single administrative environment, multiple farms simplify cross-site design concerns. For example, a multi-data center environment might look like the following:
29
With four different data center locations, one of the initial questions is whether to create a single XenDesktop farm that spans all four sites or to create a single farm for each site. Both solutions work, but each comes with their own benefits and concerns as described in the following table.
Single Farm Multiple Farms
Benefits Single Administrative Presence: A single farm solution allows XenDesktop administrators to manage and maintain the XenDesktop farm from a centralized console.
Single Access Point: With a single URL, users connect to the XenDesktop farm and are presented with a list of available resources. No additional hardware/software is required in order to provide a single access point for the users.
Local Data: A user, regardless of their location, always connects to their most preferred data center, which also includes their data. This allows the user to experience fast application response time as the hosted desktop to data communication is on a high-speed LAN.
Single Access Point: Even though the XenDesktop environment is broken down into multiple farms, resources from all farms can be consolidated and displayed to the user through a single interface. This requires Web Interface configurations to include XML brokers from every farm.
Concerns Intra-farm Communication: Desktop Controller communication must be able to cross WAN links to keep the farm in sync. Also, the master controller must be able to communicate with XenServer resource pools in each location. Delays in communication can impact the accuracy in virtual desktop status changes.
User‟s Home: With a single XenDesktop farm, there is a potential for users to connect to a hosted desktop in a different location. Although ICA is optimized for the WAN links, the backend data is not. This might result in application performance degradation a data is copied from a remote site to the hosted desktop. This can be mitigated by creating different desktop groups for users based on their preferred location, but does add complexity to the farm.
Administration: A single farm configuration allows the entire environment to be managed from one location. Multiple farms require changes to be made multiple times, one per farm. Although this tends to cause concern, with proper change control processes, this risk is easily mitigated.
Whichever option is selected, the critical aspect is guaranteeing the user‟s personalization settings are local to the hosted desktop. The delivery protocol (ICA) is able to overcome many of the latency/bandwidth limitations of the WAN link, but it‟s the application communication with the data that will disrupt the user‟s acceptance of the solution.
30
Access Design With the delivery system in place, users must have a way to easily access the environment from internal and external locations. Also, regardless of the user requirements, each one should follow the same process and be presented with the appropriate applications based on their current situation. The Access Design section focuses on
Resource Delivery
Internal Site Access
Resource Delivery
Web Interface is the access point for users to gain access to their desktops or applications. From one web page, users can see links for applications, desktops or both. Users will navigate to Web Interface to launch a virtual desktop or an application. If the user launches a desktop, the Citrix Receiver, installed within the virtual desktop, will automatically connect to the XenApp Services site to pull the same set of applications for use within the virtual desktop. However, will having both applications and desktops within the same console cause issues for users and the environment?
Common Options:
There are essentially two options, but there are a few considerations to take into account before making a decision.
Single Site: The single site option is to use a single Web Interface site for both applications and desktops. This solution provides a completely integrated solution that allows the users to decide if they want a full-blown desktop or just need an application. However, this single site solution might pose confusing if a user selects another virtual desktop and from within their virtual desktop session.
Multiple Sites: The multiple site option uses two different Web Interface sites: one site for desktops and the other site for applications. Users would connect to the desktop site and be presented with their virtual desktop. Upon connection to their virtual desktop, the Citrix Receiver will automatically receive the available applications from the Web Interface site for applications.
Recommendations:
The recommendation is based solely on the customer's requirements as both options are valid, but in many situations, a multiple site design will be implemented like the following:
Site 1: The first site will include both applications and desktops. This solution gives the users
o Flexibility: Users can choose if they need a virtual desktop or just an application. This empowers the users to create the environment most optimal for their current work scenario.
o Simplicity: With a single site for desktops and applications, every user, regardless if they have access to a virtual desktop or not, will use the same URL. If the site only delivered applications or desktops, then different sets of users would be required to remember different addresses, which will add to confusion.
Site 2: The second site will only include applications. This site will be used by the Citrix Receiver installed within the virtual desktop to automatically enumerate applications on behalf of the user. The second site will help reduce confusion for virtual desktop users because the second site only contains applications. There is no risk of a user starting a virtual desktop from within a virtual desktop.
Critical Notes:
31
If a single site design is used, there is a potential issue if workspace control is also enabled. Workspace control will move a user's session to the current target device simply by logging into Web Interface. When a user launches a virtual desktop, the Citrix Receiver will automatically start and authenticate to Web Interface. The Receiver will kick off a workspace control trigger that will move the user's connection to the virtual desktop from their target device to the new target device, which is the virtual desktop. In essence, the user's connection to the virtual desktop will be broken. This potential issue can be overcome by using a multiple site design.
Internal Site Access
Simplifying the access to the virtual desktop infrastructure is critical in order for users to easily and quickly access their resources. Also, a single URL within a site creates a single entity within the site that is shared between all users. Training and troubleshooting is simplified as there is only one location. However, if a user travels to a different location, that one URL should still give them access to the appropriate resources.
Regardless of a single or multiple-farm design, each location typically has its own set of Web Interface servers containing resources from one or all XenDesktop farms. A user can connect to any Web Interface site and still receive a hosted desktop. However, simply directing users to a Web Interface address could result in users going to a failed server, crossing latent WAN links to get to a server, or remember multiple addresses and being trained on selecting the best option.
In order to provide the user with a single URL for any site, the use of a load balancing solution, like Citrix NetScaler, should be used, as shown in the following figure.
In this example, users utilize a single fully qualified domain name that is preconfigured within the Citrix Receiver.
This request goes to one of the corporate DNS servers.
32
The DNS server sends the request to one of the defined NetScaler pairs located in each data center. The NetScaler acts as an authoritative DNS server for the specified FQDN. A high-availability pair of NetScaler devices is used because DNS round robin is unaware if a NetScaler at the site is offline.
Each NetScaler communicates with the NetScaler at the remote data centers to determine the fastest responding location with an available Web Interface server. If one site responds first, but does not have any online Web Interface servers, the second fastest site is used.
The NetScaler at the fastest responding site responds to the user‟s FQDN request with the physical address of an available Web Interface server.
From there, the user receives the list of resources and launches as appropriate.
Critical Notes:
Load balancing can be done with DNS round robin, although this solution does not validate the Web Interface is functioning before directing the user to the server. NetScaler, when properly configured with Web Interface monitors, only sends users to servers with properly functioning resources.
33
Part IV
Personalization
34
Overview Personalization of the user‟s virtual desktop environment is paramount to achieving success and acceptance from the user community. Personalization is more than simply the user‟s profile; it also includes the virtual desktop design, policies and profiles as well as a host of other items.
Virtualization Infrastructure The virtualization layer of XenDesktop is a crucial component to the overall architecture. This layer allows the environment to scale without requiring a 1:1 relationship between component and physical server. By properly designing the XenDesktop environment, one can not only better utilize the hardware but also improve availability and simplify management. This section focuses on
Virtualized Components
Resource Pools
Desktop Design Designing the virtual desktop requires an understanding of the current user environment against the expectations of future growth. This understanding allows the desktop resources and images to be defined and implemented appropriately. Without it, users will be left with an underperforming system that does not include everything they need in order to be productive. Designing the virtual desktop focuses on the following items:
Virtual Machine Specifications
Desktop Images
Virtual Machine Specifications
Determining the specifications for each group of hosted desktop requires a proper balance between performance and allocation. User groups only need certain amounts of resources in order to be productive. Providing too many resources results in underutilize hardware while allocating too few results in underperforming systems. For each unique user group, it is advisable to determine the following
Desktop Count: Identify the number of hosted desktops a particular user group requires.
Memory Allocation: Identify the amount of RAM allocated for the particular hosted desktop. Over-subscribing, not currently available in XenServer, is risky as a spike in user activity could impact user performance.
Processor Allocation: Identify the number of virtual CPUs allocated for a particular host. In almost all circumstances, a single virtual CPU per hosted desktop is enough processing power because the performance of a server CPU is much greater than a physical desktop‟s CPU.
An example of this information is as follows:
User Group Desktop Type
Population Operating System
Memory Processor
Marketing Hosted 50 XP 1 GB RAM 1 vCPU
Marketing Streamed 25 XP NA NA
Engineering Hosted 125 Vista 2 GB RAM 1 vCPU
Engineering Streamed 200 Vista NA NA
Desktop Images
35
One of the goals in defining a desktop image is to include only what the user and business requires and nothing more. Each component added onto a desktop creates a software bloat effect that reducing the efficiency of the desktop. As a general guideline, the following should be included in all desktop images. This list provides the most common components and add-ons required by most users.
Hosted Streamed
Disk Configuration
Size 20 GB 20 GB
Operating System
Windows Vista or Windows XP √ √
Latest Service Packs and Hotfixes √ √
XenDesktop Delivery
Citrix Virtual Desktop Agent √ TBD
Citrix Provisioning Services Target Device Client √ √
Citrix App Plug-in for Online Apps √ √
Citrix App Plug-in for Offline Apps √ √
Citrix Tools for Virtual Machines √ NA
Citrix User Profile Manager (disabled in GPO) √ √
Foundational Applications
Adobe Shockwave Player 11 √ √
Adobe Flash Player ActiveX 9 √ √
Antivirus Software √ √
Microsoft Silverlight 2 √ √
Applications
To Be Determined Core applications that are not streamed should be installed in the base image
If the base image is streamed to a physical workstation, the Tools for Virtual Machines is not required. The tools are enhanced XenServer drivers, which are not used when the desktop image is streamed to a physical workstation.
In most situations, local physical desktops receive the streamed image, but are accessed locally – by someone sitting in front of the workstation. This type of scenario does not require the Virtual Desktop Agent. If, however, the physical desktop will be accessed by remote users, the agent is still required so the XenDesktop controller can broker connections to the physical device. This is a scenario that should happen infrequently.
Profiles Design Profiles are a critical area of XenDesktop deployments and the most important part of personalization. A profile is a collection of personal data associated to a specific user. A profile therefore refers to the explicit digital representation of a person's identity.
At the heart of a profile is a file called "NTUSER.DAT". This file contains the majority of users personalized settings and gets mounted as the HKCU branch of the registry hive. There are several different types of profile options, including local, roaming, mandatory and various combinations (hybrid, flex, managed, etc.). These options will be briefly explored in this section and best practices will be presented for XenDesktop deployments.
Common Options:
In a typical XenDesktop deployment where specific desktops (VMs) are assigned to specific users, local profiles are often used for simplicity. However, local profiles have several well known drawbacks and disadvantages, so most organizations opt for a roaming or mandatory profile solution. It should also be noted that most organizations do not assign desktops to users - most XenDesktop implementations leverage pooled desktops.
36
In a typical XenDesktop deployment where desktops are pooled and dynamically assigned to users, roaming profiles are most commonly used. Some organizations first try mandatory profiles, but usually end up going with roaming profiles or a third party solution because roaming profiles allow for better personalization than mandatory profiles.
Recommendations:
For simple environments requiring personalization, Citrix recommends implementing roaming profiles with folder redirection. At a minimum, Citrix typically recommends redirecting My Documents, Application Data and Desktop. All shell folders that contain large amounts of data should be redirected as this will reduce logon times for the user as the large shell folders do not require network traversal. Organizations should also exercise caution to not redirect shell folders that are frequently accessed by applications (since the redirected folders typically reside on a network share and this could introduce a performance lag).
Profiles and redirected folders should be stored in a centralized network location that is logically near the virtual desktop storage. In most cases, Citrix recommends leveraging shared storage such as a SAN or NAS for this purpose.
In demanding or complex environments, Citrix recommends a more robust profile management solution such as Citrix Profile management (Pm). A complex environment may include multiple products, such as XenDesktop and XenApp, or a large number of users. These types of environments are best suited for a third party solution such as Pm due to the complexities associated with managing multiple profiles, last writer win conflicts, etc. Customers leveraging Application Streaming in conjunction with XenDesktop may also wish to leverage Pm as opposed to a typical roaming profile solution with folder redirection.
As a Microsoft best practice, profiles should be implemented as part of a Group Policy Object to ease management and allow for greater scalability. If Active Directory Group Policy cannot be used, then Citrix recommends an automated script to assign the profile path to each user (under the user's account properties).
Citrix also recommends leveraging Group Policy Preferences (GPPs) whenever possible. GPPs can eliminate many items that were classically found in logon scripts, such as drive and printer mappings. GPPs, in conjunction with a well designed profile solution with folder redirection, typically provide the fastest logon times and most consistent end-user experience.
Justification
Roaming profiles allow users to make changes to their desktops, applications, etc. and save those changes, which is a critical part of personalization. This allows a user to log off at the end of the day and log back in the next day (to a new, dynamically assigned VM) and still retain their personalization settings.
Folder redirection reduces profile bloat, optimizes logon times and reduces profile corruption issues that are typically associated with roaming profiles. This is a Microsoft and Citrix best practice for both XenDesktop and XenApp deployments.
Profile management solutions, such as Citrix Profile management, eliminate last writer win (LWW) scenarios and allow for easier administration across different platforms. Most enterprise environments with complex environments leverage a profile management solution.
Alternatives
In addition to Pm, other third party profile solutions have been tested and implemented successfully with XenDesktop. These include triCerat, AppSense and RTO.
Policy Design After profiles, policies are one of the most important areas of personalization. This section explores both Citrix policies and Microsoft Group Policy. It is important to note that Citrix policies are still available in XenDesktop via the XenApp Advanced Configuration tool (Java-based "CMC"). A stripped down
37
version of this management utility is available with XenDesktop and "Policies" will be one of the few nodes available.
Most commonly, administrators use a Microsoft Group Policy Object (GPO) or a series of GPOs to not only personalize a user's desktop, but also to lock down the delivered desktop. Administrators typically place all desktops/VMs in a separate OU within Active Directory for easier management. GPOs are then applied to the OU containing the virtualized desktops. This configuration aligns with best practices. What most administrators forget in XenDesktop deployments are Citrix policies.
Both Citrix policies and Microsoft GPOs are recommended in order to lock down, optimize and most importantly, personalize a virtualized desktop delivered via XenDesktop. Similar to XenApp, a "baseline" XenDesktop policy should be applied to all users or desktops. This policy typically contains standard printing configurations, optimizations to improve end-user experience, etc. This is also where unused virtual channels such as COM port mapping should be disabled.
After applying the baseline policy to all users, other Citrix policies can be created and applied to specific users or groups as required. It is recommended to prioritize these special policies "above" the baseline policy (priority should be higher than the baseline policy). This ensures that proper policy processing occurs.
As mentioned previously, Microsoft GPOs are also recommended to personalize the user's desktop where Citrix policies fall short. Items such as start menu configuration and folder views should be configured using GPOs to provide a friendly end-user experience.
38
Part V Implementation & Support
39
Maintenance Antivirus
If the hosted and streamed desktops originate from a Provisioning services vDisk image running in standard mode, changes made to the desktop are not stored. After a short amount of time, the virus definitions in the vDisk are old and outdated, which can potentially put the environment at risk for a virus attack. By configuring the antivirus software within the vdisk to update definitions upon boot will ensure the desktop uses the most recent definitions and is only out of date for a few minutes. These few minutes happen before any user logs into the virtual desktop.
Over time, the number and size of the antivirus definition will continue to grow. As part of the maintenance of the XenDesktop environment, the vDisk image should also be updated to include the latest antivirus definition. When the vDisk is updated in private image mode, the antivirus update will occur automatically during startup. Then when the vDisk is placed back into standard image mode, the vDisk contains the latest virus definitions.
40
Revision History Revision Change Description Updated By Date
0.1 Initial document created Daniel Feller – Sr. Architect Thomas Berger – Principal Consultant
March 23, 2009
1.1 Added additional sections focused on user community, access scenarios, virtualization infrastructure, Provisioning services and XenDesktop delivery
Daniel Feller – Lead Architect Thomas Berger – Principal Consultant Nick Rintalan – Architect Elisabeth Teixeira – Principal Product Specialist Tarkan Koçoğlu – Sr. Architect Scott Campbell – Principal Consultant
June 30, 2009
41
Citrix Worldwide Worldwide headquarters
Citrix Systems, Inc.
851 West Cypress Creek Road
Fort Lauderdale, FL 33309
USA
T +1 800 393 1888
T +1 954 267 3000
Regional headquarters
Americas
Citrix Silicon Valley
4988 Great America Parkway
Santa Clara, CA 95054
USA
T +1 408 790 8000
Europe
Citrix Systems International GmbH
Rheinweg 9
8200 Schaffhausen
Switzerland
T +41 52 635 7700
Asia Pacific
Citrix Systems Hong Kong Ltd.
Suite 3201, 32nd Floor
One International Finance Centre
1 Harbour View Street
Central Hong Kong
T +852 2100 5000
Citrix Online division
6500 Hollister Avenue
Goleta, CA 93117
USA
T +1 805 690 6400 www.citrix.com
About Citrix
Citrix Systems, Inc. (Nasdaq:CTXS) is the global leader and the most trusted name in application delivery
infrastructure. More than 215,000 organizations worldwide rely on Citrix to deliver any application to users anywhere
with the best performance, highest security and lowest cost. Citrix customers include 100% of the Fortune 100
companies and 99% of the Fortune Global 500, as well as hundreds of thousands of small businesses and
prosumers. Citrix has approximately 8,000 channel and alliance partners in more than 100 countries. Annual
revenue in 2008 was 1.6 billion.
©2009 Citrix Systems, Inc. All rights reserved. Citrix®, Citrix XenApp™, Citrix XenServer™ 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. Microsoft® and Windows®
are registered trademarks of Microsoft Corporation in the United States and/or other countries. UNIX® is a registered trademark of The Open Group
in the United States and other countries. All other trademarks and registered trademarks are property of their respective owners.
PDF-code Date
