WHITE PAPER | Citrix XenApp 6.

5





Design and Scalability Considerations for
Enterprise XenApp Deployments


























Page 2


www.citrix.com

Contents
1.0 Introduction ........................................................................................................................................... 4
1.1 Application deployment ................................................................................................................... 4
1.2 Remote office connectivity .............................................................................................................. 5
1.3 Workforce mobility ........................................................................................................................... 5
1.4 Business continuity ........................................................................................................................... 6
2.0 Product and solution overview ............................................................................................................ 6
2.1 Citrix XenApp server ........................................................................................................................ 6
2.2 Simulated environment..................................................................................................................... 7
2.3 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 Web Interface configuration .......................................................................................................... 23
2.5 Worker group configuration .......................................................................................................... 24
2.6 Citrix policy configuration ............................................................................................................. 32
3.0 Performance results and analysis ....................................................................................................... 36
3.1 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 3
3.2.1 Data collector performance ........................................................................................................... 41
3.2.2 Data collector bandwidth ............................................................................................................... 44
3.2.3 Data store performance .................................................................................................................. 44
3.3 Worker Groups ............................................................................................................................... 46
4.0 Test environment ................................................................................................................................ 47
4.1 Hardware and software configuration .......................................................................................... 47
Server configuration..................................................................................................................................... 47
XenApp farm properties ............................................................................................................................. 48
5.0 Conclusion ............................................................................................................................................ 48



Page 4
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 real-
time 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 5
1.2 Remote office connectivity
Designing an infrastructure that effectively and efficiently supports remote office
connectivity can be an overwhelming task. Most infrastructures consist of offices and remote
locations and, it is equally important to account for the needs of those users through the
variety of supported applications, the diverse network environments and assorted user
devices. Integrating new branch offices and supporting mergers and acquisitions with
disparate systems and resources brings additional complexity and challenges. Providing a
high level of support to these remote workers is critical to keep employee productivity and
satisfaction high. XenApp simplifies these requirements thorough its inherent ability to
streamline the secure deployment and maintenance of applications and information to
remote offices, over any network and device.
XenApp 6.5 provides the ability to:
o configure, manage, and enable application access from one centralized location,
reducing the cost of provisioning branch offices individually
o improve time-to-value for business expansion with accelerated delivery of ERP,
CRM, SFA, and office productivity applications
o eliminate the need to dispatch IT staff to service remote locations with centralized
applications management
o use the Internet to deploy applications securely with less bandwidth at lower
telecommunication and network costs
o enhance customer service with centralized business-critical databases
o protect data with a built-in disaster recovery system, and help eliminate costly
downtime
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 6
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.

2.0 Product and solution overview
2.1 Citrix XenApp server
XenApp is the most commonly adopted and deployed technology for centrally managing
heterogeneous applications and delivering their functionality as a service to the workforce.
XenApp server is certified for Microsoft Windows 2008 R2 Server, and supports virtually

Page 7
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 8
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 9
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.
2.3.1 Data store
The data store is a central repository for all of the static information for the XenApp
farm. This includes items like configurations, published applications, worker groups
and load evaluators. Each XenApp server maintains a constant connection to the
database server hosting the data store. During server startup, the IMA Service
queries the data store for initialization. This is the most CPU-intensive action for the
data store, as the IMA Service initialization process ensures the local host cache
(LHC) is consistent with the data store. When multiple servers are booted, multiple
requests for initialization information are made to the data store at the same time.
During normal farm operation, the data store is accessed every 30 minutes by each
server to ensure their local host cache is current. The data store is also accessed if
the farm configuration is modified or static information is requested by tools such as
the Citrix AppCenter Console or other Citrix query-based utilities. However, the
data store is not accessed when a user logs in, disconnects, or reconnects to the
farm. All the information needed for a client to establish a connection to a XenApp
server is stored in the LHC.

