Citrix XenDesktop Modular Reference Architecture Version 2.0. Prepared by: Worldwide Consulting Solutions

Transcription

1 Citrix XenDesktop Modular Reference Architecture Version 2.0 Prepared by: Worldwide Consulting Solutions

2 TABLE OF CONTENTS Overview... 2 Conceptual Architecture... 3 Design Planning... 9 Design Examples Summary Revision History Acknowledgements... 24

3 Overview Organizations are looking at desktop virtualization technologies as a method to enable device independence and flexible workstyles, and to improve manageability of the desktop environment. XenDesktop, with its FlexCast models, offers IT opportunities to deliver desktop virtualization to a wide range of users by delivering every type of virtual desktop; hosted or local, physical or virtual, shared or dedicated, tailored to meet the specific needs of the individual end user groups. As organizations scale XenDesktop it is important to consider how to best create large configurations while minimizing risk. While a single XenDesktop site can scale to large numbers of virtual desktops, creating very large single sites can involve risk as the loss of site components have the potential to impact a significant number of users. As such, it is important to consider a design that is modular in nature and allows an environment to be built in self-contained pods that can be easily replicated. This allows organizations to build an environment which scales to large numbers of users, while providing availability should a failure impact a single site structure. This whitepaper focuses on developing a modular architecture to deliver hosted virtual desktops, with considerations for an environment that can scale to tens of thousands of users. The architecture provides details for delivering Hosted VDI and Hosted Shared virtual desktops. Hosted Desktop Blades are discussed, but not covered in detail. To help architects design a XenDesktop solution based on real-world projects, organizations can refer to the Citrix Project Accelerator for step-by-step assessment, design and deployment guidance, and the Citrix Virtual Desktop Handbook for details and best practices for assessment through deployment and operations. Page 2

4 Conceptual Architecture Trying to design a completely integrated solution for large numbers of users can be challenging as there are many variables which must be taken into account. Designing a solution in a modular fashion allows it to be broken down into distinct modules; smaller portions such as layers and pods that can be designed and linked together to create the end-state solution. The modular architecture focuses on the five layer approach to insure that all key design decisions are considered. Architects should be sure to address the following layers in their design decisions: Figure 1: Five Layer Model 1. User Layer: The user layer covers the recommended end-points and the required user functionality. 2. Access Layer: This layer addresses how the user will connect to their desktop hosted in the desktop layer. Decisions for local vs. remote access, firewalls and SSL-VPN communications are addressed here. 3. Desktop Layer: The desktop layer contains the user s virtual desktop and is subdivided into three components; image, applications, and personalization. Decisions related to FlexCast model, application requirements, policy, and profile design are addressed in this layer. 4. Control Layer: Within the control layer decisions surrounding the management and maintenance of the overall solution are addressed. The control layer is comprised of access controllers, desktop controllers and infrastructure controllers. Access controllers support the access layer, desktop controllers support the desktop layer, and infrastructure controllers provide the underlying support for each component within the architecture. 5. Hardware Layer: The hardware layer contains the physical devices required to support the entire solution, and includes servers, processors, memory and storage devices. Servers are grouped according to overall function at the Desktop and Control layers. For example hypervisor servers are dedicated to support hosted shared desktop and application delivery through XenApp, or VDI delivery through XenDesktop. An additional group of servers will support the control infrastructure as defined in the control layer. Page 3

5 While the physical representation of the servers exists solely in the hardware layer, the logical representation of the components and their functions spread across the access, desktop and control layers. The modular reference architecture focuses on the logical representation; looking at components within the access, desktop and control layer, but ultimately all of the sizing and scaling is based on the hardware components selected and their base within the hardware layer. As this architecture focuses on the datacenter components, the user layer is not considered here. The following diagram represents the logical representation of components within the solution. Figure 2: Modular Reference Architecture Page 4

