A XenApp infrastructure is composed of two main elements:
Regardless of your farm size, it is recommended to have at least one server dedicated to infrastructure services.
XenApp 6.5 introduces a new server mode, session-only, for servers that only host published applications as shown in the following screenshot:
Choosing the session-host mode only during server setup
You can run your XenApp farm on physical servers or on virtual servers.
Citrix supports XenApp running on the following hypervisors:
My suggestion is to deploy your farm in a virtual environment; the use of a virtual environment makes possible to deploy new servers in minutes, without the need of buying physical hardware. In the design phase, this means you may choose to split the components on different servers and you may count on the high-availability features of the hypervisor. When the farm is in production, this means you may more easily deploy new servers to fulfill new business requirements or to improve performances.
A XenApp farm requires some infrastructure components that run on servers deployed with the controller role. Depending on the size of your farm, you may choose to install all these components on the same server or to scale them on different servers.
The data store is the repository for all the static information of your farm (farm, servers and applications configurations, administrative accounts, and so on).
Each session-host server in your farm needs a constant connection to the data store. When the Independent Management Architecture (IMA) service starts, it queries the data store and stores the farm configuration in the local host cache (LHC). Every 30 minutes, the IMA service then contacts the data store to ensure that its LHC is consistent.
If you deploy your session-host servers specifying the session-only mode, you may reduce the data store load and make the startup and join processes faster, as they require less data during the join and sync process.
Note
Refer to Citrix Knowledge Base (http://support.citrix.com/article/CTX114501) for the list of supported databases by different Citrix products.
During the setup wizard, you are asked to choose a database. You can choose New database to install a local instance of SQL Server Express or Existing Microsoft SQL Server database to use a database server already present on your network.
The free SQL Server Express is suitable for small (< 100 servers) farms, while for bigger farms I strongly suggest the use of an enterprise-level database server, possibly in a high availability configuration (such as Microsoft Cluster, Oracle RAC). If the data store is unavailable you can't make changes to the configuration of your farm; moreover if servers reboot, the IMA service won't start and they will no longer publish applications.
In both the cases you should not install other components on the servers that run your database.
XenApp does not usually require much storage for the database. A typical storage requirement is as follows:
|
Number of servers |
Number of applications |
Database size |
|---|---|---|
|
10 |
50 |
50 MB |
|
100 |
250 |
140 MB |
|
1000 |
1000 |
500 MB |
The data collector manages all the dynamic information of your farm (active and disconnected sessions, server loads, and so on). It also performs resolutions, that is, when a user requires an application, the data collector finds the least loaded server that can run that application.
It is, therefore, a key component in the application startup process. A slowness in the resolution process increases the overall time a user has to wait before the requested application is launched.
You need one data collector for each zone in your farm. A zone is a configurable grouping of XenApp servers; a farm requires at least one zone and all your servers must belong to a zone.
The main purpose to configure zones is to create a hierarchical structure to efficiently distribute changes:
Servers in a zone notify changes to the data collector of that zone using high-speed links (LAN)
The data collector then replicates those changes to data collectors of the other zones, usually through slow-speed links (WAN)
Zones are useful in a geographically distributed topology; for example, when your company has more than one site connected with WAN links. Zones are not necessary to divide servers in the same site. I worked with XenApp farms with more than 500 servers in one zone.
Citrix recommends keeping the number of zones in your farm to a minimum with one being optimal. Every time a dynamic event occurs, indeed the data collector of that zone must forward the event to the data collectors of the other zones: this replication consumes CPU and bandwidth.
The following figure is a flowchart by Citrix that helps to decide how many zones you need to deploy:
How to choose the farm topology
Data collector stores the entire event in the RAM memory. Its consumption depends on the farm size (number of servers, applications, and so on) and usage (number of active sessions and so on). However, this is usually not significant; for example, a data collector in a large farm (about 500 servers) I administer, uses an average of 250 MB of memory. Similarly, CPU usage is not significant. It may increase only if you create several zones in your farm but this is a discouraged practice. Anyhow, I strongly suggest you to dedicate one server to act as the zone data collector; if the data collector is running on a server that also publishes applications, it may experience resource contention and the resolution process may slow down.
Farms choose the data collector for each zone with an election between all the servers in the zone that can run the component (session-host only servers are excluded). XenApp administrators may change the election preference for each server to statically choose which server will be the data collector for the zone. The following screenshot displays the election preference options for the data collector:
Changing the election preference
Set the election preference to Most Preferred only on the dedicated server to be sure it will be chosen as the data collector during the election process.
If the data collector becomes unavailable, a new election is performed. You may also consider to define the backup server (a second dedicated server or a server running rarely used applications) setting its election preference to Preferred. The other servers in the farm should keep the default value (Default Preference).
The XML Broker is a component used by the Web Interface to retrieve information about the published applications. When a user logs on to the Web Interface, it displays the list of applications retrieved from the XML service to the user. When the user selects an application, the XML Broker responds with the address of a server running that application.
As the XML Broker works closely with the data collector, it is recommended that you install the XML Broker on the same server running the data collector component. If you add more XML Broker servers, you can configure the Web Interface or add an external load balancer (for example, a Citrix NetScaler) to balance the requests between them. The following screenshot displays the option of selecting an XML Broker server for load balancing:
Load balancing XML Broker servers
The license server stores and manages Citrix licenses. The first time a user connects to a XenApp server, the server checks out a license for the user. Subsequent connections of the same user share the same license.
A single license server is enough for farms with thousands of servers and users; you could install a second license server in your farm but the two servers cannot share licenses. Because the license server is contacted when the user connects to a XenApp server, slow responses may increase the login time. You should place the license service on a dedicated server or, in case of small farms, on a server that doesn't publish applications. The license server process is single-threaded so multiple processors do not increase its performance.
If the license server is not available, all the servers in your farm enter a grace period of 720 hours; during this period users are still allowed to connect. This means that you usually don't need a high-availability solution for your license server. If a server fault occurs, you can install a new license server during the 30 days of the grace period or power on a second license server you prepared and kept turned off (cold standby).
The Web Interface provides users access to the published application through a web browser. It's an application running on IIS 7 Web Server and developed in Java/.NET.
A single Web Interface, running on a Dual Core Xeon Server, can handle up to 7 to 8 requests per second. You should expect many connections to the Web Interface when the users arrive at work in the morning or after lunch, so size your Web Interface server based on the number of users you expect will log on at the same time.
A tip to provide high availability and load balancing for this component is to deploy two Web Interface servers and balance the incoming connections using an external HTTP load balancer, as shown in the following diagram:
Citrix Web Interface with external balancer
Session host servers publish and run the applications in your farm. Correctly sizing these servers is one of the most critical tasks during the design of your infrastructure; if you underestimate the servers, users will eventually complain about application slowness or worse, some users won't be able to run them at all. If you overestimate them, your boss will probably complain about the cost of the project.
The number of servers you need and their hardware configuration depends on the number of users and applications, but even more on the kind of the applications and how you deliver them to the users. My suggestion is to set up a test farm and to use it to verify the load each application produces. Later in this chapter you'll learn how to use Citrix EdgeSight for Load Testing to simulate real users.
Citrix XenApp supports five ways to deliver applications to the users. Each method has pros and cons and the choice of one or another highly changes the resource requirements of the session host servers. The methods are explained in the following sections:
Applications are installed on the server. When a user launches an application, it runs on the server. Session host servers, therefore, require sufficient resources (CPU and RAM) for the applications, while user devices may be lightweight devices (thin clients, tablets, and smartphones). No offline access is possible.
Applications are put in profiles and stored on a file or web server. When a user launches an application, this streams to the server where the execution takes place. Session host servers still require sufficient resources (CPU and RAM) for the applications, while user devices don't. No offline access is possible.
Applications are put in profiles and stored on a file or web server. When a user launches an application, this streams to the user device. This device must have enough resources to run the application and must run Windows OS. Applications are cached on the user device, so offline access is possible.
Applications are put in profiles and stored on a file or web server. When a user launches an application, XenApp tries to stream it to the user device. If this is not possible – the device runs an unsupported OS – the application is streamed to the server. This is a more versatile method, but session host servers still require sufficient resources to run the applications in the backup mode.
The traditional and most common method to deliver applications is to install them on the session host servers. Two strategies available for placing applications on servers are: siloed and nonsiloed.
In this approach applications are installed on small groups of servers; you could even have servers running a single application. Applications are usually grouped by their use, for example, all the applications used by the Financial department are installed on the same servers, while the applications used by the HR department are installed on different servers.
This approach is sometimes required if your applications have different hardware requirements or may cause conflicts if installed on the same server. Some application vendors, moreover, don't consider a different licensing if their applications are published through XenApp. So if you pay license fees simply counting the number of installations, you may reduce the cost of installing them on a small number of servers.
In this approach all the applications are installed on all the servers. This approach is more efficient as it reduces the number of required servers and it may also improve the user experience because it allows users to share the same server session with different applications. If you're using Provisioning Services, a nonsiloed approach also helps you to reduce the number of different vDisks you have to create and maintain.
My suggestion is to use the nonsiloed approach when possible. Later in this book you'll learn that, with worker groups, you will still be able to logically group applications on servers even with this approach.