How much storage is needed for the data store?
In order to estimate the storage requirements to satisfy the XYZ Corporation, it is
important to have a clear understanding as to how much disk space is consumed for
some common XenApp objects. This will aid in the determination of the initial size
of the IMA data store to reduce the frequency of database file size increases once
the farm is configured. This estimate is crucial because by reducing the frequency of
database file size increases, the performance of the IMA data store database will be
stabilized.
XenApp object Size Estimate (KB)
Initial farm creation 1184
Add one server to the farm 88
Application publication
o 10 hosting servers
o 500 users
o default icon
296

Page 10
Application publication
o 10 hosting servers
o 5 user groups
o default icon
40
Application publication
o 32-bit color icon
24
Application publication
o 256-bit color icon
48
Create one worker group 2
Create one load evaluator 8
Apply the load evaluator
o 10 servers
16
Table 1 XenApp common object sizes
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.
What type of database should be used to host the data store?
To accommodate a farm of this scale, an enterprise-capable database server should
be selected. The database selection should be made based on administrative
expertise among the existing farm administrators. The XYZ Corporation will deploy
the XenApp environment utilizing Microsoft SQL Server 2008 R2. The database
selected will match the expertise provided by the IT organization. Since XYZ
Corporation utilizes Microsoft technology for their infrastructure, SQL Server was
selected for implementation. However, if the company had Oracle database
expertise, Oracle could have been used for the deployment.
What type of hardware is needed to support 1,000 servers?
The database server should be dedicated to the data store, and should not be used
for any other applications. The processing power of the database server determines
the speed of administrative activities such as:
o starting IMA Service
o enumerating servers via the Citrix AppCenter Console
o adding a published application
XenApp 6.5 can efficiently handle up to 1,000 servers using Intel Pentium 4 class
dual processor database servers.

Page 11
The SQL database server for XYZ Corporation has Intel Xeon E5310 Quad-Core
1.6 GHz Processor and 16GB memory.
Optimizing your data store performance with Session-only mode
XenApp 6.5 introduces a new model for XenApp servers, referred to as Session-
only mode to help improve on IMA and data store performance during farm joins
and Local Host Cache (LHC) synchronization. Session-only mode is targeted to
assist in fast server provisioning and cloud-burst scenarios where servers need to be
brought online quickly for expanding farm capacity. While not concerned with the
runtime data of the entire farm, servers running in Session-only mode act as
workers and are strictly dedicated for hosting XenApp sessions only. With new
optimizations, during a join farm, IMA creates fewer objects to the data store,
resulting in fewer database transactions. The downloaded LHC is limited to only
their instance and does not contain the data of the rest of the farm. In return, these
save on roundtrips to the data store resulting in faster IMA start times and reduced
bandwidth. These savings are crucial for servers joining over a WAN or
synchronizing the LHC for a single or simultaneous set of XenApp servers.
Servers running in Session-only mode:
o Primarily host XenApp sessions
o Allows member servers to quickly join a farm or synchronize the LHC from
the data store
o Cannot be used as data collectors or back-up data collectors
o Cannot participate in the data collector election process
o Do not run the XML service, therefore cannot be used by Web Interface for
application enumeration
o Cannot be used to run management tasks such as discovery or Citrix
powershell commands
By default, Session-only mode is disabled. Configuration of a XenApp server for
Session-only mode is done at the time of joining the farm. Once the server is joined
to the farm, the mode cannot be changed. The only way to change the mode of a
server is to leave and re-join the farm.
For the XYZ Corporation, each zone will have at least 2 dedicated servers, also
known as Controllers, reserved for the data collector and back-up data collector,
while the remaining member servers will be configured in Session-only mode to
speed up the IMA start times and to reduce the amount of bandwidth when
communicating with the data store.


Page 12
How should the data store be deployed?
In previous releases of XenApp, database replication was often deployed in large,
enterprise deployments to decrease network traffic across the WAN and improve on
IMA performance. However, by designing your farms to leverage Session-only
mode, the bandwidth savings and performance improvements eliminate the need for
a dedicated SQL replica at each site. Instead, the SQL data store need only be
deployed at the main site with the other remote sites connecting to it over the WAN.
The XYZ Corporation is looking to deploy their data store at the Fort Lauderdale
site and have the Redmond member servers connect to it over the WAN. Figure 2
below illustrates the recommended data store deployment.

