Basic Principles of designing Citrix XenApp Environments Part 1
- Published: Tuesday, 09 December 2008
During several project I'm written Technical Design for Citrix Presentation Server / XenApp infrastructures. In this article series I want to explain which parts need to described within a technical design, which considerations should be made and some best practices. Before I start I need to emphasize that there is no default design. Every design is different, because decisions are made based on wishes, needs and request of the customer. So this article series will introduce you to the design parts and things which should be discussed before and/or during writing a design.
Before we start
Before we start
Independent writing a technical design for a Citrix XenApp infrastructure, a Terminal Service only infrastructure or a different Server Based Computing you should keep the Terminal Server Basic Concepts in mind. Every server need to be 100% identical, which can be realized using rules like: automate the installation and configuration, chronologic order of applications, separation of installation and configuration, do not use the shadowy key, use a DTAp environment, limit printer drivers and restrict profiles. More information about these terminal server basic concepts can be found in an earlier written article. So mention in the document how these rules are accomplished using with tools or at least the requirements for such tools.
Also every design includes a description of the hardware on which the platform will run. When using 32bit based operating systems special switches are included to allocate more memory than 4 GB of internal memory. When using these switches changes are made to so-called user and system memory, where system memory will be extended and user memory will be decreased. Within Terminal Servers the user sessions are running within the user part of the memory, so adding more memory causes that less user memory is available. Summarized on 32 bit 4 GB for Terminal Server is the maximum amount of memory. When using 64bit Operating System this limitation on memory does not apply, but remember that 32bit applications running on 64bit operating system are consuming 1 ½ to 2 times more memory then the application would use on a 32bit platform. Also think about 16bit applications, because they cannot be installed on a 64 bit platform. Normally two physical CPU's are enough, because more CPU's will create more overhead, other hardware limitations will be reached and/or applications are often not written to use more than 2 CPU's.
It also a best practice to use the quickest disks available in a RAID 1 with a RAID controller with Write Cache Battery. Be careful when using more than one Network Interface Card using Fault Tolerant and or Load Balancing principles. Thoroughly discuss this kind of configuration with the network engineer.
Farm Architecture & Design
The first design component is the Citrix farm. A Citrix farm is a logical group of Citrix server sharing the same settings and configuration. A Citrix farm is the highest level in the Citrix Architecture.
When designing a Citrix infrastructure this design decision should be made first where the question is if more than one farm is required. Creating one or more farms is dependent of following considerations:
- Configuration separating versus sharing
This consideration is mostly based on administrative reasons or very special requirements to set-up different configuration settings (based on farm level) between servers. Normally sharing the configuration is much to administrator and maintain than several configurations. Examples to choose for separate configurations are for example different shadowing configurations or very unreliable links if Terminal Servers are located at several locations.
- Legal regulations
If your organization exists of several companies or in several countries there can be legal regulations which do not allow that such companies are using the same infrastructure components and so separate farms need to be created.
- Security aspects
Although Citrix XenApp has the possibility to add delegation of control for administration tasks there can be reasons that your organization wants additional security guidelines for the administration which do not fit with the delegation of control possibilities.
Last but not least is the controllability of the environment. In very large organization with many servers and hundreds of applications it can be too difficult to administrate this out of one console. Separation of applications in farms can be a solution, but also introduces more complexity.
The best practice is to use one farm when possible. The legal regulations is the only reason which makes is impossible to stay to one farm, but consider more farms thoroughly based on the other considerations. In my opinion using silos and delegation of control it better to handle than the complexity by creating more farms.
To be continued
This article will continue in a next article describing more Citrix XenApp design decisions.