6 Access Layer Figure 3: Access Layer The access layer consists of servers and appliances responsible for providing connectivity to the XenDesktop environment through both web based methods and Citrix Receiver. The access layer controls connectivity across multiple pods within the desktop delivery layer and generally only one pool of servers is required to fulfill this role in a datacenter. The access layer consists of the following components StoreFront: Storefront is the successor to Web Interface, and authenticates users to XenDesktop sites, XenApp farms, and SaaS applications (via AppController). It enumerates and aggregates available desktops and applications into stores which users access through Citrix Receiver or Receiver for Web sites. Web Interface: Web Interface provides initial user access into the XenDesktop infrastructure by accepting user credentials and passing them to the appropriate XenDesktop or XenApp controller for authentication and enumeration. For remote users, authentication takes place on the NetScaler/Access Gateway and credentials are passed to the Web Interface and controller infrastructure. Once the controller acknowledges authentication, Web Interface presents the user with the available resources. When the virtual desktop is selected by the user, the XenDesktop Controllers in the XenDesktop site manage session initiation. NetScaler: Citrix NetScaler provides dual functionality in the XenDesktop modular architecture. It provides front-end secure remote access to the environment through integrated Access Gateway functionality, and enhances high availability to XenDesktop by load balancing the StoreFront service, Web Interface, XenApp Controller and XenDesktop Controller components. Load balancing is achieved using intelligent monitors which query the Web Interface, XML, and XenDesktop Controller infrastructure to ensure that the services are up and running correctly. For high availability, NetScaler devices are configured in an activepassive pair to ensure that service is available should one device go down. Page 5

7 Desktop Layer Figure 4: Desktop Layer The desktop layer contains the hardware level components that provide the base infrastructure to deliver Hosted VDI, Hosted Shared and Hosted Desktop Blade desktops delivered from the datacenter. The desktop layer consists of a number of hypervisor pools or blade PCs to deliver service to the end users. A given XenDesktop implementation can include multiple desktop pods containing pools of servers to deliver virtual desktops, aligned with Citrix FlexCast models for virtual desktop delivery. Hosted VDI Pool: Hypervisor pools provide the structure to run virtual desktops when delivering a Hosted VDI model. For the purposes of this document, XenServer hosts are considered, although using VMware vsphere or Microsoft Hyper-V host pools are also supported. The hypervisor hosts are defined in XenServer pools to provide management and high availability. Hosts within the pool share common storage and networking components so that virtual machines can be started on any host within the pool where sufficient resources exist. Hosted Shared Pool: Pooled hypervisors hosting XenApp servers to provide Hosted Shared Desktops. Hosted shared desktops provide a locked-down standardized environment with a core set of applications. While it is possible to configure a XenApp farm to deliver both applications and Hosted Shared Desktops, this reference architecture limits the pool configuration to delivering Hosted Shared Desktops to simplify the environment. Additional XenApp configurations can be created to deliver applications as required. Hosted Desktop Blade: A hosted blade pool consists of a number of physical blade PCs within an enclosure. These blades are provisioned to end-users in a one-to-one configuration. The number of blades in a single enclosure is dictated by the specifications of the hardware manufacturer (as an example, some current blade systems support blades per enclosure). Specifications of the blade PCs can be matched to the end-users performance requirements. Page 6

8 Control Layer The control layer contains the XenDesktop components that are required to control the delivery of virtual desktops to end-users. Some of the XenDesktop components in the control layer are replicated per-desktop pod while some serve the entire configuration. The components in the control layer are detailed below. Per-Desktop Pod Figure 5: Control Layer Per-Desktop Pod XenDesktop Controller: The XenDesktop Controller provides the control structure to manage virtual desktops delivered through the Hosted VDI model. The controllers authenticate users, enumerate resources, and direct user launch request to the appropriate virtual desktop. The controllers manage and maintain the state of the XenDesktop site to help control desktop startups, shutdowns and Virtual Desktop Agent registrations. The controllers constantly query and update the SQL database with site status, allowing controllers to go offline without impacting user activities. Redundant XenDesktop Controllers are configured and load balanced to ensure availability of the site should a single controller fail. XenApp Data Collector/XML Server: The XenApp Controller infrastructure provides the link between the Web Interface and the XenApp pool providing Hosted Shared desktops. Within a XenApp environment, there are two controller functions; Zone Data Collector and XML Broker. Zone Data Collectors host an in-memory database that maintains dynamic information about the servers in a zone (e.g. server load, session status, and published applications). XML Brokers authenticate users, enumerate resources, and direct user launch request to the appropriate XenApp application server. XenApp controllers are regular XenApp servers that have been installed with Controller Mode enabled and do not host any user applications. Zone Data Collectors are designated Most Preferred and Preferred zone election preference for primary and backup data collectors respectively. Dedicated XML Brokers are assigned a default election preference. Redundant XenApp controllers are configured and load balanced to ensure availability of the site should a single controller fail. Provisioning Server: The Provisioning Server is responsible for streaming the operating system to the virtual desktops in the infrastructure, and optionally streaming the server image to XenApp servers. Citrix Provisioning Services allows a single vdisk to be used to deliver a consistent virtual desktop across the environment, and to simplify image management and maintenance. The provisioning servers must be configured for high availability by configuring properties on the servers, and by having multiple servers sharing read/write access to a CIFS file share where the vdisks reside, or replicating the vdisk store between servers. This structure will provide load balancing operations across the provisioning servers by distributing I/O requests from target devices across all servers, and allowing target devices to automatically fail over to another server should connectivity to the original be lost due to server failure. Page 7