Figure 2 Data store infrastructure

2.3.2 Data collector
The data collector is responsible for managing all of the dynamic information in the
farm. Dynamic information consists of items that change often such as connected
sessions, disconnected sessions, and server loads. Each zone contains one data
collector. Data collectors are responsible for knowing the global state of the farm, by
maintaining the list of connected sessions, not only for their own zone, but also for
the entire farm. Since the global state of the farm is stored in the data collector, all
changes, except for load information, that are sent to a data collector in one zone are
forwarded to all other data collectors in the farm.

Page 13
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 back-
up 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.

Figure 3 Data collector infrastructure



Page 14
How many zones are needed to support 1,000 users?
The number of zones required for a farm is dependent on the topology of the site in
which the farm is being deployed.
A quick analysis of the number of servers at each site will help in the determination
of the optimal configuration for combining sites into zones. Having sufficient
network support to maintain the data collector replication is pertinent to the
performance of the farm. If bandwidth and network reliability are a concern, a hub
and spoke architecture can be used.
For optimal performance, it is best to keep the number of zones in a large enterprise
farm below 5 zones. This can best be accomplished using the hub and spoke design
as shown in Figure 3. Otherwise multi-zone farm should be considered.
Figure 4 outlines key decision points when architecting the zone design based on
the topology of the infrastructure.

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 15
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 16

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.
Is a backup data collector needed for this farm?
It is recommended to have a second XenApp Controller in your zone to act as a
BDC (Backup Data Collector), in case the primary DC goes down. Similarly, for
each site in your environment, you should have at least one XenApp controller in
the case the link between the sites fails. The XenApp controller will then assume the
role of the DC for that zone. When the link is restored, the sites will converge back
to a single Data Collector, based on the highest election preference.

Page 17
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.
What type of hardware is recommended for the data collector?
The data collectors store all dynamic information in memory; therefore, it is
important that the data collector has enough RAM to store all of the records.
Memory usage will vary based on the number of published applications, number of
servers and number of user sessions in the farm. The CPU plays an important role in
determining the number of resolutions the data collector can process in conjunction
with managing dynamic information. The data collectors for the XYZ Corporation
are built using a server with an Intel Xeon X3360 Quad-Core 2.83 GHz processor
with 4GB of memory.
Figure 7 displays the published application memory usage on the data collector. An
application with 32-bit application icon consumes about 65KB of memory.

Figure 7 IMA memory consumption for number of applications


Page 18
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 19
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.

2.3.3 XML server
The XML service is a component of XenApp that runs on all XenApp servers not
configured in Session-only mode. The XML service communicates published
application information to servers running the Web Interface. When a user connects
and logs on to Web Interface server, they will be presented with a list of published
applications in the web browser as provided by the XML service. When the user
selects one of the published applications, the XML service will then respond with
the address of a server on which the application is published.
Is a dedicated server needed for the XML server?
The XML Service must contact the data collectors when enumerating and resolving
published applications. To reduce this network communication, the XML service
should be configured on the data collector. In the event the primary data collector,
and thus XML server go offline, a backup XML server should also be configured.
For XYZ Corporation, the XML service was placed on each of the data collectors,
and the backup XML service was placed on the backup data collectors for each
zone.
Additionally, the Web Interface site can be configured to allow for XML load
balancing in which multiple XML servers will be used for enumeration to offset any
load being put on the XML service.
Remember, the XML Server cannot be a XenApp server running in Session-only
mode. The XML service only runs on XenApp Controllers. Based on your
environment, you may consider dedicating a XenApp Controller server to service
XML requests from Web Interface.
2.3.4 License server
The license server is responsible for storing and managing Citrix licenses. The first
time a client device connects to a XenApp server, the XenApp server will check out
a license from the license server on behalf of the client device. Subsequent
connections from the same client device share the same license.

Page 20

