Scaling XenMobile 10

Scaling XenMobile 10

Understanding the scale of your XenMobile infrastructure plays a significant role in how you decide to deploy and configure XenMobile. This article offers answers to common questions on determining the requirements for small to large scale enterprise deployments.

Performance and Scalability Guidelines

The data in this article are intended as guidelines for determining performance and scalability of a XenMobile infrastructure. The two key factors for determining how to configure your server and database are scalability (maximum users/devices) and logon rate.

Scalability is defined as the maximum number of concurrent users executing a defined workload. For more information on the flows used to load the XenMobile infrastructure, see .

Logon Rate is defined as the on-boarding of new users and the authentication of existing users. On-boarding rate is the maximum number of devices that can be enrolled on the environment for the first

time. Called First Time Use or FTU in this article, this data point is important when orchestrating a rollout strategy.

Existing user rate is the maximum number of users who authenticate to the environment, who have

already enrolled and connected with their device. These tests included creating sessions for already

enrolled users and the execution of WorxMail and WorxWeb apps.

System Configuration and Test Results

This section describes hardware configuration used and the results of running the On-boarding (FTU) workload and the Existing User workload scalability tests.

The following table defines the hardware and configuration recommendations for XenMobile when scaling from 1,000 to 100,000 devices. These guidelines are based on the test results and their associated workloads. The recommendations account for the acceptable margin of error as defined in.

Analysis of the test results led to these conclusions:

Logon rate is an important factor in determining the scalability of a system. In addition to the initial logon, logon rates are dependent upon the authentication time-out values configured in your environment. For instance, if you set the authentication time-out value too low, users must perform more frequent logon requests. Therefore, you need to clearly understand how time-out settings affect your environment.

An external database (SQL Server) with 128 GB of RAM, 300 GB of disk space, and 24 virtual CPUs was used for the tests and is recommended for production environments.

To achieve maximum scalability, CPU and RAM resources were increased on XenMobile.

The 10-node cluster configuration was the largest configuration validated. Scaling beyond 10 nodes requires an additional XenMobile implementation.

The preceding table shows the recommended on-boarding and existing user logon rates based on the XenMobile configuration, NetScaler Gateway appliance, cluster settings, and database. Use the data in this table to construct an optimal enrollment schedule for new deployments and returning user/device rates for existing deployments. The Configuration section relates enrollment and logon performance data to the appropriate hardware recommendations.

Note: You will experience the following if you exceed the recommended rates or hardware recommendations when sizing your system.

Enrollment or logon latency (round-trip time)

Total average latency: > 1.5 seconds

Average latency for a NetScaler Gateway logon: > 440 ms

Average latency for a Worx Store request: > 3 seconds

Physical performance degradation, such as CPU and memory exhaustion, was observed on the

infrastructure components when scalability limits were reached.

Invalid responses on the NetScaler Gateway and XenMobile appliances.

Slow XenMobile console response time.

The error percentage in the preceding figure includes the overall error experienced considering requests corresponding to every operation and is not limited to logons. The error percentage is within the acceptable limit for each test run as defined in.

The following figure shows the reference architecture for a small scale deployment. It is a standalone architecture that supports up to 10,000 devices.

The following figure shows the reference architecture for an enterprise deployment. It is a clustered architecture with SSL offload for MDM over HTTP that supports 10,000 or more devices.