Basic Principles of designing Citrix XenApp Environments Part 3
- Published: Wednesday, 07 January 2009
This article is part three of an article series about Citrix XenApp design decisions. The starting article can be found here.
Data Store Architecture & Design
Data Store Architecture & Design
One of the most important components is the Citrix Data Store. The Datastore is a database storing the static information about the Citrix Farm. Think of settings for the load evaluator, published applications, zones and much more.
When writing a design the decisions made for the Data Store can have much influence in the practical usage of the Citrix infrastructure.
- Type of Database
First the type of database you would like to use should be determined. Citrix supports several databases like MS Access, MS SQL Express, MS SQL, IBM DB2 and Oracle. The MS Access database and MS SQL Express database will be hosted on the first server on which Citrix XenApp will be installed, while MS SQL, IBM DB2 and Oracle databases normally or hosted on a dedicated database server.
- Direct or Indirect Mode
During the installation of Citrix XenApp you will be asked of the database will be accessed direct or indirect by the server. MS Access and SQL Express databases can only be accessed indirectly where you have the option when using MS SQL, IBM DB2 or Oracle. When using the indirect mode the server will ask one server to access the datastore for the requested information. In other words there is Single Point of Contact accessing the database.
When writing a design also the reliability of the database is important. Although the server can perform their tasks for a while without a database connection, no changes can be made to the configuration of the Citrix Farm. Try to determine the amount of changes to the farm and the importance/priority of those changes in the case the database is unavailable. For such situations on a database level several options are available to create a redundancy using replications, clustered database or similar solutions.
- Bandwidth (Replication of Databases)
When the servers are divided geographically over low bandwidth lines it can be good idea to choose for database replication, so every location has a copy of the datastore available locally. Remember that (a bit depend on the type of database) this creates more complexity for the environment and also database replication uses bandwidth.
I recommend using a dedicated database for the datastore when possible. Almost every infrastructure has a database server available. The load for the datastore is minimal, so normally this can added to a current database server available. Only when there is small farm (less than 10 servers) and no database server is available MS Access or MS SQL Express (recommended over MS Access) is an option.
In such small environment with a database hosted on a Citrix XenApp server use this server only as a management server (for administrators) and as primary data collector and do no host any published applications on this server. When using the MS SQL, IBM DB2 or Oracle database hosted on a database server use the direct access mode to access the database. This prevents a Single Point of Failure (SPOF) in the infrastructure. Citrix (and also I) recommends using a single database when possible for normal usage. Only consider a replicated database when servers are divided by low bandwidth connections. Describe how the database will be restored in case of a disaster.
Load Balancing Architecture & Design
Within Citrix XenApp advanced and higher Citrix offers the possibility to divide the load between the servers using Load Balancing. Load Balancing is based on a load evaluator, where this load evaluator exists of sever rules. These rules will provide a number reflecting the load on the servers.
Considerations for Load Balancing are:
- Differences between hardware
If a server or servers has more memory, quicker hard disks, better or more processors than other servers in the farm there is good change that such a server can handle more sessions/application than the server with lower specifications. When there a big differences in hardware and during tests is shows this hardware can handle more traffic, create different load evaluators for those hardware types.
- Dynamic values of evaluators
Within a load evaluator there are several roles which are based on values that can have a very dynamic character. Examples are pages per second, processor usage and disk usage. When your load evaluator is based on those dynamic counters this can cause by spikes of these rules that the actually load balancing is not optimal between the servers.
- Disconnected Users
It is good to remember that disconnected sessions are not calculated within the load evaluator but of course are using resources on the servers. If a lot of disconnected sessions are expected use those for the calculation of the values of the rules.
- Calculation method of the Load Evaluators
There are many misunderstandings about the calculation method being used by the load evaluators. When more rules are available within one load evaluator each rule will give the value for his own rule. The rule with the highest value will then be used to show the load evaluator value for that resource. Many people are expecting that all values are summed up and then divided by the amount of rules. So one wrong configured rule in the load evaluator can cause strange load balancing issues.
I have seen many load evaluator configurations and out of these practical experiences I use normally a specific load evaluator for each farm based on non dynamic rules as the primary rule. Normally I will the Server User Load (with an actual value of a full load based on testing during the project) combined with high values of no load and full load (think about 70%/80% no load and 90%/95% full load) of CPU Utilization and Memory Usage.
To be continued
This article will continue in a next article describing more Citrix XenApp design decisions.