scaling big - daas saas deployments for citrix service providers_1108

Upload: asrul-ezwadi

Post on 07-Apr-2018

219 views

Category:

Documents


0 download

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.