Figure 10 License server infrastructure
How many license servers are necessary?
A single license server can adequately handle the load placed on it by a thousand
servers and tens of thousands of users. Multiple license servers can also be deployed
for a single farm. However, the drawback to having multiple license servers is that
licenses are not shared between license servers.
Where in the farm should the license server be located?
The license server should be placed at the site that hosts the most users. Whenever a
client connects to a XenApp server, a connection license is retrieved from the license
server. Figure 10 shows that a single license server has been placed in the FTL zone,
the Citrix XenApp Servers in the Redmond data center need to request licenses
across the WAN.
What type of hardware is recommended for the license server?
One of the most important considerations in determining license server
requirements is the processor speed of the hardware running the license server.
Although CPU usage is not usually high, CPU time increases as license check-out
requests are made and License Management Console activity increases. The time it
takes to execute these transactions is dependent on the speed of the CPU. In

Page 21
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.
How much bandwidth is used during license consumption?
The following describes the communication paths between the XenApp server and
the license server and the associated bandwidth utilization.
o When a XenApp server is brought online, it establishes a static connection to
the license server and checks out a Citrix startup license. This action
consumes 1.68 KB of bandwidth and occurs for every server in the farm.
Once a startup license is checked out, the server holds this license until it is
taken offline or the license server location is changed.
o When a client logs in, the XenApp server requests a license from the license
server on behalf of the client. The amount of bandwidth consumed for a
license check-out request or check-in request is 1.04 KB.
o Every 5 minutes, each XenApp server exchanges a heartbeat with the license
server to determine if the license server is still available. The amount of
bandwidth in this transaction is 366 bytes for each server. The timing of the
heartbeat is based on the start time of the IMA Service.
Therefore, when deploying a license server, it is important to know and understand
the communication paths and bandwidth costs associated with licensing, especially
when communication is over a WAN.
Is the license server a single point of failure?
If a XenApp server cannot contact the license server, the servers enter into a grace
period and will allow user connections for 720 hours. After the 720 hour grace
period expires, and the XenApp server still has been unable to contact the license

Page 22
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.
2.3.5 Citrix AppCenter Console
The Citrix AppCenter Console, as shown in Figure 11, provides XenApp
administrators the ability to manage users, published applications, create worker
groups, and perform a variety of other tasks associated to the XenApp farm from a
common user interface. The console gathers farm information from two main
sources:
o the data store is used to collect static information
o the data collector is queried to assemble dynamic information, such as user
sessions

Figure 11 Citrix AppCenter Console



Page 23
How should the farm be managed from remote locations?
The Citrix AppCenter console can be run from a XenApp server in the farm or
from a standalone computer running either Windows 2003, Windows 2008,
Windows 2008 R2, Windows 7 or Windows Vista. If administrator would like to
administer the farm from a remote location, it is a best practice to configure the
Citrix AppCenter Console as a published application or remotely to a server running
local to the location of the data store. By connecting to the console through an ICA
session, the static and dynamic information is queried from the data store locally,
dramatically increasing the performance of the console. This is particularly useful in
larger server farms where the data store contains larger amounts of objects.
In the XYZ Corporation, the AppCenter console should be published on one of the
XenApp servers in the Fort Lauderdale zone and remote administrators from the
Redmond offices should access the console over a published ICA session.
Can the AppCenter Console accommodate a hybrid administration
model?
The XYZ Corporation uses a hybrid administration model. Basically, various
XenApp administrators have specific delegated authority on the XenApp farm.
Administrators in Fort Lauderdale manage farm infrastructure settings for all
servers. The administrators local to the site handle the day-to-day server operations
and maintenance. Delegated administration is then used to set granular permissions
at the folder level in the Citrix AppCenter Console. For the purposes of the XYZ
Corporation, servers are placed in folders based on the site in which they reside (i.e.,
all Fort Lauderdale servers are placed in the Fort Lauderdale folder and all
Redmond servers are placed in the Redmond folder). Redmond administrators are
allowed custom permissions to administer all servers in the Redmond folder with the
exception of the infrastructure settings. Helpdesk administrators only need the
ability to manage sessions for the farm, so they are granted view-only permissions
for all nodes except the ones allowing session management.
2.4 Web Interface configuration
Web Interface is an application deployment system that provides users with access to
XenApp applications through a standard Web browser. The Web Interface employs
Java and .NET technology executed on a Web server to dynamically create an
HTML depiction of published applications for users. Each user is presented with all
the applications published in the server farm for that user. Web Interface enables
centralized application management capabilities and complete control over the
application deployment process. Standalone Web sites for application access can be
created and integrated into the enterprises existing corporate portal.