9 Across The Configuration Figure 6: Cross Configuration Control Layer SQL Server: The SQL database provides the foundation for the virtual desktop solution, storing all configurations, desktop and current utilization information. The server is critical to the continuous functioning of XenDesktop, XenApp and Provisioning Services configurations. The SQL server instance should be highly available to ensure continuous operation. Citrix recommends the configuration of database mirroring in a synchronous mirroring with witness configuration to ensure the database is protected and failover is automatic. Desktop Director: Desktop Director is a management tool that provides an overview of XenDesktop and XenApp sessions. It provides a dashboard that summarizes real-time machine issues, usage metrics, HDX information, and host and controller health information. Information is displayed based on the aggregation from multiple sources including XenDesktop and XenApp controllers, Citrix profile management, Windows Management Information (WMI) and Active Directory and allows administrators to manage from a centralized tool. While a single Desktop Director server can manage the environment it is recommended that redundant Desktop Director servers be configured and load balanced to ensure the management console is always available. Citrix License Servers: The licensing server provides Citrix licensing for all components within the XenDesktop architecture, with the exception of the NetScaler components in the Access pool, as they are manually configured with license files. Citrix licensing has a 30 day grace period during which the XenDesktop components will function normally should the license server become unavailable. Because of this grace period, a single license server as a virtual machine or virtual appliance which is configured for VM-level HA can be implemented. A failed license server can easily be rebuilt and restored from backup without impacting operations of the XenDesktop infrastructure. Note: On XenApp servers the information required to provide the 30 day license grace period is stored locally on every server. In Provisioning Services based infrastructures, the relevant information is updated on every XenApp server during runtime, but reset back to the state stored within the vdisk upon reboot. In case the vdisk has not been in maintenance within the last 30 days, the license server fails and the XenApp servers are rebooted, no new user sessions can be established. Therefore, the MPS-WSXICA_MPS- WSXICA.ini is redirected to a file share, as described within Citrix Knowledgebase Article CTX Microsoft Windows Active Directory, DHCP, and DNS: Provides the base infrastructure required to access virtual desktops. Page 8

10 Design Planning The modular reference architecture is built on a virtualize everything approach, with all servers and services within the architecture configured on virtual servers. The architecture is constructed based on a number of desktop pods which are functional XenDesktop sites and are sized based on scalability considerations and risk. As the size of an individual desktop site becomes very large, the risk of a failure impacting a significant portion of the user population increases. Thus the modular concept allows organizations to build smaller site configurations which are combined together through the access and control layers to produce an environment that can serve the needs of both large and small numbers of users while allowing for resiliency and availability should a single site structure fail. The first step in determining the overall configuration of the modular reference architecture is to determine the number of users and the user requirements based on desktop load. Once the user load is determined, the number of modules can be enumerated based on risk, and the individual modules can be broken down by individual server and pool scalability. Each of the three layers in the modular reference architecture is considered separately. Note: The scalability numbers presented in this whitepaper are estimates based on Citrix testing and field experience and provided as initial estimation guidance. Architects should validate design estimates with thorough scalability testing prior to production through load simulation and/or user monitoring. Determine Desktop Layer Requirements Estimating Single Server Scalability Single server scalability refers to the number of users that can be loaded onto a single virtual server and is the basis for determining the scalability of a hypervisor resource pool and the overall scalability of a single pod. Single server scalability needs to be considered for Hosted VDI and Hosted Shared models. Hosted Blade scalability is 1:1. Hosted VDI Scalability For Hosted VDI, single server scalability is based on CPU and memory load. The majority of XenDesktop deployments use a CPU overcommit ratio of between 4:1 and 8:1. However, some high-performance virtual desktops may require multiple physical CPUs per virtual desktop. The following table outlines the initial virtual machine recommendations for virtual desktops, based on a 2.7 GHz Intel Westmere processor architecture. Note that there is not a linear progression from dual to quad socket systems. Testing shows a 15% drop in user density per core when considering a Quad socket processor configuration.

