Professional Documents
Culture Documents
www.citrix.com
Contents
Overview ............................................................................................................................................................. 3 What is a Worker Group? ................................................................................................................................. 3 Introducing XYZ Corp ..................................................................................................................................... 5 Creating Worker Groups .................................................................................................................................. 6 Application Publishing ...................................................................................................................................... 9 Load Balancing Policies ..................................................................................................................................12 Citrix Policy Filters ..........................................................................................................................................15 Worker Groups and Delegated Administration ..........................................................................................16 XenApp Load Balancing .................................................................................................................................17
Troubleshooting Load Balancing .............................................................................................................................18
Conclusion ........................................................................................................................................................23
Page 2
Overview
The release of XenApp 6 adds powerful new features for XenApp administrators through integration with Active Directory (AD). All user and server settings can now be managed through AD policies, while applications and load balancing can be managed through a new container known as a worker group. Worker groups allow similar XenApp servers to be grouped together to greatly simplify the management of XenApp farms. By publishing applications and managing server settings via AD and worker groups, administrators can reduce the time to deploy new XenApp servers and increase the agility of their environment. In this white paper, we consider a fictitious company with a large, geographically-distributed XenApp farm. This company must deliver applications to two distinct groups of users with different needs. This white paper outlines the new worker group features in XenApp 6 and shows how any company can leverage worker groups to simplify their farm management. Throughout the paper, we detail the best practices for creating and managing worker groups and how these can be applied in an enterprise XenApp deployment.
Page 3
cases, the worker group hierarchy may be similar to that of zones and server folders, but worker groups serve a separate purpose and are managed independently. Zones in XenApp are used to control the aggregation and replication of data in the farm. A XenApp farm should be divided into zones based upon the network topology, where major geographic regions are assigned to separate zones. Each zone elects a data collector, which aggregates dynamic data from the servers in its zone and replicates the data to the data collectors in the other zones. However, best practices dictate that zones are only created for large sites interconnected by adequate WAN linkssmaller sites should be consolidated into a larger zone to avoid replicating all of the network traffic of the farms dynamic data to the smaller site. In past releases, zones were also used to control load balancing via the Zone Preference and Failover feature, but this has been replaced with finer-grained load balancing policies in XenApp 6. These policies eliminate the need to create zones for load balancing purposes. Worker groups should now be created to define load balancing policies, while zones should only be configured to control the data replication between data collectors. Server folders in XenApp serve two purposes. First, they provide a tree hierarchy in order to organize servers in the management console. Second, they are used to control permissions for delegated administrators. Like server folders, worker groups allow arbitrary groupings of servers, but worker groups are much more flexible. The decision to create a new 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, servers can be grouped into worker groups for multiple reasonsfor instance, servers may be grouped into worker groups both by their geographic region and by the applications they host. 2. Worker groups are more fine-grained 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. As we will see in the next section, when AD containers are added to a worker group, changes in the AD container are automatically reflected in the servers worker group memberships.
Page 4
Page 5
Miami Site
USA Zone Data Collector
London Site
UK Zone Data Collector
WAN
Productivity Apps
Productivity Apps
WAN
Atlanta Site
Productivity Apps
Figure 1 XYZ Corp's XenApp Farm In the following sections, we will look at how XYZ Corp can leverage the new features of XenApp 6 to meet their business needs and to simplify the management of their XenApp farm.
Worker groups can only consist of XenApp servers in the same farm. Non-XenApp servers, XenApp servers in other farms, users, and other objects in the AD container will not become part of the worker group. For this reason, creating a worker group with XyzCorp\Domain Computers will map to all servers in the farm belonging to the XyzCorp domain. Note: Worker group operations are not instantaneous, particularly when worker groups are managed via AD containers. For more details on the expected delays, refer to the section Data Store Synchronization on page 20.
At XYZ Corp, administrators choose to manage their XenApp farm through Active Directory. They create an organizational unit (OU) for their XenApp farm and structure their servers as follows:
Figure 2 - OU structure for XYZ Corp's XenApp farm Since XYZ Corp plans to add new sites in the future, they decide to create two sets of worker groups: one set of worker groups to group servers by application and one set of worker groups by geographic location. This way, when XYZ adds a new site, they do not need to modify the servers list of all 120 published applications. Instead, they simply add the sites OU to the appropriate worker groups for the applications. The diagram and table below illustrate XYZ Corps worker group structure:
Page 7
Figure 3 - Worker group structure for XYZ Corp's XenApp farm Worker Group Apps\Engineering Apps Apps\Productivity Apps Organizational Units
OU=Engineering Apps,OU=London,OU=XenApp,DC=XyzCorp OU=Engineering Apps,OU=Miami,OU=XenApp,DC=XyzCorp OU=Productivity Apps,OU=Atlanta,OU=XenApp,DC=XyzCorp OU=Engineering Apps,OU=London,OU=XenApp,DC=XyzCorp OU=Productivity Apps,OU=London,OU=XenApp,DC=XyzCorp OU=Productivity Apps,OU=Miami,OU=XenApp,DC=XyzCorp OU=Engineering Apps,OU=Miami,OU=XenApp,DC=XyzCorp OU=Productivity Apps,OU=Atlanta,OU=XenApp,DC=XyzCorp OU=Engineering Apps,OU=London,OU=XenApp,DC=XyzCorp OU=Productivity Apps,OU=London,OU=XenApp,DC=XyzCorp OU=Engineering Apps,OU=Miami,OU=XenApp,DC=XyzCorp OU=Productivity Apps,OU=Miami,OU=XenApp,DC=XyzCorp
Sites\Atlanta\Atlanta - Productivity Sites\London\London - Engineering Sites\London\London - Productivity Sites\Miami\Miami - Engineering Sites\Miami\Miami - Productivity
Table 1 Worker group structure for XYZ Corps XenApp farm In the following sections, we will see how these worker groups are integrated with three XenApp features: application publishing, load balancing policies, and Citrix policy filters.
Page 8
Application Publishing
Each published application in XenApp contains a list of servers hosting that application. XenApp 6 supports adding worker groups to an applications server list, which greatly simplifies management of application silos and capacity management. In previous releases of XenApp, managing a silo of servers required ensuring each application in the silo was published to all servers in the silo. For example, the diagram below illustrates the application/server mappings of a 3-server silo hosting Microsoft Office applications.
Word
Excel
Outlook
Figure 4 - Application/Server mappings of a Microsoft Office silo with XenApp 5 With XenApp 5, each of the three servers had to be added to the servers list of each of the Microsoft Office applications. However, with XenApp 6, this deployment can be simplified using worker groups. Instead of publishing each application to each server, a worker group can be 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 9
Word
Excel
Outlook
Worker Group
Figure 5 - Application/Server mappings of a Microsoft Office silo with XenApp 6 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. Create a base image for each application silo containing XenApp and all applications installed. To add capacity, 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. It is important that all applications are installed before a new server is added to an application silos OU. XenApp 6 adds a new application installation check at load balancing time. However, this check is only intended to prevent a few misconfigured servers from accepting user connections and is not meant to be used for normal load balancing. For more information about this check, see the section Application Installation Check on page 22. One side effect of publishing applications via worker groups is that XenApp 6 does not allow customizing the applications command line, working directory, or application load evaluator on a per-server basis. Administrators may continue to use system environment variables in the command line to support per-server customizations.
Page 10
Another important change between XenApp 5 and XenApp 6 is the behavior of the users list of published applications. Users are no longer required to have access to all servers that host the application and may be restricted to a subset of servers using load balancing policies, covered in the next section. In many circumstances, this change eliminates the need to publish multiple copies of the same application.
At XYZ Corp, the administrators create two worker groups specifically for publishing applications: the Productivity Apps and Engineering Apps worker groups. As noted in Table 1, the administrators configured Productivity Apps to contain both the servers from the productivity and engineering silos. With previous releases of XenApp, XYZ would have had to publish separate copies of all 100 productivity applications, one for the engineering users and one for all others, because the users use different servers. However, with XenApp 6, XYZ can publish the productivity apps to both servers and use load balancing policies to direct users appropriately. The application properties on XYZs farm would appear as follows: Productivity Applications o Servers: Worker Groups\Apps\Productivity Apps o Users: XYZCorp\All Employees Engineering Applications o Servers: Worker Groups\Apps\Engineering Apps o Users: XYZCorp\Engineering Creating separate worker groups for application publishing gives XYZ Corp the flexibility to expand their farm in the future. To add additional capacity to their existing sites, XYZ 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.
Page 11
Page 12
Load balancing policies may be used to restrict which servers are returned to a user by load balancing, but note that this does not prevent users from directly connecting to servers outside of their policy. To restrict users access to specific servers, always configure user groups on published applications and/or the Remote Desktop Users group in conjunction with load balancing policies. 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 on 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 balancingXenApp will not consider preference lists from lower-priority policies in the load balancing calculations. Note: Load balancing policies behave differently than user policies when no filters are applied. In a user policy, a policy with no filters applies to all users. For load balancing policies, a policy must have at least one filter; otherwise it applies to no users.
At XYZ Corp, the administrators must ensure that engineering users are always load balanced to one of the engineering images 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. In this example, the site is selected by IP range: 10.4.0.0/16: London 10.6.0.0/16: Miami 10.8.0.0/16: Atlanta
Page 13
The administrators then configure five Load Balancing Policies: Policy Name London - Engineering USA - Engineering London Productivity Miami Productivity Atlanta - Productivity Priority 1 2 3 4 5 Policy Filters Client IP Address: 10.4.0.0/16 Users: XyzCorp\Engineering Client IP Address: 10.6.0.0/16, 10.8.0.0/16 Users: XyzCorp\Engineering Client IP Address: 10.4.0.0/16 Client IP Address: 10.6.0.0/16 Client IP Address: 10.8.0.0/16 Worker Group Preferences 1: London Engineering 2: Miami - Engineering 1: Miami Engineering 2: London Engineering 1: London Productivity 2: Miami Productivity 3: Atlanta Productivity 1: Miami Productivity 2: Atlanta Productivity 3: London Productivity 1: Atlanta Productivity 2: Miami Productivity 3: London - Productivity
Table 2 XYZ Corps Load Balancing Policies Users will receive the worker group preference list from the highest-priority policy with matching filters. Thus, users from the 10.8.0.0/16 IP address range will receive the USA Engineering policy if they are a member of XyzCorp\Engineering, while they will receive the Atlanta Productivity policy if they are not. With this configuration, XYZ Corp 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.
Page 14
Since XYZ Corps administrators have control over their XenApp OU, they use AD GPOs to manage the settings in their XenApp farm. For user and per-site settings, they can link the GPO to the appropriate site OUs without any filters. However, if they wish to deploy a setting specifically to the engineering servers or productivity servers, they can add a Worker Group filter to the policy to limit it to the appropriate server type.
Page 15
At XYZ Corp, the company has dedicated IT staff at each of its three sites. In order to allow the site administrators to add and remove servers, XYZ delegates control of the three site-specific OUs to the appropriate IT staff. Since the applications are already published to the appropriate OUs via worker groups, the delegated administrators can add or remove servers from the silos they manage using ADthey do not need the Publish Applications and Edit Properties or Assign Applications to Servers permissions in XenApp. Session management tasks continue to be controlled via the folder-level delegated administration tasks in XenApp.
The same holds true for the XenApp PowerShell cmdlets. To add an AD object to a worker group, the Citrix administrator running the cmdlets must be a domain user. Page 16
For example, XYZ Corp is experiencing a problem where users in Atlanta are being directed to servers in Miami when they launch the Payroll application. To troubleshoot this, they use the XYZCorp\TestUser account which has the same group memberships as a typical employee, and run LBDiag on one of the servers in their XenApp farm:
Page 18
LBDiag first uses the test users credentials to enumerate all groups to which the user belongs. This is useful for understanding which load balancing policy applies to the user. In this case, the combination of the user not belonging to XYZCorp\Engineering plus the client IP in the 10.8.0.0/16 range causes the Atlanta Productivity load balancing policy to be applied, whose worker group preference list is shown next. Finally, LBDiag displays the servers in the order they would be returned by load balancing. In this case, LBDiag indicates the problem with the Atlanta site: of the 10 servers, two servers are missing the application, six are fully-loaded, and two are offline. Since none of the servers are available, users are failing over to servers in the Miami site.
Page 19
Page 20
Servers cannot update their worker group membership if the data store is down. Because of this, the data collector will continue load balancing using the worker group memberships stored in its LHC until the data store comes online, regardless of any changes made in AD. Once the data store is available, any AD changes will be reflected in load balancing within five to ten minutes. The latency of other operations is described in the diagram and table below:
Task Add/remove a server from an OU or group in Active Directory Add/remove an OU, group, or individual server from a worker group Add/remove individual server or worker group from a published application Modify load balancing policies
Expected Delay Up to 96 minutes. Rebooting the server can force an update quicker. 15 to 55 seconds 5 to 40 seconds Next user logon (Web Interface) or application refresh (Citrix online plug-in)
Page 21
Performance Metrics
For XenApp 6, 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.
Page 22
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.
Conclusion
Workers groups and the integration with Active Directory add powerful new features to XenApp 6. These features greatly simplify farm management by streamlining application publishing, providing fine-grained control of load balancing, and allow management of server settings across different groups of servers in the farm. Creating an AD and worker group hierarchy should be part of every XenApp 6 farm design. With appropriate planning, XenApp 6 greatly reduces the time to provision new servers and allows the farm to dynamically adjust to business and capacity needs.
Page 23
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 2009 was $1.61 billion. 2010 Citrix Systems, Inc. All rights reserved. Citrix, Access Gateway, Citrix Receiver, HDX, XenServer, XenApp, and XenDesktop 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 24