Choosing a Database

General recommendations are listed below, based on the following size table.

• Microsoft SQL Server and Oracle are suitable for any size environment and are recommended for all large and enterprise environments. When deploying large farms across a WAN, you can obtain a performance advantage by replicating the data store and distributing the load over multiple database servers. SQL Server and Oracle are suitable for large farms and support replication.

  Do not install XenApp on the SQL Server or Oracle database server.

• SQL Server Express is suitable for all small and many medium environments located in one physical location, which do not have branch offices across a WAN.

See the database product documentation for hardware requirements for the database server.

Database Server Hardware Performance Considerations

The response time of other events (such as starting the IMA Service on a single server, recreating the local host cache, or replicating printer drivers to all servers in the farm) is affected more by the farm size than by the data store response time.

Adding processors to the server hosting the data store can improve response time when executing multiple simultaneous queries. In environments with large numbers of servers coming online simultaneously and at frequent intervals, additional processors can service requests faster.

The capabilities of the processor on the database server affect management console performance, how long it takes to add (configure) and remove a server from the farm, and how long it takes to start multiple servers simultaneously.

In the following chart, five sample farm configurations (A through E) are listed, with measurements of various metrics in the farm.

The following table lists suggested hardware for the server hosting the data store, for each configuration in the previous table.

The actual performance of a farm’s data store varies depending on the database engine and the level of performance tuning achieved.

Replication Considerations

When you join a new server to a XenApp farm, a significant amount of time can be spent waiting for the server’s Citrix Independent Management Architecture (IMA) service to start and come online. As a result, you might choose to configure SQL data store replication at each remote site, to allow member servers to point to their local SQL subscriber and avoid the slowness of traversing the WAN. However, as your farm expands geographically, the overhead of administering SQL subscribers at each of your sites becomes a burden.

In XenApp 6.5, you can configure servers in session-host mode (also known as session-only mode). This server mode allows XenApp servers to join a farm in significantly less time with substantial bandwidth savings.

When a XenApp server joins a farm, it performs numerous read and write operations to the IMA data store as well as a download of the farm data to its Local Host Cache (LHC). In previous releases of XenApp, all member servers of the farm were required to download all farm data to their LHC during a join, resulting in a large amount of data store transactions and bandwidth consumption. In XenApp 6.5, you can dedicate a select few servers as XenApp controllers which are responsible for farm management tasks, while the remaining member servers are session-only servers whose sole task is to host user sessions. XenApp controllers must synchronize all of the farm data, while session-only servers must synchronize only a subset of the information to their LHC. These changes result in fewer database transactions, less bandwidth consumption, and faster IMA startup performance.

While session-only XenApp servers can host XenApp user sessions, they cannot perform the role of data collectors, nor can they participate in or trigger a data collector zone election. The XML service does not run on session-only XenApp servers; therefore, the Web Interface cannot use them to perform application enumerations. Additionally, management tasks such as AppCenter discovery or PowerShell tasks cannot be run directly on a session-only server. However, with proper planning and placement of XenApp controller servers, leveraging the session-only model can optimize your farm performance and reduce IMA bandwidth and server provisioning time.

You specify the XenApp server mode through the Server Role Manager when you configure the XenApp role to join a farm. For more information, see the XenApp Server Mode section in Before Configuring XenApp.

Therefore, although you can replicate a XenApp 6.5 data store on SQL Server 2008 R2 and earlier versions, you do not need to, and you may not be able to with later SQL Server versions.

Planning for Configuration Logging and IMA Encryption

The IMA encryption feature provides a robust AES encryption algorithm to protect sensitive data in the IMA data store. Enabling IMA encryption provides an additional layer of security for the data preserved by the Configuration Logging feature.

If you do not enable IMA encryption, XenApp uses the standard encryption used in previous versions of XenApp. The Securing Server Farms documentation contains more information about IMA encryption, Configuration Logging, and when to enable these features.

To enable IMA encryption, you specify a key which is used for all the servers in your farm. To generate the key, use CTXKEYTOOL, which is available on the installation media.

If you have multiple farms in your environment, Citrix recommends you generate separate keys for each farm.