11 Personal vdisk (PVD) technology allows users to perform advanced customizations while still providing administrators with the benefits of central image management. Virtual Desktops with PVD have a performance overhead of approximately 14% per core to account for the additional CPU utilization of the filter drivers responsible for redirecting requests to the Personal vdisk. User Category Operating System vcpu RAM Users per Core Dual Socket Light Windows XP MB Windows 7 with PVD Windows Normal Windows XP GB 11 9 Windows 7 with PVD GB 8 6 Windows GB 10 8 Heavy Windows XP 1 2 GB 8 7 Windows 7 with PVD 2 4 GB 4 3 Windows GB 5 4 Table 1: Hosted VDI Scalability Users per Core Quad Socket When determining the user density on a single server, calculate the maximum user density for CPU and memory and use the lower value. The formulae for maximum users are as follows: ( ) ( ) ( ) Note: Each hypervisor requires CPU and RAM to function properly. On average, the hypervisor will need 2-5 GB of RAM. For XenServer, the maximum RAM configuration for Hypervisor Overhead is 2.94 GB. For calculation, this is rounded to 3 GB. For information on configuring Dom0 memory in XenServer, refer to Citrix Knowledgebase Article CTX As the size of the physical server increases, so too does the overhead. It is also advisable to reserve 1 CPU core for hypervisor processing, which helps mitigate the risk of over-allocating CPUs. For example, if a normal Windows 7 without PVD user is considered, each user will need 2 vcpu, 2GB of RAM and the a system will support up to 10 users per core. Assuming a 2x8 core CPU with 128GB of RAM, a single server would scale as follows: CPU Cores: 16, Users/Core: 10 ( ) ( ) Available Memory: 128GB, RAM/User: 2GB ( ) ( )

12 Single server scalability is determined by the lower of the two values, netting a rounded scalability of approximately 60 users per hypervisor server for this example. Note that here the bottleneck is memory. Adding more RAM to the hypervisor server would allow more users to be hosted. Increasing memory to 256GB would allow 126 users per hypervisor server, and would be a better balance of CPU and memory. Hosted Shared Scalability For hosted shared desktops, multiple users are simultaneously hosted on a XenApp server. As with the Hosted VDI model, the number of users that can be hosted on a single server depends upon user load and CPU and memory. As XenApp 6.5 is 64-bit only, it is assumed that the processor subsystem is the primary bottleneck. If 32-bit operating systems are used, it is more likely that memory will be the primary bottleneck. CPU overcommit is not recommended for XenApp servers. The following table provides some general guidance on how to estimate user density based on the number of physical cores available. The move from dual to quad sockets is not linear and this has been accounted for by a 15% drop in user density: Number of Sockets Users per Physical Core Light Normal Heavy Dual Quad Table 2: Hosted Shared Users per Core The following assumptions were made during the creation of these estimates: XenApp vcpu: The optimal number of vcpus assigned to each virtual XenApp server will vary according to the characteristics of the users and applications supported. However, optimal density is typically obtained when 4 vcpus are assigned to each virtual XenApp server. Processor: The speed and architecture of the processors has a direct impact on the number of users that can be supported per processor. The estimates provided are based on an Intel Westmere processor with a speed of 2.7 GHz. Workloads: Light, normal and heavy workloads are not mixed within a single virtual XenApp server or physical virtualization hosts. Hypervisor Overhead: The overhead from supporting the hypervisor has been accounted for by reducing the estimated number of users per core rather than specifically reserving virtual CPUs. XenApp Optimization: The recommended XenApp optimization recommendations have been applied. For more information, please refer to the Citrix Knowledgebase Article CTX XenApp 6.x Optimization Guide.

13 The host density estimates in the following table were obtained by multiplying the number of physical cores available by the estimated user density per core values. Sockets Cores Total Physical Cores VM Count User Density per Host Light Normal Heavy Table 3: Hosted Shared Scalability As a general rule, RAM requirements should be calculated by multiplying the number of light users by 341MB, medium users by 512MB and heavy users by 1024MB. Therefore, each virtual machine hosted on a dual socket host should typically be assigned 12GB of RAM and each virtual machine hosted on a quad socket host should be assigned 10GB of RAM. Important: Although these estimates provide a good starting point it is still important that scalability testing be performed to account for areas of variance, including processor speed, processor architecture, application set, usage patterns and number of idle users. For the hosted shared desktop servers, given a VM to CPU core ratio of 1:1, we would use the following formula to determine how many XenApp virtual servers, and thus users, we can host on a single hypervisor server. ( ) Following the previous example and using a 2x8 Core hypervisor host with 128 GB RAM and a Normal user load, an example single server would scale as follows: ( ) Estimating Resource Pool Scalability Pooled hypervisor hosts provide the hypervisor structure to run Windows XP/Windows 7 virtual desktops and XenApp servers when delivering Hosted VDI and Hosted Shared FlexCast models respectively. When creating a resource pool structure for a virtual desktop solution, Citrix recommends the following resource pool sizes: FlexCast Model Streamed VDI Up to 12 Dedicated/Pooled VDI Up to 8 Hosted Shared Up to 16 XenServer Resource Pool Table 4: Resource Pool Scalability

