Escolar Documentos
Profissional Documentos
Cultura Documentos
www.citrix.com
Contents
1.0 1.1 1.2 1.3 1.4 2.0 2.1 2.2 2.3 Introduction ........................................................................................................................................... 4 Application deployment ................................................................................................................... 4 Remote office connectivity .............................................................................................................. 5 Workforce mobility ........................................................................................................................... 5 Business continuity ........................................................................................................................... 6 Product and solution overview............................................................................................................ 6 Citrix XenApp server ........................................................................................................................ 6 Simulated environment..................................................................................................................... 7 XenApp configuration...................................................................................................................... 9
2.3.1 Data store ........................................................................................................................................... 9 2.3.2 Data collector ...................................................................................................................................12 2.3.3 XML server ......................................................................................................................................19 2.3.4 License server...................................................................................................................................19 2.3.5 Citrix AppCenter Console .............................................................................................................22 2.4 2.5 2.6 3.0 3.1 Web Interface configuration..........................................................................................................23 Worker group configuration ..........................................................................................................24 Citrix policy configuration .............................................................................................................32 Performance results and analysis.......................................................................................................36 Farm environment ..........................................................................................................................36
3.1.1 Network configuration ...................................................................................................................36 3.1.2 Farm-wide IMA bandwidth consumption...................................................................................36 3.2 XenApp performance results ........................................................................................................41
Page 2
3.2.1 Data collector performance ...........................................................................................................41 3.2.2 Data collector bandwidth ...............................................................................................................44 3.2.3 Data store performance..................................................................................................................44 3.3 4.0 4.1 Worker Groups ...............................................................................................................................46 Test environment ................................................................................................................................47 Hardware and software configuration..........................................................................................47
Page 3
1.0 Introduction
Citrix XenApp 6.5 provides advanced management and scalability, a rich multimedia experience over any network, and self-service applications with universal device support from PC to Mac to smartphone. With full support for Windows Server 2008 R2 and seamless integration with Microsoft App-V, XenApp 6.5 provides session and application virtualization technologies that make it easy for customers to centrally manage applications using any combination of local and hosted delivery to best fit their unique requirements. XenApp 6.5 introduces significant enhancements that simplify application management and bring unprecedented levels of scalability to increase cost savings and datacenter efficiency. XenApp gives corporations the ability to centrally manage heterogeneous applications and deliver Software as a Service (SaaS) to their workforce. This report documents the Citrix solution to maximize the business requirements to provide a scalable and high availability infrastructure while delivering on-demand access to applications and information for the enterprise. The requirements and associated solutions are consistent with the business needs and challenges that are common to most large scale organizations.
1.1
Application deployment
In a business world transformed by globalization, IT staff is presented with the challenge to satisfy their user community with services that incorporate the fundamentals of access at anytime from anywhere, with any-device through any-connection, all the while, ensuring secure access to business-critical applications and information. Continuous access to realtime information is integral to success of a business. Accomplishing this across the network requires robust, centralized application delivery and management capabilities. The solution must be scalable, reliable, manageable, and secure. Businesses can count on Citrix solutions to achieve this goaland to maintain their competitive advantage. XenApp 6.5 provides the ability to: o allow rapid application deployment what used to take months now takes minutes o accelerate delivery of a full range of business applications including ERP, CRM, and office productivity software o enable rapid technology integration following mergers and acquisitions o increase ROI by extending the life of existing technology investments without rewriting applications or changing existing computing architectures o reduce IT infrastructure costs up to 50% over five years o maximize the productivity of IT staff and reduce IT costs by centralizing data center operations
Page 4
1.2
1.3
Workforce mobility
Employees can be anywhere when the need arises to access information and applications. XenApp provides access to a companys networked resources beyond the traditional office environment to anywhere, on any device, over any connection. XenApp 6.5 provides the ability to: o provide the mobile workforce with real-time remote access to business-critical applications and data o increase productivity by giving telecommuters a familiar desktop-to-go accessible from anywhere o empower the workforce with high-performance wireless access on a platform that works today o reduce costly bandwidth and telecommunications charges and eliminate traditional compromises for secure remote access
Page 5
And accomplish all of this without redeveloping applications or changing current application-serving hardware. XenApp 6.5 is an effective workforce mobility solution that allows mobile users to access applications and data as they would if they were in a traditional office. Whether tracking a customer order in an ERP system, accessing the corporate mail system, reviewing confidential patient health records, or just browsing the Internet, the Citrix workforce mobility solution provides the secure, reliable wireless access needed to keep business going while on the go.
1.4
Business continuity
In preparing for natural, man-made or technological disasters, todays management must be able to maintain nothing less than uninterrupted connection for employees, customers, suppliers, and business partners. Normal service level agreements allow for little or no downtime. XenApp server enables this level of continued operations by protecting critical information and applications, providing secure Web access to essential business resources, and allowing users to continue working while remote. XenApp 6.5 provides the ability to: o resume serving customers quickly and allowing displaced workers to securely access key applications and data remotely over the Internet o empower employees to continue working from alternative locations, including home offices even if the main location is inaccessible o provide application redundancy through remote data centers XenApp 6.5 provides a critical component to an efficient and cost-effective business continuity plan. XenApp allows users to continue working even after an unplanned disruption. Losses such as network, power, or loss of the entire workplace due to fire or flood, can be mitigated with Citrix XenApp server. Citrix products can be implemented to permit employees and business partners to continue their work and securely connect to critical corporate resources from any anywhere, on any device, over any connection. The solutions provided by Citrix products assure the rapid secure access to business-critical data and applications, which is the cornerstone of any corporate business continuity plan.
any custom or commercially packaged Windows or Web application. XenApp provides an exceptional foundation to build highly scalable, flexible, secure, manageable access solutions that reduce computing costs and increase the utility of any information system. For the purposes of this document, a fictitious corporation will be created, named XYZ Corporation. The XYZ Corporation is faced with all of the challenges that have been mentioned in this report. Citrix XenApp 6.5 provides the means to satisfy all of the business requirements for XYZ Corporation. XenApp server addresses remote office connectivity, application deployment, workforce mobility, and business continuity requirements leading to a seamless, end-to-end solution. In order to satisfy the requirements for the company, XenApp server was architected and deployed with the following core XenApp components: o XenApp 6.5 o Web Interface, version 5.4
2.2
Simulated environment
XYZ Corporation is in the process of identifying a solution that will satisfy the requirements and challenges of their organization. Citrix products will be introduced to maximize the efforts of the company to achieve all of its corporate IT initiatives. The data compiled in this report will consist of real-time simulations and provide a valuable retrospective satisfying the infrastructure requirements of XYZ Corporation with scalable, secure and reliable Citrix products. The corporate infrastructure for the XYZ Corporation is based on Microsoft products and solutions. They have implemented an Active Directory based infrastructure. XYZ Corporation employs a hybrid administration model. The architecture group is based out of the Fort Lauderdale office. This group is responsible for company-wide IT infrastructure and the Citrix XenApp farm. They implement Active Directory group policies to meet the existing business needs and want the ability to configure and maintain the Citrix XenApp policies from the same Active Directory group policy console. XYZ Corporation has distributed operations with data centers on the east and west coast of the United States. Two data centers have been created for business continuity purposes. Fort Lauderdale, Florida hosts one, while Redmond, Washington hosts the other. XYZ Corporation uses an Active-Active Disaster Recovery model. Each site is fully redundant and has the capacity to service all the users for the entire organization. The data centers are responsible for serving the following business functions: o access to mission critical applications for 60,000 corporate users (30,000 at each site) o each site must have the capacity to service all of the users for the entire company, equating to a farm capable of servicing 60,000 users o access to applications for 1,000 remote users and traveling users
Page 7
o access to partner applications for business partners It is important to note that XYZ Corporation is a fast growing company and has plans to expand their capacity at their existing sites and to add additional sites in the future. They want to ensure that their farm design is scalable and allows them to rapidly add new XenApp servers. The XenApp farm for the XYZ Corporation contains three types of server images: one server image hosts business essential applications delivered to all employees, the second server image contains applications delivered to engineering, and the third server image contains applications that are reserved for the finance department.
Figure 1 XYZ Corporation Active Directory Model The Fort Lauderdale and Redmond offices have separate XenApp administrators responsible for maintaining the servers in their respective locations. The local XenApp administrators are responsible for tasks such as publishing applications, rebooting servers, and monitoring servers in their zones. These XenApp administrators only have rights to administer servers in their zones. The helpdesk is tasked with the responsibility of managing user sessions and being able to shadow in order to better support their employees.
Page 8
2.3
XenApp configuration
The following section outlines the architectural design for the XenApp farm. A review of the primary components of the XenApp farm has been outlined with details to its influence on the solution architected for XYZ Corporation.
Page 9
Application publication o 10 hosting servers o 5 user groups o default icon Application publication o 32-bit color icon Application publication o 256-bit color icon Create one worker group Create one load evaluator Apply the load evaluator o 10 servers Table 1 XenApp common object sizes
40
24 48 2 8 16
Table 1 displays the object sizes commonly used XenApp objects. The XYZ Corporation will create a farm with 1,000 servers and 1,000 applications published applications, 100 worker groups to serve as applications silos, and 10 load evaluators. To satisfy this design, the IMA data store size requirement will be approximately 500MB.
The SQL database server for XYZ Corporation has Intel Xeon E5310 Quad-Core 1.6 GHz Processor and 16GB memory.
Page 11
The other main responsibility of the data collector is to perform resolutions. A resolution is the process where the data collector determines the least-loaded server that is hosting the requested load-balanced published application. If the application spans multiple zones, the data collector asks the other data collectors to resolve the application as well. When all responses are returned, it selects the least-loaded server, and directs the client to connect to that server. Reminder: Data Collectors cannot be configured to run in Session-only mode. Servers running in Session-only mode cannot function as Data Collectors or backup Data Collectors and are not capable of participating in elections. In order to reduce the impact of performing resolutions across zones, Server group preference and failover should be configured for the users. Server group preference and failover sets an affinity based on username, client name, or client IP address to determine the zone that is optimal for the user to connect to as defined by the administrator. During resolution time, the data collector filters the list of available servers hosting the published application based on the clients preference setting, and only performs the resolution in the primary zone. If the primary zone is not available, the client fails over to the next preferred zone.
Page 13
Figure 4 Zone design decision considerations In the case of XYZ Corporation, two zones of 500 servers would be optimal due to the environment consisting of two distinct data centers which host an equal number of XenApp servers. The number of zones in the farm should be kept to a minimum. The fewer zones in a farm, the more scalable the farm. The reason is that every time a dynamic event occurs, such as a logon, logoff, or disconnect, an update is sent to the data collector. The data collector must then forward the update to all other data collectors in the farm, which consumes bandwidth and CPU. This is an important consideration because data collectors must keep up with the events in other zones as well as their own.
Page 14
In the near future, XYZ Corporation plans to expand operations to a small, remote site in San Francisco which would house 50 XenApp servers in the same farm with approximately 500 users. Would the same strategy of one zone per site apply? The following analysis will demonstrate why in this case, it would be optimal for the servers in San Francisco to join the Red Zone.
Figure 5 Proposed corporate expansion to another zone Assume the San Francisco location needs to be added to the current topology. In this proposed design, the bulk of the users are in Fort Lauderdale and Redmond with 30,000 users at each location. Meanwhile, the site in San Francisco has 500 users. In this scenario, because all data collectors have to replicate all session information to all other data collectors in the farm, the San Francisco data collector will receive 60,000 updates although it only generates 1,000 replication updates, resulting in 60.5 MB of bandwidth utilization.
Page 15
Figure 6 Expansion of RED zone with multiple sites If the Redmond and San Francisco servers are combined in the Red Zone, member server requests will still traverse the WAN between San Francisco and Redmond for resolutions, load updates, etc., however, Fort Lauderdale replication traffic will not be sent across the wire to San Francisco. Since IMA traffic does not need to be replicated from Fort Lauderdale and Redmond to San Francisco, the bandwidth consumption is cut in half. In the event the WAN link between Redmond and San Francisco goes down, a data collector will be elected in San Francisco and users will still be able to connect to resources both within the San Francisco and Redmond sites. For this reason, it is important to configure at least one server in San Francisco in non-Session-only mode so it could participate in elections and designate itself as the data collector for the San Francisco site. When the WAN link is restored the zone will consolidate back down to a single data collector.
In order to satisfy the business requirements for XYZ Corporation it is important to have a dedicated backup data collector for each zone and at each site. In the event the primary data collector goes offline, a new dedicated server is available to assume the data collector role. If the data collector role is assumed by a server that is not dedicated, resource contention between application users and the data collector operations can result in data collector events getting queued. This occurrence can have a ripple effect to the rest of the data collectors in the farm as updates are not sent and received properly.
Page 17
Figure 8 shows the memory usage based on the number of sessions. The average session consumes approx. 1.6 KB of memory on the data collector.
Figure 8 IMA memory consumption for number of sessions Figure 9 references the memory usage bsed on varying numbers of servers. The average server consumes approx. 210 KB of memory on the data collector.
Figure 9 IMA memory consumption for number of servers Based off the data above, for the XYZ Corporation to host 2,000 applications, 100k sessions in a 1,000 server farm, the data collector will consume approx. 380 MB of memory. It is important that all data collectors in the farm are sized to accommodate the largest zone. Since data collectors must manage the global state of the farm, they
Page 18
require the same processing capability of the other data collectors in the farm regardless of the size of their particular zone. Likewise if the data collector needs to be dedicated for one zone, all data collectors in the farm should be dedicated.
Page 19
Page 20
general, the size of the farm and the number of simultaneous client connections dictate the power of the server needed for the licensing feature. To appropriately size the license server it is important to determine the number of client logins per second in the farm deployment. This can be accomplished using the Performance Monitor counters available within XenApp and the load evaluator logging feature. This analysis will determine the processor speed needed for optimal license server performance. Another consideration when sizing the license server is that multiple processors do not provide performance increases because the license server process is single threaded. CPU speed is the most important aspect to consider for sizing the license server. The license server uses approximately 4.5KB of memory for every session license and 39KB of memory for every start-up license that is in-use. The license server is capable of processing 248 license check-out requests per second. In a given scenario with all users logging in over the course of 30 minutes, a single license server would be able to handle 446,400 users.
server, connections are denied. For XYZ Corporation, the 720 hour grace period provided more than enough time for recovery in the event of a failure. However, for some environments, this is not adequate. A hot or cold standby of the license server can be built into the farm. If the license server goes offline, the administrator can bring up a backup license server. In the cases where failover with no administrative interaction is required, Microsoft Clustering Services can be used in order to deliver hardware-based fault tolerance for the license server. For more information on setting up the license server in a clustered environment, please refer to the Citrix eDocs.
Page 22
2.4
Page 23
The XYZ Corporation plans to deploy a dedicated Web Interface server to each of the zones and sites in the farm. In the case the WAN link goes down, users in the remote sites will still be able to access their Web Interface sites locally and access their applications.
How many Web Interface servers are needed to support 30,000 users?
The Web Interface used in this simulation is a Intel Xeon X3360 dual core 2.2 GHz server with 2GB of RAM and HyperThreading turned on. As shown in Table 2, this server was able to handle 9.2 user requests per second. A Web Interface server was placed at each site to service the 30,000 internal users at each location.
Platform Windows Server 2008 R2 / IIS7 requests / second 9.2 User scalability 33,700 users / hour
Table 2 Web Interface user scalability In general the number of users that a single Web Interface server can support is dependent on the processor speed rather than the number of processors in the system.
2.5
Page 24
Figure 12 Worker groups and application silos The worker group container offers the following benefits: 1. A single server may belong to multiple worker groups. Unlike server folders, where a server can only belong to a single folder. Now servers can be grouped into worker groups for multiple reasons. For instance, servers may be grouped into worker groups both by their geographic region and by the applications they host. 2. Worker groups are more granular than zones. Worker groups can be created to control load balancing within a single site. A worker group may even consist of a single server. 3. Worker groups can be dynamic. For example, when AD containers are added to a worker group, changes in the AD container are automatically reflected in the server's worker group memberships. There are two ways to add servers to a worker group: 1. Servers may be explicitly added to a worker group by name. This allows administrators to add specific servers to a worker group and is the only option in non-AD environments. 2. Servers may be added by AD Organizational Units or Server Groups. This allows worker groups to be dynamically updated based on the servers AD memberships. That is, as servers are added or removed from the AD containers, they will be automatically added or removed from the respective worker groups. For this simulation, the XYZ Corporation administrators have chosen to manage their XenApp farm through Active Directory. Figure 13 shows the Active Directory
Page 25
Organizational Unit (OU) for the XenApp farm and grouping structure of the servers.
Figure 13 Active Directory Organization Unit (OU) In preparation for future expansion, the XYZ Corporation has created two sets of worker groups: one set to group servers by application and one set to group servers by geographic location. Given this approach, when the company adds a new site, they do not need to modify the servers list of all published applications. Instead, they simply add the sites OU to the appropriate worker groups for the applications. Figure 14 and Table 3 illustrate XYZ Corporations worker group structure.
Page 26
Figure 14 Worker group layout Worker Group Apps\Business Essential Apps Organizational Units OU=Business Essential Apps, OU=San Francisco, OU=XenApp, DC=XYZCorp OU=Business Essential Apps, OU=Redmond, OU= XenApp, DC=XYZCorp OU=Financial Apps, OU=Redmond, OU= XenApp, DC=XYZCorp OU=Engineering Apps, OU=Redmond, OU= XenApp, DC=XYZCorp OU=Business Essential Apps, OU= Ft Lauderdale, OU= XenApp, DC=XYZCorp OU=Financial Apps, OU= Ft Lauderdale, OU= XenApp, DC=XYZCorp OU=Engineering Apps, OU= Ft Lauderdale, OU= XenApp, DC=XYZCorp OU=Engineering Apps, OU=Redmond, OU= XenApp, DC=XYZCorp OU=Engineering Apps, OU= Ft Lauderdale, OU= XenApp, DC=XYZCorp OU=Financial Apps, OU=Redmond, OU= XenApp, DC=XYZCorp OU=Financial Apps, OU= Ft Lauderdale, OU= XenApp, DC=XYZCorp OU=Business Essential Apps, OU= Ft Lauderdale, OU= XenApp, DC=XYZCorp OU=Engineering Apps, OU= Ft Lauderdale, OU= XenApp, DC=XYZCorp OU=Financial Apps, OU= Ft Lauderdale, OU= XenApp, DC=XYZCorp OU=Business Essential Apps, OU=Redmond, OU= XenApp, DC=XYZCorp OU=Engineering Apps, OU=Redmond, OU= XenApp, DC=XYZCorp OU=Financial Apps, OU=Redmond, OU= XenApp, DC=XYZCorp OU=Business Essential Apps, OU=San Francisco, OU= XenApp, DC=XYZCorp Table 3 Worker group structure
Page 27
Apps\Engineering Apps
Apps\Financial Apps
Sites\Ft Lauderdale\FTL Business Essential Sites\Ft Lauderdale\FTL Engineering Sites\Ft Lauderdale\FTL Financial Sites\ Redmond \FTL Business Essential Sites\ Redmond \FTL Engineering Sites\Redmond\FTL Financial Sites\San Francisco\FTL Business Essential
The following sections will show these worker groups are integrated with three XenApp features: application publishing, load balancing policies, and Citrix policy filters.
Application publishing
Each published application in XenApp contains a list of servers hosting that application. XenApp 6.5 supports adding worker groups to the application server list, which greatly simplifies management of application silos and capacity management. Without using worker groups, managing a silo of servers requires ensuring each application in the silo is published to all servers for that silo. For example, Figure 15 illustrates the application/server mappings of a 5-server silo hosting Microsoft Office applications.
Figure 15 Published applications server support without worker groups In this case, each of the five servers has to be added to the servers list of each of the Microsoft Office applications. If a new server is brought online, the applications server list would need to be updated manually to account for the new server. However, this deployment can be simplified using worker groups. Instead of publishing each application to each server, a worker group is created containing the servers hosting the Microsoft Office applications. Instead of adding individual servers, the worker group is added to the servers list of each of the applications.
Page 28
Figure 16 Published applications with worker group support In the future, to increase capacity in the application silo, a new server is added to the worker group. This eliminates the need to manually modify the properties of each published application hosted by the server. With dynamic provisioning, this step can even be automated using AD, by creating a base image for each application silo containing XenApp and all of the applications installed. To add capacity, simply create a new instance of the base image and add it to the desired OU. The server will receive its server settings from AD, join the appropriate worker groups, and begin hosting published applications.
Page 29
Server Worker Groups\Apps\Business Essentials Apps Worker Groups\Apps\Engineering Apps Worker Groups\Apps\Financial Apps
XYZCorp\Finance
Table 4 Worker groups Creating separate worker groups for application publishing gives XYZ Corporation the flexibility to expand their farm in the future. To add additional capacity to the existing sites, XYZ Corporation can simply add new servers to the appropriate OUs. When they expand their farm to another site, they can create OUs for the new site, and add these to the two worker groups above. There is no need to change individual application settings.
Figure 17 Worker group load balancing policy When the administrator selects the checkbox Configure application connection preference based on worker group in a load balancing policy, they can configure a
Page 30
prioritized list of worker groups. When a user defined by the policy launches a published application, load balancing will return servers in the order of the priorities configured. Servers at a lower priority level will only be returned if all servers at a higher priority level are offline or fully-loaded (10,000 load). This feature replaces the Zone Preference and Failover feature in previous releases of XenApp with the following major differences: 1. This feature is not tied to zones. While worker groups may be created based upon sites and contain the same servers as a zone, worker groups may also be more granular than zones. 2. Unlike the Zone Preference and Failover feature in previous releases, users are not directed to servers in worker groups that are not included in the worker group preference list, even if all servers in the preference list are unavailable. Load balancing policies are evaluated when a user logs in to Web Interface or refreshes applications in the Citrix online plug-in. For performance, the resultant settings are then cached on the Web Interface server or with the users Citrix online plug-in and used during each application launch. In the case where multiple load balancing policies apply to a single user, the worker group preference list from the highest-priority policy will be used. Only servers in this preference list will be returned by load balancing. XenApp will not consider preference lists from lower-priority policies in the load balancing calculations. At XYZ Corporation, the administrators must ensure that engineering and financial users are always load balanced to one of the engineering or financial servers close to their offices and that all users are load balanced to servers at the nearest site and fail over to a remote site if the nearest site goes down. For this example, the site is selected by IP range: o 10.8.0.0/16: Ft. Lauderdale o 172.16.0.0/8: Redmond o 10.1.0.0/16: San Francisco The administrators then configure the Load Balancing Policies for engineering users: Policy Name FTL ENG Priority 1 Policy Filter Client IP: 10.8.0.0/16 User: XYZCorp\Engineer Client IP: 172.16.0.0/8 User: Worker Group Preference 1. FTL - Engineering 2. RED - Engineering 1. RED Engineering 2. FTL - Engineering
Page 31
RED ENG
3 4 5
XYZCorp\Engineer Client IP: 10.8.0.0/16 User: XYZCorp\Finance Client IP: 172.16.0.0/8 User: XYZCorp\Finance Client IP: 10.8.0.0/16
1. 2. 1. 2. 1. 2. 3. 1. 2. 3. 1. 2. 3.
FTL Finance RED - Finance RED Finance FTL - Finance FTL Business Essential RED Business Essential SF Business Essential RED Business Essential SF Business Essential FTL Business Essential SF Business Essential RED Business Essential FTL Business Essential
Table 5 Load balancing policies and associated priorities As shown in Table 5, users will receive the worker group preference list from the highest-priority policy with matching filters. Therefore, engineering users from the 10.8.0.0/16 IP address range will receive the FTL ENG policy while nonengineering users will receive FTL BUSINESS policy. With this configuration, XYZ Corporation can deliver separate sets of applications to the two different groups of users within the company and also ensure proper failover if a failure at one site occurs.
2.6
1. Local Machine Policy (gpedit) 2. Active Directory Group Policy (gpmc) 3. Policies node of the Citrix AppCenter Console The local machine policy can be used for managing small farms, but large farms will use either AD or the AppCenter Console to manage settings across multiple servers. AD offers the most powerful solution for administrators and supports managing settings across multiple XenApp and XenDesktop farms. Administrators create a GPO containing the desired Citrix policy settings and link the GPO to the appropriate OUs. However, for Citrix administrators who do not have control over their AD environment, XenApp 6.5 provides the policies node in the management console. Policies configured here are written to the XenApp data store and propagated to all servers in the farm. It is recommended to use smaller policies to allow for incremental updates. If Farm group policy is used, makes sure there is a replicated IMA data store on the remote site. If multiple types of policy are created, the priority of policy enforcement (from low to high) is as follows o Local GPO o Farm GPO o Domain GPO XYZ Corporation has decided to take full advantage of the AD group policies. The administrators create Citrix policies at different domain and OU structure levels. In this case, the priority of policies enforcement is as follows 1. 2. 3. 4. Policy created at the Default Domain Policy Policy created at the top OU level Policy created at the middle level OU Policy created at lowest level OU
Page 33
Figure 18 Active Directory XenApp group policies As displayed in Figure 18, the administrators at XYZ Corporation create the Citrix group policies at different XenApp OU structure levels. The XenApp General is created to apply to the XenApp farm as a whole. The FTL Site GPO is created to apply to XenApp servers at the Fort Lauderdale location. The Business App GPO is created to apply to the servers that host the business critical applications. The resultant Citrix policies applied to the Business Essential Apps OU will be the merged settings from all three GPOs. If there is a policy settings conflict among these three GPOs, the settings in Business App GPO has the highest priority and will overwrite the settings in FTL Site GPO and XenApp General GPO.
Page 34
Figure 19 Group Policy Management refresh intervals as managed by Active Directory When Citrix policies are managed from the XenApp management console (e.g., AppCenter Console), the sequence of policy refresh and update is as follows: 1. 2. 3. 4. change is made in AppCenter Console member server writes the policy change to the DS and updates its LHC all servers pull policy information from the DS and updates their LHCs within 1 to 2 hours, member servers apply updates to the registry
Figure 20 Group Policy Management refresh intervals as managed by the DSC If needed, IMA service can be restarted to refresh machine policies immediately. For user policies, logons and reconnects refresh them immediately. The gpupdate /force command can be executed to force the policy synchronization and update.
Page 35
3.1
Page 36
Figure 21 IMA bandwidth consumption XenApp Startup When the XenApp servers startup, they must establish a connection to the data store to read all of the configuration information needed to initialize IMA. Next the servers will go to the license server to check out a server license. This allows the XenApp servers to grant grace period licenses in the event the license server becomes unreachable. If the license server is unavailable at startup, as long as the XenApp server had been able to previously connect to it at least once, it will still be able to grant grace period licenses. Next the servers will be available to serve applications, so they will go and register with the data collector for their zone. Finally, the data collectors will replicate all of the registration information to the other data collectors in the farm.
Page 37
Figure 22 IMA bandwidth consumption XenApp farm is idle After the XenApp server starts, every thirty minutes the local host cache will perform a consistency check to ensure it is in sync with the data store just in case it missed a directory change notification. If the data collector has not received an update from a member server within the last 60 seconds, it will send an IMAPing to ensure the server is still up and available to service user requests. Likewise, if the data collectors have not received updates from each other in the last 60 seconds they will perform an IMAPing to ensure the remote zones are still available. Finally every 5 minutes plus some randomized interval, the XenApp servers will contact the license server to ensure it is still available.
Page 38
Figure 23 IMA bandwidth consumption user connection In this case, a user wants to connect to an application using Citrix Receiver. The data collector performs the resolution and directs the plug-in to connect to the least loaded server. When the user connects, the XenApp server will contact the license server to check-out a license on behalf of the user. Once the user is connected to the server, several things have changed on the server. The number of sessions on the server has changed and the servers load has changed. The member server will then update the data collector for its zone with that information. Since all data collectors must track the global state of the entire farm, it will replicate that information to all other data collectors in the farm.
Page 39
Figure 24 IMA bandwidth consumption new data collector election In the event that the data collector in Zone 1 has a failure, the member servers will recognize the server is offline by one of the many monitoring mechanisms and start the election process. When the new data collector is elected, all the member servers for the zone will rebuild all of their dynamic tables with the new data collector. The new data collector will then replicate that information to all other data collectors in the farm and will receive complete table rebuilds for the remote zones as well. Although the data collector went down, the user connection that was established in Figure 23 is unaffected, as once the resolution process completes, the data collector will only passively track the session.
Page 40
3.2
Page 41
Figure 26 Data collector application resolution per second Figure 26 shows a snapshot of the application resolutions rate for the Fort Lauderdale zone. At this rate, it would be able to handle 30,000 user logons at the FTL site in less than 25 minutes while the CPU usage (see Figure 27) is only at about 50%. If this same logon rate is applied to the Redmond zone, the farm as a whole would be able to log on all 60,000 users in less than 25 minutes. If XYZ Corporation wants to logon 60,000 users in shorter time, it can deploy more Web Interface servers. The Data Collector would be able to handle the additional load.
Page 42
Figure 27 shows the CPU utilization of the data collector while handling the 30,000 user application request. FTL Zone Data Collector - CPU Utilization
Figure 27 CPU utilization while handling 30,000 user requests Figure 28 shows the data collector failover performance while serving user application request: it takes about 25 seconds for the failover to occur.
Figure 29 IMA bandwidth between the FTL and RED data collectors
Page 44
Figure 29 IMA bandwidth usage during the IMA start process Additionally, the time for a server to join a farm or synchronize the local host cache has been significantly reduced. This is especially important for servers communicating to a data store over a low-bandwidth link. As shown in the figure below, XenApp 6.5 servers configured in Session-only mode show significant time savings during the join farm and LHC synchronization process over a WAN.
Much of this time saving is due to the reduced number of SQL transactions the IMA service needs to perform on the data store. Compared to previous releases, XenApp 6.5 has made substantial optimizations to IMA to reduce the number of SQL transactions and speed up the IMA start time. The figure below illustrates the number of SQL transactions are significantly reduced in XenApp 6.5.
3.3
Worker Groups
For XenApp 6.5, Citrix eLabs ran a variety to tests to ensure scalability and performance in large farms of up to 1,000 XenApp servers. The addition of worker groups did not add a significant performance overhead, even in complex environments. Some of the key metrics found during testing: 1. Application publishing to worker groups and load balancing policies had no measurable impact on application enumeration or load balancing times. 2. The number of worker groups had minimal impact on discovery times for the management console. Adding 200 worker groups increased discovery time by 2.5 seconds, while 500 worker groups increased the time by 4.2 seconds. 3. Worker groups and their memberships are cached in memory in every IMA service for performance. This results in an increase in memory consumption of 8 KB for every worker group in the farm.
Page 46
4.1
Function XenApp server Data Store1 Data Collector1 Data Collector2 License Server Backup Data Collector1 Backup Data Collector2 XML Server1 XML Server2 Backup XML Server1 Backup XML Server2 Member Server1 (200) Member Server2 (90) Member Server3 (110) Member Server4
Machine HP DL360 IBM x3250 IBM x3250 IBM x3250 IBM x3250 IBM x3250 IBM x3250 IBM x3250 IBM x3250 IBM x3250 IBM x3250 DELL 1850 HP DL1000 XenServer VM
Processor Quad-Core 1.6 GHz Xeon E5310 Quad-Core 2.83 GHz Xeon X3360 Quad-Core 2.83 GHz Xeon X3360 Quad-Core 2.83 GHz Xeon X3360 Quad-Core 2.83 GHz Xeon X3360 Quad-Core 2.83 GHz Xeon X3360 Quad-Core 2.83 GHz Xeon X3360 Quad-Core 2.83 GHz Xeon X3360 Quad-Core 2.83 GHz Xeon X3360 Quad-Core 2.83 GHz Xeon X3360 Quad-Core 2.83 GHz Xeon X3360 Dual 2.8 GHz Xeon E5520 with HT Dual-Quad 2.27 GHz E5520 2 vCPU
Backup DC for FTL zone Backup DC for RED zone Shared with Data Collector1 Shared with BDC1 Shared with Data Collector2 Shared with BDC2
(600) Web Interface Web Interface (4) IBM x3250 Quad-Core 2.83 2 GB GHz Xeon X3360 Table 6 Server configuration
5.0 Conclusion
In an era when teams are increasingly virtual, mobile and remote workforces are on the rise, and users have moved further and further away from their data, a proven remote access strategy is a must have for any organization. XenApp 6.5 addresses remote office connectivity, application deployment, workforce mobility, and business continuity requirements to lead to a seamless, end-to-end solution for the largest most demanding business environments. XenApp can scale to meet the most demanding and complex business environments. With core architectural improvements made to XenApp from release to release, XenApp 6.5 is the most scalable, high-performing release to date. XenApp provides the foundation for aggregating more than 1,000 servers into a farm, each hosting as many users as the server hardware will permit.
Page 48
About Citrix Citrix Systems, Inc. (NASDAQ:CTXS) is the leading provider of virtualization, networking and software as a service technologies for more than 230,000 organizations worldwide. Its Citrix Delivery Center, Citrix Cloud Center (C3) and Citrix Online Services product families radically simplify computing for millions of users, delivering applications as an on-demand service to any user, in any location on any device. Citrix customers include the worlds largest Internet companies, 99 percent of Fortune Global 500 enterprises, and hundreds of thousands of small businesses and prosumers worldwide. Citrix partners with over 10,000 companies worldwide in more than 100 countries. Founded in 1989, annual revenue in 2008 was $1.6 billion.
2011 Citrix Systems, Inc. All rights reserved. Citrix, Access Gateway, Branch Repeater, Citrix Repeater, HDX, XenServer, XenApp, XenDesktop and Citrix Delivery Center are trademarks of Citrix Systems, Inc. and/or one or more of its subsidiaries, and may be registered in the United States Patent and Trademark Office and in other countries. All other trademarks and registered trademarks are property of their respective owners.
Page 49