Page 24
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 requests / second User scalability
Windows Server 2008 R2 / IIS7 9.2 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 Worker group configuration
The use of worker groups adds powerful administration capabilities for XenApp
administrators and can easily integrate with Active Directory (AD). All user and
server settings can be managed through AD policies, while applications and load
balancing can be managed through a container known as a worker group.
A worker group is simply a collection of XenApp servers in the same farm. Worker
groups allow a set of similar servers to be grouped together and managed as one.
Worker groups are closely related to the concept of application silos however, they
streamline the creation of application silos by providing a way to synchronize the
published applications and server settings across a set of XenApp servers.
Workers groups and the integration with Active Directory greatly simplify farm
management by streamlining application publishing, providing granular control of
load balancing, and allow management of server settings across different groups of
servers in the farm.

Page 25

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 26
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 27
Figure 14 Worker group layout
Worker Group Organizational Units
Apps\Business Essential Apps
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
Apps\Engineering Apps
OU=Engineering Apps, OU=Redmond, OU= XenApp,
DC=XYZCorp

OU=Engineering Apps, OU= Ft Lauderdale, OU= XenApp,
DC=XYZCorp
Apps\Financial Apps
OU=Financial Apps, OU=Redmond, OU= XenApp,
DC=XYZCorp

OU=Financial Apps, OU= Ft Lauderdale, OU= XenApp,
DC=XYZCorp
Sites\Ft Lauderdale\FTL
Business Essential
OU=Business Essential Apps, OU= Ft Lauderdale, OU=
XenApp, DC=XYZCorp
Sites\Ft Lauderdale\FTL
Engineering
OU=Engineering Apps, OU= Ft Lauderdale, OU= XenApp,
DC=XYZCorp
Sites\Ft Lauderdale\FTL
Financial
OU=Financial Apps, OU= Ft Lauderdale, OU= XenApp,
DC=XYZCorp
Sites\ Redmond \FTL Business
Essential
OU=Business Essential Apps, OU=Redmond, OU=
XenApp, DC=XYZCorp
Sites\ Redmond \FTL
Engineering
OU=Engineering Apps, OU=Redmond, OU= XenApp,
DC=XYZCorp
Sites\Redmond\FTL Financial
OU=Financial Apps, OU=Redmond, OU= XenApp,
DC=XYZCorp
Sites\San Francisco\FTL
Business Essential
OU=Business Essential Apps, OU=San Francisco, OU=
XenApp, DC=XYZCorp
Table 3 Worker group structure

Page 28
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 29

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.
Load balancing based on worker groups
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. In many
circumstances, this change eliminates the need to publish multiple copies of the
same application.
At XYZ Corporation, the administrators created three worker groups specifically for
publishing applications: the Business Essential Apps, Engineering Apps and
Financial Apps worker groups. The administrators configured the Business Essential
Apps worker group to contain all the servers from the Business Essential,
engineering and financial silos. With previous releases of XenApp, the
administrators would have had to publish separate copies of all Business Essential
applications, one for the engineering users , one for financial user and another one
for all others, because the users use different servers. However, with XenApp 6.5,
the administrators can publish the Business Essential apps to all servers and use load
balancing policies to direct users appropriately.

Page 30
Application Server Users
Business Essential
Applications
Worker
Groups\Apps\Business
Essentials Apps
XYZCorp\All
Employees
Engineering
Applications
Worker
Groups\Apps\Engineering
Apps
XYZCorp\Engineers
Financial Applications 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 31
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 Priority Policy Filter Worker Group Preference
FTL ENG 1 Client IP: 10.8.0.0/16
User:
XYZCorp\Engineer
1. FTL - Engineering
2. RED - Engineering
RED ENG 2 Client IP: 172.16.0.0/8
User:
1. RED Engineering
2. FTL - Engineering