14 Estimating the number of resource pools and desktop pods required The final step in building out the desktop layer is to determine the number of resource pools required. For a given number of users, the decision on the number of pods deployed is made based on risk and contingency. As the size of the XenDesktop configuration grows, increasing the number of virtual desktops by scaling a single pod to larger sizes can create increased risk. While there is redundancy built into the configuration, a significant failure has the potential to impact the entire organization. This risk can be mitigated by adding additional pods, essentially scaling out within the configuration rather than increasing the size of a pod. For example, if the user population to be served is 10,000 hosted VDI users, it may make sense from a risk mitigation perspective to create an architecture consisting of 4 x 2,500 user pods rather than a single 10,000 user pod. In this configuration, an additional pod can be created to provide a failover environment should a single pod fail. For hosted shared desktops, splitting the configuration into pods may also be a consideration, but the threshold size can be considerably higher as there are less servers and smaller database structures in a XenApp configuration. From an estimating point of view, the size of the resource pools and pods is based on the following formulae: Continuing with the example assuming 2,500 streamed VDI users per pod, and using the scalability examples above for users and pool sizes, resource pool size and pod size can be calculated: ( ) For this example the final value (Pools per Pod) is rounded up to ensure capacity for the target number of users. This also provides a level of availability within the pod structure; if a single resource pool fails, the remaining four resource pools will be able to take up the load. Note that this needs to be evaluated on a case by case basis. If the calculation works out to a whole number, an additional resource pool may be added to the environment for redundancy at the resource pool level.

15 Determine Control Layer Requirements When determining the configuration of the control layer, two control environments need to be considered; per-desktop pod control elements, and control elements that serve the entire solution. The per-desktop pod elements are the XenDesktop and XenApp controllers, and Citrix Provisioning Server elements. Control layer components that serve the entire solution include the Citrix Licensing Server, and Microsoft SQL server elements. XenDesktop Controller The XenDesktop Controller provides the control structure to manage virtual desktops delivered through the Hosted VDI model. The following XenDesktop Controller configuration is recommended for the per-desktop pod control layer: XenDesktop Controllers VM Host CPU/Memory Configuration VM Host Networking VM Host Storage Windows OS Windows Roles/Features 4 vcpu, 4GB RAM Bonded virtual NIC 40GB Shared Storage for OS, XenDesktop Windows Server 2008R2 Web Services (IIS).NET Framework Windows Process Activation Service XenDesktop XenDesktop 5.5, 5.6 Table 5: XenDesktop Controller Configuration A single XenDesktop Controller using this configuration can support more than 5,000 users. For redundancy, load balanced N+1 configuration is used. Given a load balanced configuration for XenDesktop Controllers, a pair of controllers can support a single XenDesktop site of over 10,000 users, so three controllers are required based on the sample load and configuration. XenApp Controllers The XenApp Controller provides the link between the Web Interface and the XenApp pool providing Hosted Shared desktops. The following XenApp Controller configuration is recommended for the per-desktop pod control layer: XenApp Controllers VM Host CPU/Memory Configuration VM Host Networking VM Host Storage Windows OS 4 vcpu, 8GB RAM Bonded virtual NIC 40GB Shared Storage for OS, XenApp Windows Server 2008R2 Windows Roles/Features.NET Framework Remote Desktop Services Role Windows Application Server Role XenApp XenApp 6.5 Table 6: XenApp Controller Configuration

16 For environments beyond 2,000 users, or for farms where periods of heavy logon traffic is anticipated, Citrix recommends dedicated virtual servers for XML Broker components. For all XenApp farm configurations, a single Zone Data Collector (ZDC) is required, with a backup for redundancy. Primary and backup ZDC servers should be dedicated for environments with more than 10 and 20 servers respectively. For XML controllers, the following formula is used: Citrix Provisioning Server The following Provisioning Server configuration is recommended for the per-desktop pod control layer: Provisioning Server VM Host CPU/Memory Configuration 4 vcpu, 32GB RAM VM Host Networking VM Host Storage Windows OS Dual Bonded 10GB Virtual NIC for data 40GB Shared Storage for OS, Provisioning Server Windows Server 2008R2 Windows Roles/Features.NET Framework Citrix Provisioning Server CPS v6.1 vdisk Storage CIFS Share with SMB v2 configuration Table 7: Provisioning Server Configuration A single virtual provisioning server will support approximately 1000 streams. In order to provide N+1 redundancy, a minimum of two Provisioning Servers are required. In order to support the target configuration size, the following formulae can be used: ( ) ( ) This value should be rounded up to the next highest whole number to ensure redundancy and adequate scalability. Note that the amount of RAM required per server may vary depending upon the number of vdisk targets that are streamed and need to be kept in memory to reduce disk I/O. In order to size provisioning server memory, the following formulae may be used: Note: A good starting point for determining the minimum amount of server memory is to allocate 2GB of RAM per active desktop vdisk and 10GB of RAM per active server vdisk. For most Provisioning Services implementations, the amount of RAM allocated to each Provisioning Server will fall between 8GB and 32GB. For more information on memory and storage considerations for Provisioning Server, refer to Citrix Knowledgebase Article CTX125126

