XenApp Servers Explained
Proper farm design is the most important aspect to having a well performing, scalable farm. This post examines the architecture and design of the Citrix XenApp solution as the number of users/servers requiring applications or desktop access scales.
XenApp Server Roles
XenApp farms have two types of servers: infrastructure servers and worker servers. Worker servers are dedicated to the role of hosting published applications and desktop. Infrastructure servers perform specific functions and do not typically host published applications, except in small farms. Infrastructure servers host functionality that supports the farm, such as the data store, data collector, XML Service, license server, and other services.
- Farm infrastructure services. Data Store, Data Collector, XML Service and Web Interface
- Access infrastructure services. Access Gateway (optional)
- Additional services. Streaming File Server, Provisioning Services (optional), Configuration Logging database (optional), EdgeSight database (optional), and SmartAuditor (optional).
XenApp Farm Roles
- Access Gateway: Provides secure access to Citrix XenApp applications and desktops.
- Web Interface Server: A Web server running Microsoft’s (IIS) Web server and Citrix’s Web Interface which hosts the Web pages users connect to in order to enumerate and launch published applications.
- Data Collector: Maintains dynamic farm-wide data, including the list of online and offline servers, as well as the load level of each server.
- XML Service: Used by the Web Interface to enumerate published applications from the XenApp farm.
- Database Server (Data Store): Could be another XenApp server (SQL Express) or a server running an enterprise database like Microsoft SQL or Oracle.
- XenApp Worker Server: Servers that host the applications and desktops.
It is common practice to group one or more of these infrastructure services in small farms. In large deployments, each service runs on one or more dedicated servers for scalability and redundancy. The table below categorizes the XenApp deployment model into groups based on the number of users and servers hosting the applications and desktops.
Farm Size Categories
|
Farm Size |
Number of Users | Number of XenApp Servers "Workers" |
| Small (Pilot/Demo) | < 100 | 5-Jan |
| Medium | < 1000 | May-50 |
| Large | < 5000 | 50 – 250 |
| Enterprise | > 5000 | 250 – 1000 |
| Service Provider | 100 – 100,000 | 1 – 1000 |
While farm size (small, medium, large, etc…) as determined by the number of servers, can indicate the general category your farm is in, another important factor to consider is the number of user connections. Because applications can scale differently from server to server (some servers might support 100 user connections, others might support only ten), both categories are used to determine the size of the farm.
Small Farm (< 100 Users / < 5 XenApp "Worker" Servers) 
For small environments all roles can be placed on a single server. As the number of users increase, it is important to know where the bottlenecks are occurring. Once a bottleneck is identified, move the affected services to their own server.
Medium Farm (< 1000 Users / 5 – 50 XenApp "Worker" Servers) 
For medium sized environments dedicating servers for application and desktop hosting presents the best use of computing resources and avoids contention of resources between the users and the infrastructure. As memory or CPU become scarce, more servers supporting applications and desktops can be added easily. At this stage, the resource usage of the infrastructure services, for a farm of this size, is within the bounds of an appropriately sized server.
Large Farm (< 5000 Users / < 50 – 250 XenApp "Worker" Servers) 
As the user count increases, the combined overhead of server resolutions and application enumerations (Data Collector), SQL Database resource usage (Data Store) and HTTP requests (Web Interface) will require infrastructure services to be placed on dedicated servers. Administrators should group infrastructure servers and services together when they have similar functions. For example, the XML Server should be grouped with the data collector.
Another benefit of this design is, if the data collector goes down, then the servers hosting published applications would not take on that role, leading to contention. A backup Data Collector is recommended to keep the operations segregated in the event of a DC failure.
Enterprise Farm (> 5000 Users / 250 – 1000 XenApp "Worker" Servers) 
In enterprise class deployments, disaster recovery and failover capabilities become critically important, each infrastructure service will be dedicated to one or more servers.
Service Provider Farm (< 100 Users / < 5 XenApp "Worker" Servers) 
The CSP XenApp solution provides a scalable and high availability infrastructure designed around multi-tenancy, tenant security and automation. In this module, applications and desktops are virtualized, and subscriber partitions and Active Directory boundaries are defined, which are centrally governed by XenApp systems.
For more information re
garding the CSP Reference Architecture see http://www.citrix.com/skb/articles/RDY2524.
For more information on designing and building a scalable XenApp solution for the cloud please reference the following whitepaper. http://www.citrix.com/skb/articles/RDY3028