Page 32
XYZCorp\Engineer
FTL FINANCE 3 Client IP: 10.8.0.0/16
User: XYZCorp\Finance
1. FTL Finance
2. RED - Finance
RED FINANCE 4 Client IP: 172.16.0.0/8
User: XYZCorp\Finance
1. RED Finance
2. FTL - Finance
FTL BUSINESS 5 Client IP: 10.8.0.0/16 1. FTL Business Essential
2. RED Business Essential
3. SF Business Essential
RED
BUSINESS
6 Client IP: 172.16.0.0/8 1. RED Business Essential
2. SF Business Essential
3. FTL Business Essential
SF BUSINESS 7 Client IP: 10.1.0.0/16 1. SF Business Essential
2. RED Business Essential
3. 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 non-
engineering 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.
Citrix policy filters
All Citrix server policies can be filtered by worker groups, which allow
administrators to restrict GPOs to a specific set of servers in the farm. For policies
configured in the AppCenter Console, this is the only way to assign different settings
to different groups of servers, since all policies are replicated to all servers,
completely independent of AD.
Since XYZ Corporation administrators have control over their XenApp OU, they
use AD GPOs to manage the settings in the 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.
2.6 Citrix policy configuration
Nearly all server, farm, and user settings are governed by Citrix group policies, which can be
configured in three different ways:

Page 33
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. Policy created at the Default Domain Policy
2. Policy created at the top OU level
3. Policy created at the middle level OU
4. Policy created at lowest level OU

Page 34

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.
Policy refresh interval
It is very important to understand how the configured policies are refreshed and
applied to the XenApp server. This can help the Citrix administrator to troubleshoot
the policy related issues.
When Citrix policies are managed from the AD domain group policy, the sequence
of policy refresh and update is as follows:
1. change is made on the GPMC
2. within 1 to 2 hours, member servers pull and apply updates
3. every 3 hours, AD replication occurs between domain controllers
4. within 1 to 2 hours, remote member servers pull and apply updates

Page 35

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. change is made in AppCenter Console
2. member server writes the policy change to the DS and updates its LHC
3. all servers pull policy information from the DS and updates their LHCs
4. 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 36
3.0 Performance results and analysis
In determining the scalability of XenApp, two items were taken into consideration: farm
scalability and single server scalability. Farm scalability determines the number of XenApp
servers that can perform successfully together in a given environment. Farm scalability is
determined by components like load balancing, manageability of the server farm, and data
store load. Single server scalability measures the number of users that can be loaded onto a
single server with acceptable performance.
This section outlines the results from the 1000-server farm simulated for XYZ Corporation.
After the farm was designed and deployed, the farm was loaded with thousands of client
sessions to exercise the infrastructure well above the service level agreements of the most
demanding environments.
3.1 Farm environment
3.1.1 Network configuration
Simulation of the XYZ Corporation environment required that two data centers
which were at opposite ends of the country be configured using the Shunra Storm
WAN Emulator. Half of the servers in the farm were placed on a 172.16.x.x
network while the other half of servers was placed on a 10.8.x.x network. All traffic
between the networks went through the Shunra appliance. The WAN emulator was
configured to apply 200ms round trip latency. The throughput was set to 10 Mbps.
3.1.2 Farm-wide IMA bandwidth consumption
Analysis of the IMA service communication in the XenApp farm will help XYZ
Corporation understand the bandwidth requirements needs, especially when it
comes to the WAN link that connects the two data center.
The following diagrams show the IMA communication bandwidth consumption in
four typical scenarios:
o XenApp startup
o farm is in an idle state
o user launch a session
o a DC election happens


Page 37
IMA Communication - XenApp Startup

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 38
IMA Communication Idle Farm

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 39
IMA Communication User Connection

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 40
IMA Communication DC election

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 41
3.2 XenApp performance results
3.2.1 Data collector performance
During the simulation, 10,000 unique static users were connected to the farm,
shown in the figure below, while other users were dynamically logging on and off at
a rate of 1300 users per minute in the Fort Lauderdale zone. This data was derived
from the application resolutions/second in the second graph below, which shows an
average of 22 resolutions per second.
Static Users Load onto the Farm

