scaling big - daas saas deployments for citrix service providers_1108
TRANSCRIPT
-
8/3/2019 Scaling Big - DaaS SaaS Deployments for Citrix Service Providers_1108
1/35
WHITE PAPER | Citrix XenApp 6
www.citrix.com
S caling B ig DaaS and S aaS
Deployments for C itrix S ervice P rovide
Scaling to 1,000 servers in a single farm
-
8/3/2019 Scaling Big - DaaS SaaS Deployments for Citrix Service Providers_1108
2/35
Page 2
Contents
1.0 Introduction ........................................................................................................................................... 3
1.1 Citrix Service Provider Reference Architecture ............................................................................................ 4
2.0 Product and Solution Overview .......................................................................................................... 5
2.1 Citrix XenApp 6 ............................................................................................................................................. 5
2.2 XenApp simulated environment .................................................................................................................. 5
2.3 XenApp configuration .................................................................................................................................. 5
2.3.1 Data Store (DS) ............................................................................................................................................. 6
2.3.2 Data Collector (DC) ....................................................................................................................................... 8
2.3.3 XML server ................................................................................................................................................. 12
2.3.4 License server ............................................................................................................................................. 13
2.3.5 Delivery Services Console (DSC) ................................................................................................................. 16
2.4 Web Interface configuration ...................................................................................................................... 17
2.5 Worker Group configuration ...................................................................................................................... 17
2.6 Citrix policy configuration .......................................................................................................................... 21
3.0 Scalability Results and Analysis ......................................................................................................... 25
3.1 Farm environment ..................................................................................................................................... 25
3.1.1 Network configuration ............................................................................................................................... 25
3.1.2 Farm-wide IMA bandwidth consumption .................................................................................................. 25
3.2 XenApp performance results ..................................................................................................................... 30
3.2.1 Data collector performance ....................................................................................................................... 30
3.2.2 Data store performance ............................................................................................................................. 31
3.3 Worker Groups ........................................................................................................................................... 32
3.4 Citrix farm policies and bandwidth ............................................................................................................ 32
4.0 Conclusion ............................................................................................................................................ 34
-
8/3/2019 Scaling Big - DaaS SaaS Deployments for Citrix Service Providers_1108
3/35
Page 3
1.0 Introduction
XenApp is an on-demand application delivery solution that enables any Windows
application to be virtualized, centralized and managed in the datacenter and instantly
delivered as a service to users anywhere on any device. This means subscribers can use
whatever device they chooselaptop, tablet, smartphonebut still access familiar Windows
desktops and business applications that the service provider manages. XenApp enables
service providers to centrally manage a single instance of each application and deliver it to
users for online and offline use, providing a high-definition experience. It delivers 99.999
percent application availability and is proven with 25 million applications in production and
over 100 million users worldwide.
Citrix XenApp 6 introduces exciting new enhancements for 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 providessession and application virtualization technologies that make it easy for service providers to
centrally manage applications using any combination of local and hosted delivery to best fit
their unique requirements.
This whitepaper examines the architecture and design of the Citrix XenApp solution and its
ability to provide a scalable and high availability infrastructure while delivering on-demand
access to applications (SaaS) and desktops (DaaS) from the cloud.
-
8/3/2019 Scaling Big - DaaS SaaS Deployments for Citrix Service Providers_1108
4/35
Page 4
1.1 Citrix Service Provider Reference Architecture
The Citrix Service Provider Reference Architecture model describes the complete solution
available to service providers for delivering a bundle of applications, desktops and services tosubscribers in SaaS and DaaS models. For more information regarding the CSP Reference
Architecture seehttp://www.citrix.com/skb/articles/RDY2524.
Figure 1 - CSP Architecture
1.2 Multi-tenant SaaS/DaaSThe multi-tenant SaaS/DaaS module comprises four sub-components:
1. Windows applications and desktops
2. Web-based SaaS
3. Back-office SaaS
4. Third-party SaaS
This module is the core component of the service provider datacenter(s) it enables multi-tenant delivery of virtual applications (SaaS) and desktops (DaaS). Within this module,
applications and desktops are virtualized, and subscriber partitions and Active Directory
boundaries are defined, which are centrally governed by XenApp systems.
Windows desktops and applications are powered by XenApp, enabling service providers to
deliver any applicationWindows, Web, SaaS, back office or third-partyto their
subscribers.
http://www.citrix.com/skb/articles/RDY2524http://www.citrix.com/skb/articles/RDY2524http://www.citrix.com/skb/articles/RDY2524http://www.citrix.com/skb/articles/RDY2524 -
8/3/2019 Scaling Big - DaaS SaaS Deployments for Citrix Service Providers_1108
5/35
Page 5
2.0 Product and Solution Overview
2.1 Citrix XenApp 6
XenApp is the most commonly adapted and deployed technology for centrally
managing applications and delivering their functionality as a service. XenApp 6 is
certified for Microsoft Windows 2008 R2 Server, and supports virtually any custom
or commercially packaged Windows or Web application. XenApp provides an
exceptional foundation to build highly scalable, secure, manageable access solutions
that reduce computing costs and increase the utility of any information system.
XenApp 6 introduces significant enhancements that simplify application
management and bring unprecedented levels of scalability that increase cost savings
and datacenter efficiency. For detailed steps on installing XenApp 6 for Windows
Server 2008 R2 please visit
http://support.citrix.com/proddocs/index.jsp?topic=/xenapp/xenapp6-w2k8-
wrapper.html.2.2 XenApp simulated environment
CSP Corporation is a fictional company used for illustrative purposes.
CSP Corporation is in the process of identifying a solution that will satisfy the
requirements of offering dedicated and secure Windows-based applications anddesktops as a service.
To achieve this goal, Citrix products will be introduced to maximize the efforts of
the company. The data compiled in this whitepaper are the results of real-time
simulations and provide the reference used to satisfy CSP Corporations
infrastructure requirements with scalable, secure and reliable Citrix solutions.
2.3 XenApp configuration
A review of the primary components of the XenApp farm and its architectural
design is outlined below with details about each components role in the architectedsolution.
http://support.citrix.com/proddocs/index.jsp?topic=/xenapp/xenapp6-w2k8-wrapper.htmlhttp://support.citrix.com/proddocs/index.jsp?topic=/xenapp/xenapp6-w2k8-wrapper.htmlhttp://support.citrix.com/proddocs/index.jsp?topic=/xenapp/xenapp6-w2k8-wrapper.htmlhttp://support.citrix.com/proddocs/index.jsp?topic=/xenapp/xenapp6-w2k8-wrapper.htmlhttp://support.citrix.com/proddocs/index.jsp?topic=/xenapp/xenapp6-w2k8-wrapper.html -
8/3/2019 Scaling Big - DaaS SaaS Deployments for Citrix Service Providers_1108
6/35
Page 6
Figure 2 - XenApp infrastructure components
2.3.1 Data Store (DS)
The data store is a central repository for all of the configuration information for the
XenApp farm. This includes items like published applications, worker groups andload evaluators. During server startup, the IMA Service queries the data store for
initialization information. 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 its LHC is current. The data store is also accessed if the farm
configuration is modified or static information is requested by tools such as the
Delivery Service Console (DSC) or other Citrix query-based utilities. However, thedata 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, with the exception of licensing details.
Figure 3 - Data store infrastructure
-
8/3/2019 Scaling Big - DaaS SaaS Deployments for Citrix Service Providers_1108
7/35
Page 7
To estimate the database storage requirements, it is necessary to be aware of the
amount of disk space that common XenApp objects consume. This helps with
estimating the initial size of the database which, in turn, reduces the frequency of
database file size increases as new objects are created. This estimate is important
because minimizing database file size increases stabilizes the performance of the data
store.
How much storage is needed for the data store database?
XenApp object Size (KB)
Initial farm creation 1264
Add one server to the farm 67
Application publicationo 10 hosting servers
o 500 users
o default icon
168
Application publication
o 10 hosting servers
o 5 user groups
o default icon
24
Application publication
o 32-bit color icon
48
Application publicationo 256-bit color icon
408
Create one worker group 2
Create one load evaluator 8
Apply the load evaluator
o 10 servers
16
Table 1 - XenApp common object sizes
Given CSP Corporations goal, an environment consisting of 1,000 hosted or
streamed applications with high resolution icons (256-bit), 100 worker groups to
serve as tenant silos, and 10 load evaluators, will require an IMA data store ofapproximately 500MB.
To accommodate a farm of this scale, an enterprise-capable database server should
be selected. The database selection should be made based on expertise among farm
administrators. Based on the environment described above and on current in-house
What type of database should be used to host the data store?
-
8/3/2019 Scaling Big - DaaS SaaS Deployments for Citrix Service Providers_1108
8/35
Page 8
expertise, CSP Corporation will deploy the XenApp environment utilizing Microsoft
SQL Server 2008. However, if the company had Oracle database expertise, Oracle
could have been used for the deployment.
For 1,000 servers in a single XenApp farm, it is recommended that a database server
with an Intel Xeon class or better quad-core processor be dedicated to hosting
the data store.. The processing power of the database server determines the speed of
administrative activities such as:
What type of hardware is needed to support 1,000 servers?
o starting the IMA Service
o enumerating servers via the Delivery Services Console
o adding a published application
The database server CSP Corporation selected was an Intel quad-core 1.6GHZ
processor with 4GB of RAM.
2.3.2 Data Collector (DC)
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. The data collector is responsible
for knowing the global state of the farm. The data collector also performsresolutions. A resolution is a process where, upon user request, the data collector
determines the least-loaded server that is hosting a load-balanced published
application or desktop.
Proper XenApp zone design is one of the most important steps in building a stable,
high-performing farm. For CSP Corporations purposes, a site can be associated with
a separate geographical region.
How many zones are needed to support 1,000 servers?
Figure 4 outlines key decision points when
architecting the zone design based on the topology of the infrastructure.
-
8/3/2019 Scaling Big - DaaS SaaS Deployments for Citrix Service Providers_1108
9/35
Page 9
Figure 4 - Zone design decision considerations
Consider these zone design guidelines:
Minimize the number of zones in your farm. The fewer zones in a farm, themore scalable the farm. Every time a dynamic event occurs, such as a logon,logoff, or disconnect, an update is sent to the data collector. The datacollector must then forward the update to all other data collectors in thefarm, which consumes bandwidth and CPU. Data collectors must keep upwith the events in other zones as well as their own.
Create zones for major datacenters in different geographic regions.
If a site has a small number of servers, group that site in a larger sites zone.
If your organization has small sites with low bandwidth or unreliableconnectivity, do not place those sites in their own zone. Instead, group themwith other sites that have better connectivity. When combined with otherzones, this might form a hub-and-spoke zone configuration.
If you have more than five sites, group the smaller sites with the larger zones.Citrix recommends a maximum of five zones.
In the case of CSP Corporation, a single zone of 1000 servers is optimal as the
environment consists of a single site hosting all of the XenApp servers. This design
remains true regardless of how tenants are isolated at the network level. TCP port
2512 must be open to allow IMA communications to and from the member serversand data collector. As shown in Figure 4, zones should be based on physical
topology rather than on network subnets or VLANs.
-
8/3/2019 Scaling Big - DaaS SaaS Deployments for Citrix Service Providers_1108
10/35
Page 10
Figure 5 - CSP Corporation single zone design
In the case where the XenApp servers are located in different sites, the flow chartshown in Figure 3 provides guidance on the optimal zone design for that
environment.
In order to satisfy the business requirements for CSP Corporation, a dedicated
backup data collector has been installed in each zone. In the event the primary data
collector goes offline, this dedicated server is available to assume the data collector
role. If the data collector role is assumed by a server that is not dedicated to the task,
resource contention between application users and the data collector operations can
result in data collector events getting queued.
Is a backup data collector needed for this farm?
The data collector stores all dynamic information in memory; therefore, the data
collector should have 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 collector for the CSP Corporation was an Intel
Xeon 2.83 GHz quad-core processor with 4GB of memory.
What type of hardware is recommended for the data collector?
Figure 6 shows the published application memory usage on the data collector. The
average published application consumes about 39KB of memory.
-
8/3/2019 Scaling Big - DaaS SaaS Deployments for Citrix Service Providers_1108
11/35
Page 11
Figure 6 - IMA memory consumptionapplication variant
Figure 7 shows the memory usage based on the number of connected sessions. The
average session consumes about 1.52KB of memory on the data collector.
Figure 7 - IMA memory consumptionsession variant
Figure 8 references the memory usage based on varying numbers of servers. Each
server that joins a farm consumes about 329KB of memory.
-
8/3/2019 Scaling Big - DaaS SaaS Deployments for Citrix Service Providers_1108
12/35
Page 12
Figure 8 - IMA memory consumptionserver variant
For CSP Corporation, the administrators expect to host 2,000 published applications
in the 1,000 server farm. They also expect that the maximum number of user
sessions during peak hours of operation will be approximately 100,000 sessions.
Using the data from the charts above, the data collector will consume about 560MB
of memory during peak time.
Note: In a multi zone design, all data collectors in the farm should be sized toaccommodate the largest zone. Data collectors manage the global state of the
farm, so all servers acting in this role should have the same processing capability,regardless of the size of their particular zone. Likewise if the data collector forone zone is dedicated, data collectors for the other zones in the farm should bededicated as well.
2.3.3 XML server
The XML service is a component of XenApp. The XML service communicates
published application information to servers running the Web Interface. When users
connect and log on to the Web Interface server through their Web browser, they arepresented with a list of published applications and desktops as provided by the XML
service. When the user selects one of the resources, the XML service responds with
the address of a server on which the application is published.
-
8/3/2019 Scaling Big - DaaS SaaS Deployments for Citrix Service Providers_1108
13/35
Page 13
Figure 9 - XML service design
To support the burst logon requirement for the 100,000 users, CSP Corporation
configured the XML Service role on the data collector, backup data collector, and
two additional member servers. In addition, the Web Interface site was configured
to load balance requests across all servers providing the XML Service.
2.3.4 License server
The license server is responsible for storing and managing Citrix licenses. When
users connect to a XenApp server, the XenApp server checks out a license from the
license server on behalf of the client device. Subsequent connections from the same
client device share the same license.
Figure 10 illustrates various license server design considerations.
-
8/3/2019 Scaling Big - DaaS SaaS Deployments for Citrix Service Providers_1108
14/35
Page 14
Figure 10 - License server design
A single license server can adequately handle the load placed on it by a thousand
XenApp servers (single or multiple farms) 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 servers.
How many license servers are necessary?
Note: In the case where a farm spans multiple sites, the license server should beplaced at the site that hosts the most users.
One of the most important considerations in determining license server
requirements is processor speed. 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 general, the size of the farm and the number of simultaneous
client connections dictate the power of the server needed for the licensing feature.
What type of hardware is recommended for the license server?
To appropriately size the license server, determine the number of client logins per
second in the farm deployment. To do this, you can use the Performance Monitor
counters available within XenApp and the load evaluator logging feature. This
analysis determines the processor speed needed for optimal license server
performance.
Additionally, the license server process is single threaded. So, multiple processors do
not increase performance. The license server uses approximately 4.5KB of memory
-
8/3/2019 Scaling Big - DaaS SaaS Deployments for Citrix Service Providers_1108
15/35
Page 15
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 scenario where all users log in over the course of 30 minutes, a single
license server would be able to handle 446,400 users. The license server configured
for CSP Corporation is a standalone Intel Xeon 2.83 GHz quad-core processor
with 4GB of RAM.
When deploying a license server, it is important to understand the communication
paths and bandwidth costs associated with licensing, especially when communication
is over a WAN.
How much bandwidth is used during license consumption?
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.87 KBof 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.
When a user logs in, the XenApp server requests a license from the license server on
behalf of the client device. The amount of bandwidth consumed for a license check-
out request or check-in request is 0.745KB.
Every 5 minutes, each XenApp server checks to ensure the license server remains
available. The amount of bandwidth in this transaction is 416 bytes for each server.
The timing of this verification is based on the start time of the IMA Service.
If a XenApp server cannot contact the license server, the XenApp server enters a
grace period in which user connections are allowed for 720 hours. If the XenApp
server is unable to contact the license server during the grace period, connections are
denied when the grace period expires. For CSP Corporation, the 720-hour grace
period provides more than enough time for recovery in the event of a failure.
Is the license server a single point of failure?
However, for some environments, the standard grace period might not be adequate.
In such cases, a 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 to deliver hardware-based fault tolerance for the
license server. For more information on setting up the license server in a clustered
environment, refer to theCitrix Licensing sectionof Citrix eDocs.
http://support.citrix.com/proddocs/topic/licensing-1161/lic-licensing-1161.htmlhttp://support.citrix.com/proddocs/topic/licensing-1161/lic-licensing-1161.htmlhttp://support.citrix.com/proddocs/topic/licensing-1161/lic-licensing-1161.htmlhttp://support.citrix.com/proddocs/topic/licensing-1161/lic-licensing-1161.html -
8/3/2019 Scaling Big - DaaS SaaS Deployments for Citrix Service Providers_1108
16/35
Page 16
2.3.5 Delivery Services Console (DSC)
The Delivery Services Console, as shown in Figure 11, provides Citrix administrators
the ability to manage users, published applications, create worker groups, andperform a variety of other tasks associated with the XenApp farm. The console
gathers farm information from two 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 Delivery Services Console
The Delivery Services 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. To administer the farm from a
remote location, the console can be accessed as a published application. By
connecting to the console through an ICA session or through RDP, the static and
dynamic information is queried from the console locally, dramatically increasing the
performance of the console. This is particularly useful in larger server farms.
How should the farm be managed from remote locations?
-
8/3/2019 Scaling Big - DaaS SaaS Deployments for Citrix Service Providers_1108
17/35
Page 17
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. Users are presented with all the applications published in
the server farm(s) that they are permitted to use. 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.
For CSP Corporation, the Web Interface server is a 2.2 GHz Intel Xeon dual-processor
computer with 2GB of RAM. As shown in
How many Web Interface servers are needed to support 30,000 users?
Table 2, this server is able to handle 9.2 userrequests per second.
PlatformFarm
authority
User
requests / secondUser scalability
Windows Server 2008 R2 / IIS7 ADS 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 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 published applications, hosted desktops, load balancing and
farm multi-tenancy can be managed through a new container known as a worker group.
-
8/3/2019 Scaling Big - DaaS SaaS Deployments for Citrix Service Providers_1108
18/35
Page 18
Figure 12 illustrates how worker groups enable multi-tenancy in a XenApp farm.
Figure 12 - Worker groups and tenant silosA worker group is a collection of XenApp servers in the same farm, where administrators
can associate objects like published applications, published desktops, and policies. Worker
groups allow a set of similar servers to be grouped together and managed as a single entity.
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.
Worker groups are dynamic. For example, when AD containers are associated with a worker
group, changes in the AD container are automatically reflected in the server's worker group
memberships.
Servers can be added to worker groups 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.
The CSP Corporation administrators have chosen to manage their XenApp farm through
Active Directory. Figure 12 shows the Active Directory Organizational Unit (OU) structure
for the XenApp farm.
-
8/3/2019 Scaling Big - DaaS SaaS Deployments for Citrix Service Providers_1108
19/35
Page 19
Figure 13 - Active Directory Organization Unit (OU)
In anticipation of future expansion, CSP Corporation administrators created two sets of
worker groups: one set to group servers by tenant and one set to group applications by
tenant. When the administrators add capacity for an existing tenant, they do not need to
modify the servers list of published applications or desktops assigned to that tenant. Instead,
they simply add another XenApp server to the tenants OU.
Figure 14 illustrates CSP Corporations worker group structure in the DSC.
-
8/3/2019 Scaling Big - DaaS SaaS Deployments for Citrix Service Providers_1108
20/35
Page 20
Figure 14 - Worker group layout
With dynamic provisioning, this step can be automated using AD, by creating a base image
for XenApp with all of the applications installed. To add capacity, simply create a new
instance of the base image and add it to the desired tenant OU. The server receives its serversettings from AD, joins the appropriate worker groups, and begins hosting published
applications or desktops. Creating separate worker groups for desktops and applications
gives CSP Corporation the flexibility to easily expand their tenant base.
Worker Groups and Citrix policy filters
All Citrix server policies can be filtered by worker groups, which allow CSP administrators
to restrict GPOs to a specific set of servers in the farm. For policies configured in the
Delivery Services Console, this is the only way to assign different settings to different groups
of servers as all policies are replicated to all servers, completely independent of AD.
Since CSP Corporation administrators have control over their XenApp OU, they use AD
GPOs to manage the settings in the XenApp farm. For all user and site settings, they can
link the GPO to the XenApp OUs without any filters. However, if they wish to deploy a
setting specifically to Tenant1s servers or Tenant2s servers, they can add a Worker Group
filter to the policy to limit it to the appropriate tenant.
-
8/3/2019 Scaling Big - DaaS SaaS Deployments for Citrix Service Providers_1108
21/35
Page 21
2.6 Citrix policy configuration
Figure 15 - AD Group Policy vs. XenApp Farm Policy
In XenApp 6, nearly all server, farm, and user settings are governed by Citrix group policies,
which can be configured in three different ways:
1. Local Machine Policy (gpedit)
2. Active Directory Group Policy (gpmc)
3. XenApp Farm Group Policy (Policies node of the Citrix Delivery Services Console)
Local Machine Policy can be used for managing small farms, but large farms will use eitherAD or the Delivery Services Console to manage settings across multiple servers. AD offers
the most powerful solution for administrators and supports managing settings across
multiple XenApp farms. Administrators create a Group Policy Object (GPO) containing the
desired Citrix policy settings and link the GPO to the appropriate tenant OUs. However, for
Citrix administrators who do not have control over their AD environmentor whose
organizations dont use AD for directory services, XenApp 6 provides farm-based group
policies through 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.
If multiple types of policies are created, the priority of policy enforcement (from low tohigh) is as follows
o Local GPO
o Farm GPO
o Domain GPO
Based on CSP Corporations multi-tenancy requirements, the only option is to utilize
XenApps AD Group Policy option. The administrators create Citrix policies at different
-
8/3/2019 Scaling Big - DaaS SaaS Deployments for Citrix Service Providers_1108
22/35
Page 22
OU structure levels as displayed in Figure 16. 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 OU4. Policy created at lowest level OU
Figure 16 - Active Directory XenApp group policies
The XenApp General GPO was created to apply to the XenApp farm as a whole. For each
tenant, the CSP administrator creates new or links existing GPOs to the tenants OU
structure. For example, the Tenant1 GPO is a general tenant GPO that was created to applypolicies to all of Tenant1s downstream OUs. The CTXRestrictedComputer GPO is linked
to Tenant1s computer OU (Tenant1_Computers) and CTXRestrictedUser and XASession
GPOs are linked to Tenant1s user OU.
The resultant Citrix policies applied to Tenant1s computer and user OUs will be the
merged settings from all four GPOs. If there is a conflict among the policy settings of these
GPOs, the settings in the Computer and User GPOs have the highest priority and will
overwrite the settings in the Tenant1 GPO, XenApp General GPO and Domain GPO.
-
8/3/2019 Scaling Big - DaaS SaaS Deployments for Citrix Service Providers_1108
23/35
Page 23
Understanding how configured policies are refreshed and applied to the XenApp server can
help the Citrix administrator troubleshoot policy-related issues.
Policy refresh interval
When Citrix policies are managed from the AD domain group policy, the sequence of policy
refresh and update is as follows:
1. A change is made in the Group Policy Management Console (GPMC).
2. Within 1 to 2 hours, member servers pull and apply updates.
3. Every 3 hours, AD replication occurs between domain controllers.
Figure 17 - Group Policy Management refresh interval (Active Directory)
-
8/3/2019 Scaling Big - DaaS SaaS Deployments for Citrix Service Providers_1108
24/35
Page 24
When Citrix policies are managed from the Delivery Service Console, the sequence of policy
refresh and update is as follows:
1. A change is made in Delivery Service Console.
2. A member server writes the policy change to the data store and updates its LHC.
3. All farm servers pull policy information from the data store and update their LHCs.4. Within 1 to 2 hours, member servers apply updates to the registry.
Figure 18 - Group Policy Management refresh interval (DSC)
If needed, the IMA service can be restarted to refresh computer policies immediately. User
policies are refreshed when users logon or reconnect.. The gpupdate /force command can
be executed to force the policy synchronization and update.
-
8/3/2019 Scaling Big - DaaS SaaS Deployments for Citrix Service Providers_1108
25/35
Page 25
3.0 Scalability Results and Analysis
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.
After the farm for CSP Corporation 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
CSP Corporation currently has multiple, geographically diverse data centers with the
capacity to support thousands of servers. For the purpose of this simulation a singledata center was utilized to deploy the XenApp environment.
Within the data center, the XenApp servers were segmented into tenants utilizing
internally assigned VLANs. All traffic between the networks was routed through a
Layer3 switch, taking advantage of access policies for individual tenant security.
3.1.2 Farm-wide IMA bandwidth consumption
Analysis of the IMA service communication in the XenApp farm helps CSP
Corporation understand the bandwidth requirements needs.
The following diagrams show the IMA communication bandwidth consumption in
four typical scenarios:
o XenApp startup
o Farm in an idle state
o User launching a session
o Election of a data collector
-
8/3/2019 Scaling Big - DaaS SaaS Deployments for Citrix Service Providers_1108
26/35
Page 26
IMA Communication - XenApp Startup
Figure 19 - 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 the IMA
Service. Next, the servers check out a server license from the license server. Thisallows 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, the server
can still grant grace period licenses. Next, the servers that provide access to
applications and desktops register with the data collector.
-
8/3/2019 Scaling Big - DaaS SaaS Deployments for Citrix Service Providers_1108
27/35
Page 27
IMA Communication Idle Farm
Figure 20 - IMA bandwidth consumption Idle Farm
After the XenApp server starts, the local host cache performs a consistency check
every 30 minutes 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 sends an IMAPing to ensure the server is still available. Also, every
five minutes plus some randomized interval, the XenApp servers contact the license
server to ensure it is still available.
-
8/3/2019 Scaling Big - DaaS SaaS Deployments for Citrix Service Providers_1108
28/35
Page 28
IMA Communication User Connection
Figure 21 - IMA bandwidth consumption user connectionIn this case, a user wants to connect to an application or desktop using Citrix
Receiver or Web Interface. The data collector performs the resolution and directs
the client device to connect to the least loaded server. When the user connects, the
XenApp server contacts the license server to check out a concurrent license on
behalf of the user. Once the user is connected, 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 then updates the data collector with this information.
-
8/3/2019 Scaling Big - DaaS SaaS Deployments for Citrix Service Providers_1108
29/35
Page 29
IMA Communication data collector election
Figure 22 - IMA bandwidth consumption new data collector electionIn the event that the data collector in Zone1 has a failure, the member servers
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 rebuild all of their dynamic tables with the new data collector. Although
the original data collector went down, the user connection that was established in
Figure 21is unaffected. Once the resolution process is complete, the data collector
will only passively track the session.
-
8/3/2019 Scaling Big - DaaS SaaS Deployments for Citrix Service Providers_1108
30/35
Page 30
3.2 XenApp performance results
3.2.1 Data collector performance
During the simulation, 10,000 unique static users were connected to the farm, while
other users were dynamically logging on and off at a rate of 1,300 users per minute.
Figure 23 shows a snapshot of the data collectors application resolutions rate, an
average of 22 resolutions per second.
Data Collector Application Resolutions/Second
Figure 23 - Data collector application resolution per second
At this rate, the data collector would be able to handle 30,000 user logons in less
than 25 minutes while the CPU usage is only about 45%. If the logon rate is
increased to consume 90% of the data collectors CPU, the farm would be able to
log on 60,000 users in less than 25 minutes.
-
8/3/2019 Scaling Big - DaaS SaaS Deployments for Citrix Service Providers_1108
31/35
Page 31
Data Collector Failover Scenario
Figure 24 - Data collector failover performance
Figure 24shows the data collector failover performance while serving user
application requests. It takes about 25 seconds for the failover to occur.
3.2.2 Data store performance
The data store is utilized primarily during a server join task and at IMA startup. The
server join operation places the highest burden on the data store. To demonstrate
data store performance capabilities, CPU time performance data is collected as 50
XenApp servers join the farm. Figure 25 shows the database server easily handles the
request as it only takes about 30 seconds for 50 servers to join the farm.
-
8/3/2019 Scaling Big - DaaS SaaS Deployments for Citrix Service Providers_1108
32/35
Page 32
Fort Lauderdale Data Store CPU Utilization
Figure 25 - CPU utilization while 50 servers join the farm
3.3 Worker Groups
For XenApp 6, Citrix eLabs ran a variety to tests to ensure scalability and performance inlarge 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:
Application publishing to worker groups and load balancing policies had no measurable
impact on application enumeration or load balancing times.
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.
Worker groups and their memberships are cached in memory for performance. This
results in an 8 KB increase in memory consumption for every worker group in the farm.
3.4 Citrix farm policies and bandwidth
Citrix policies provide an efficient method of controlling connection, security and bandwidth
settings of a XenApp-delivered application or desktop. Citrix policies can be configured
through the Group Policy Management Editor in Windows or the Delivery Services Console
-
8/3/2019 Scaling Big - DaaS SaaS Deployments for Citrix Service Providers_1108
33/35
Page 33
(DSC) in XenApp. The following analysis was done in an effort to understand the network
impact of policies to a user logon; bandwidth usage was compared against a varying number
of policies and policy settings.
Policy Configuration Bandwidth (KB)Incremental bandwidth
over baseline (KB)No Policies 127 (Baseline) NA
1 Policy / 5 Settings 158 31
1 Policy / 10 Settings 147 20
2 Policies / 5 Settings 161 34
2 Policies / 10 Settings 154 27
5 Policies / 10 Settings 193 66
Table 3 - User bandwidth consumption with Citrix policies
Table 3compares the bandwidth consumption of a single user logon with Citrix policies
enabled and settings configured, and a single user logon with no polices enabled. Based onthis data, additional policies and settings associated with a user add a small amount of
bandwidth to each logon. Also, policy settings that are unchanged from their defaults are not
transferred over the wire.
Policy best practices
Assign policies to groups rather than individual users. If you assign policies to groups,
assignments are updated automatically when you add or remove users from the group.
Do not enable conflicting or overlapping settings in Remote Desktop Session Host
Configuration. In some cases, Remote Desktop Session Host Configuration provides similar
functionality to Citrix policy settings. When possible, keep all settings consistent (enabled or
disabled) for ease of troubleshooting.
Disable unused policies. Policies with no settings added create unnecessary processing.
-
8/3/2019 Scaling Big - DaaS SaaS Deployments for Citrix Service Providers_1108
34/35
Page 34
4.0 Conclusion
Companies of all sizes are looking for a smarter approach to managing the applications and
data they use to run their business. More devices, more applications, and more places to
work means business owners have to spend an increasing amount of time on IT. Citrix
Service Providers can shift the focus for their subscribers back to where it matters the
mostgrowing the business. By offering a bundle of applications, desktops, and IT services,
customers get what they want in a familiar, pay-as-you-go subscription model.
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 is the
most scalable, high-performing release to date. XenApp provides the foundation for
aggregating over 1,000 servers or tenants into a single management scope, ultimately
providing a solution that enables service providers to build a flexible, scalable, and cost
effective architecture to meet their customers needs.
-
8/3/2019 Scaling Big - DaaS SaaS Deployments for Citrix Service Providers_1108
35/35
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.