17 SQL Database The SQL database provides the foundation for the XenDesktop configuration, storing all configurations, desktop and current utilization information. The following SQL server configuration is recommended for the control layer: Control Brick Configuration: SQL Servers VM Host CPU/Memory Configuration VM Host Networking VM Host Storage SQL Database Storage (SQL Mirrors Only) Windows OS Calculated value SQL Mirrors 2 vcpu, 4GB RAM - Witness Bonded virtual NIC 40GB Shared Storage for OS, SQL Storage for Databases Storage for Transaction Logs Windows Server 2008R2 Windows Roles/Features.NET Framework SQL Software Microsoft SQL Server 2008 R2 Table 8: SQL Server Configuration For a standard mirrored with witness configuration for SQL Server, three virtual machines are required. Two of the VMs will host the databases and process transactions, and the third will monitor the production and mirror copies of the database and will initiate failover if required. The witness server does not require a high amount of system resources as it does not process transactions or update the databases. For the modular architecture, a single SQL mirror set with witness can support the entire environment, but the CPU and Memory resources for the two SQL mirror servers will need to scale to meet the needs as user load increases. The following are guidelines for increasing CPU and Memory: vcpu and Memory Sizing Less than 2,500 users, 2 vcpu, 4GB RAM 2,500 to 10,000 users, 4 vcpu, 8GB RAM Greater than 10,000 users, 8 vcpu, 16GB RAM Note: Beyond 20,000 users, CPU and Memory utilization on the SQL servers should be reviewed to determine when the SQL environment should be scaled out to a new configuration. For more information on XenDesktop scalability, refer to Citrix Knowledgebase Article CTX The most significant factor when sizing the database server will be determining the database and transaction log sizing. Database sizing is relatively static for XenDesktop, XenApp and Provisioning Services load, but transaction logs for XenDesktop are difficult to size as they depend upon multiple factors such as the database recovery model, the peak desktop launch rate, and the number of desktops in use. Rule of thumb calculations for database space and transaction log for Hosted VDI and Hosted Shared desktops are as follows: Hosted VDI Citrix recommends that a fixed-size transaction log be used and that a SQL Alert is set up so that when the transaction log reaches 50 percent full, the transaction log is backed up, thus freeing up the log space.