Figure 25 User sessions for simulation


Page 42
FTL Zone Data Collector Application Resolutions/Second

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 43
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 28 Data collector failover performance

Page 44
3.2.2 Data collector bandwidth
The bandwidth usage during the logon/logoff stress between the Fort Lauderdale
and Redmond data collectors can be seen in Figure 29. As shown by the graph, the
bandwidth usage averages around 500 KBps, while logging in 1,300 users per minute
to the Fort Lauderdale zone. If the Fort Lauderdale data collector and Redmond
data collector were each handling 1,300 users per minute then the bandwidth usage
would double to 1,000 KBps. Although XYZ Corporation has a 10 Mbps WAN link
between the two data centers, the IMA service will only utilize a small piece of the
available bandwidth.
FTL Zone Data Collector IMA Bandwidth between Data Collectors

Figure 29 IMA bandwidth between the FTL and RED data collectors

3.2.3 Data store performance
XenApp servers configured in Session-only mode consume considerably less
bandwidth when communicating with the Data Store than in previous XenApp
releases. Citrix eLabs ran a series of tests to measure the IMA bandwidth usage and
start times. The figure below illustrates the bandwidth usage of the IMA service
communicating to the Data Store on a single server during start time.

Page 45

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.

Figure 30 single server IMA start time performance

Page 46
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.
Figure 31 SQL data store transactions during IMA operations

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 47
4.0 Test environment
This report documents the architecture, design, and deployment of 1,000 XenApp servers
running the Platinum edition in a single, distributed farm. The infrastructure described in
this document was built using Citrix eLabs.
4.1 Hardware and software configuration
Server configuration
Table 6 outlines the hardware details for the systems deployed for the simulation described
in this report.
Function Machine Processor Memory Notes
XenApp server
Data Store1 HP DL360
Quad-Core 1.6
GHz Xeon E5310
16 GB SQL Data Store
Data Collector1 IBM x3250
Quad-Core 2.83
GHz Xeon X3360
4 GB DC for FTL zone
Data Collector2 IBM x3250
Quad-Core 2.83
GHz Xeon X3360
4 GB DC for RED zone
License Server IBM x3250
Quad-Core 2.83
GHz Xeon X3360
4 GB
Backup Data
Collector1
IBM x3250
Quad-Core 2.83
GHz Xeon X3360
4 GB
Backup DC for FTL
zone
Backup Data
Collector2
IBM x3250
Quad-Core 2.83
GHz Xeon X3360
4 GB
Backup DC for RED
zone
XML Server1 IBM x3250
Quad-Core 2.83
GHz Xeon X3360
4 GB
Shared with Data
Collector1
XML Server2 IBM x3250
Quad-Core 2.83
GHz Xeon X3360
4 GB Shared with BDC1
Backup XML Server1 IBM x3250
Quad-Core 2.83
GHz Xeon X3360
4 GB
Shared with Data
Collector2
Backup XML Server2 IBM x3250
Quad-Core 2.83
GHz Xeon X3360
4 GB Shared with BDC2
Member Server1
(200)
IBM x3250
Quad-Core 2.83
GHz Xeon X3360
4 GB
Member Server2 (90) DELL 1850
Dual 2.8 GHz
Xeon E5520 with
HT
2 GB
Member Server3
(110)
HP DL1000
Dual-Quad 2.27
GHz E5520
4 GB
Member Server4 XenServer VM 2 vCPU 1.5 GB

Page 48
(600)
Web Interface
Web Interface (4) IBM x3250
Quad-Core 2.83
GHz Xeon X3360
2 GB
Table 6 Server configuration
XenApp farm properties
Table 7 displays the summation of the configuration for the farm that use used to simulate
the business requirements for this document.
Farm object Quantity
Servers 1000
Server folders 50
Published applications 2000
Application folders 50
Citrix administrators 10
Load evaluators 10
Print drivers 30
Printer queues 5
Table 7 Farm properties
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 49













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.