18 Hosted Shared Provisioning Server The Provisioning Services database stores all system configuration settings that exist within a farm. The Provisioning Services farm database will rarely grow beyond 250MB in size, even with large environments. The following formula can be used to estimate the size of the Provisioning Services database: ( ( ( )) These calculations are initial estimates. Specific details on configuring SQL for XenDesktop can be found in the Citrix whitepaper XenDesktop 5 Database Sizing and Mirroring Best Practices. Desktop Director Desktop Director provides support resources with access to information required to manage and support XenDesktop and XenApp environments. The following Desktop Director configuration is recommended for the control layer: Desktop Director VM Host CPU/Memory Configuration 4 vcpu, 8GB RAM VM Host Networking VM Host Storage Windows OS Windows Roles/Features Bonded virtual NIC 40GB Shared Storage for OS, License Server Windows Server 2008R2 Web Services (IIS).NET Framework Desktop Director Desktop Director 2.1 Table 9: Desktop Director Configuration A single Desktop Director server with this configuration can support up to 20,000 desktops and access by 100 Desktop Director Users. In order to maintain access, redundant (N+1) and load balanced Desktop Director Servers are recommended. This value should be rounded up to the next highest whole number to ensure redundancy and adequate scalability.

19 Citrix License Server The licensing server provides Citrix licensing for all components within the XenDesktop architecture, with the exception of the NetScaler components in the Access pool, as they are manually configured with license files. The following license server configuration is recommended for the control layer: Citrix License Server Number of VM s 1 VM Host CPU/Memory Configuration VM Host Networking VM Host Storage Windows OS Windows Roles/Features 2 vcpu, 4GB RAM Bonded virtual NIC 40GB Shared Storage for OS, License Server Windows Server 2008R2 Web Services (IIS).NET Framework Windows Process Activation Service License Server Citrix License Server Table 20: License Server Configuration A single Citrix License server can issue approximately 170 licenses per second or over 300,000 licenses every 30 minutes. Because of this scalability, a single virtual license server with VM level HA can be implemented. Determine Access Layer Requirements The access layer provides connectivity for end users to the XenDesktop environment. It includes two components; StoreFront or Web Interface, and NetScaler. Architects can choose to implement either StoreFront or Web Interface as the primary access method, and have the option to implement both if requirements dictate. The NetScaler component provides both secure remote access through integrated Access Gateway functionality as well as intelligent load balancing for the Web Interface and XenDesktop and XenApp Controllers. StoreFront The StoreFront server provides authentication and resource delivery services to Citrix Receiver for the XenDesktop infrastructure. The following StoreFront configuration is recommended for the access layer: StoreFront Server VM Host CPU/Memory Configuration VM Host Networking VM Host Storage Windows OS Windows Roles/Features 4 vcpu, 4GB RAM Bonded virtual NIC 40GB Shared Storage for OS, Web Interface Windows Server 2008R2 Web Services (IIS).NET Framework Windows PowerShell 2.0 Microsoft Management Console 3.0 Web Interface StoreFront 1.2 Table 13: StoreFront Server Configuration

20 A single StoreFront server with this configuration has the capacity to handle more than 24,500 connections per hour. A minimum of two StoreFront servers should always be configured and load balanced through NetScaler to provide redundancy and balance load. This value should be rounded up to the next highest whole number to ensure redundancy and adequate scalability. Web Interface The Web Interface provides initial user access into the XenDesktop infrastructure. The following Web Interface configuration is recommended for the access layer: Web Interface VM Host CPU/Memory Configuration VM Host Networking VM Host Storage Windows OS Windows Roles/Features 2 vcpu, 4GB RAM Bonded virtual NIC 40GB Shared Storage for OS, Web Interface Windows Server 2008R2 Web Services (IIS).NET Framework Windows Process Activation Service Web Interface Web Interface 5.4 Table 43: Web Interface Configuration A single Web Interface serve has the capacity to handle more than 30,000 connections per hour. Two Web Interface servers should always be configured and load balanced through NetScaler to provide redundancy and balance load. This value should be rounded up to the next highest whole number to ensure redundancy and adequate scalability. NetScaler Citrix NetScaler provides secure remote access through integrated Access Gateway functionality and intelligent load balancing for the Web Interface, XenDesktop controllers and XenApp controllers. Two NetScaler appliances configured in an Active/Passive pair are used to provide availability for the NetScaler functionality in the event of an appliance failure. The primary sizing guideline for NetScaler is based on SSL throughput. The largest amount of traffic through the NetScaler appliances will be the Access Gateway traffic; load balancing traffic is nominal. To determine the throughput required, the bandwidth requirements for groups accessing the environment remotely should be determined and used in the following formulae. This calculation should be performed for each datacenter in the environment. Although the SSL bandwidth overhead is often considered negligible, it should be factored into the calculation for total bandwidth requirements to ensure the estimated throughput is sufficient. For initial estimates, a 2% overhead is a reasonable rule of thumb.

21 This value is compared to the throughput capabilities for various NetScaler models to determine the best appliance to use for the configuration. The following table represents a sample of NetScaler capabilities for SSL Throughput. For current throughput numbers, refer to the NetScaler Data Sheet.. NetScaler Model MPX 5500, MPX 5660, ,000 MPX ,500 MPX 11,500 6,000 MPX ,000 MPX ,000 MPX ,000 SSL Throughput (Mb per second) Table 54: NetScaler Configuration For example, assuming 10,000 users with 2,000 remote users in a single group, and 65K average bandwidth utilization, the appropriate NetScaler model can be determined as follows: As there is only one group in this example, Total bandwidth is equivalent to user group bandwidth. Based on this calculation, a pair of NetScaler MPX 5500 devices would be sufficient to handle the load.

22 Design Examples Now that all the components of the modular architecture are determined, example configurations can be created. For design examples, this whitepaper looks at a configuration containing a mix of FlexCast models configured across a number of configurations, as follows: The example environment consists of a mix of FlexCast models with 40% Hosted Shared, 20% Pooled VDI, and 40% Dedicated VDI desktops. All Hosted VDI desktops are streamed from Provisioning Servers and Personal vdisk (PVD) is not used. Web Interface is used as the method to access the environment. The user load is considered Normal across all models. Based on risk, a new XenDesktop Hosted VDI pod will be created if there are more than 5,000 users in a single site. For Hosted Shared, a new pod will be created if there are more than 20,000 users in a single XenApp farm. Configuration sizing for the three examples is as follows: Model Size # Users Hosted Shared Pooled VDI Dedicated VDI Small 2,500 1, ,000 Medium 15,000 6,000 3,000 6,000 Large 50,000 20,000 10,000 20,000 Table 65: Example Users To stay consistent with the examples, the hardware specification for this design consists of servers with 2x8 core CPU and 128GB RAM. Based on these values and the formulae in the Design Planning section of this whitepaper, we can create the following configurations: Desktop Layer Model Size # XenApp Servers # XenApp Pools # Hosted Shared Pods # VDI Servers # VDI Pools # Hosted VDI Pods Small Medium Large Table 16: Desktop Layer Configuration Note that the Pooled and Dedicated VDI user requirement is combined into a single Hosted VDI configuration.

23 Control Layer Model Size # XenApp ZDC # XenApp XML # XenDesktop Controllers #Provisioning Servers # SQL Cluster Servers # Desktop Director Servers Small Medium Large Table 77: Control Layer Configuration # License Servers Based on vcpu and memory requirements as referenced in the Design Planning section of the document, and using the same 2x8 core CPU and 128GB memory configuration, the virtual servers in the control layer will require the following hardware. For this calculation, 1 vcpu equals 1 core, and CPU overcommit is not considered. Model Size Access Layer Control Layer vcpu Total Control Layer Memory Total GB Small Medium Large Table 18: Server Requirements Servers Required For this example, it is assumed that 20% of the user population will be remote, and the average bandwidth consumed is 65 KB per second. Model Size # Web Interface # NetScaler Appliances Small 2 2 MPX 5500 Medium 2 2 MPX 5500 Large 3 2 MPX 7500 Table 89: NetScaler Requirements The small number of virtual servers required for the Web Interface components of the access layer consumes 4-6 vcpu and 8-12 GB of RAM. Given the low resource requirements for these components, they can be hosted within the hardware infrastructure dedicated to the control layer. The NetScaler components are physical appliances.

24 Summary As XenDesktop environments scale to large numbers of users risk mitigation becomes increasingly important. The loss of a single XenDesktop site through component failure or database corruption can affect a large number of users if the design considers a single site. The modular reference architecture presented in this paper offers organizations a way to design an environment that mitigates risk by creating smaller XenDesktop pod instances which are analogous to traditional XenDesktop sites and XenApp farms. The layered architecture also simplifies the design allowing architects to focus on design elements at each layer separately, and scale each layer in a logical fashion. The overall architecture allows organizations to create a XenDesktop environment with multiple FlexCast models that can scale from a small, single site to an enterprise configuration that can provide virtual desktops for large numbers of users.

25 Revision History Revision Change Description Updated By Date 1.0 Initial Document Rich Meesters April 18, Revised Hosted Shared Rich Meesters April 30, 2012 Calculations 1.3 Updated XenApp Andy Baker August 24, 2012 scalability 2.0 Added Personal vdisk, updated estimates Rich Meesters April 1, 2013 Acknowledgements Citrix Consulting would like to thank all the individuals that offered guidance and technical assistance during the course of this project including those who were extremely helpful answering questions, providing technical guidance and reviewing documentation throughout the project: Andy Baker Thomas Berger Matthew Brooks Daniel Feller About Citrix Citrix Systems, Inc. (NASDAQ:CTXS) is a leading provider of virtual computing solutions that help companies deliver IT as an on-demand service. Founded in 1989, Citrix combines virtualization, networking, and cloud computing technologies into a full portfolio of products that enable virtual workstyles for users and virtual datacenters for IT. More than 230,000 organizations worldwide rely on Citrix to help them build simpler and more cost-effective IT environments. Citrix partners with over 10,000 companies in more than 100 countries. Annual revenue in 2011 was $2.20 billion Citrix Systems, Inc. All rights reserved. Citrix, Access Gateway, Branch Repeater, Citrix Repeater, HDX, XenServer, XenApp, XenDesktop and Citrix Delivery Center are trademarks of Citrix Systems, Inc. and/or one or more of its subsidiaries, and may be registered in the United States Patent and Trademark Office and in other countries. All other trademarks and registered trademarks are property of their respective owners.