Citrix Systems 4.1 manual

4

When creating a load managed group, each group must provide enough redundancy to be capable of supporting all users in the event of a server failure. This results in an N+1 scenario where there is at least one additional XenApp server per load managed group. In many situations, organizations implement an N+10% strategy where an additional 10% of XenApp servers per load managed group are allocated in order to allow for multiple server failures or maintenance.

In this architecture, there are three load managed groups focused on the following:

oLine-of-Business: Every organization has a set of applications that are critical to the proper functioning of the business, often called Line-of-Business applications. In this particular example, the Line-of-Business servers experience high utilization just from the day-to-day activities of the business. These systems are optimal in their physical world as utilization is high, but if a few servers fail, the remaining systems will not be able to support the business.

oBusiness Unit Line-of-Business: Driven by organizational structure, this scenario includes a load managed group for another line-of-business application meant for a single business unit. The business unit purchased the hardware and had it integrated into the corporate XenApp environment. This group of servers is lightly loaded and is meant for only a single business unit.

oCore Applications: Many XenApp environments contain a load managed group focused on the delivery of the remaining core business applications like Microsoft Office, Adobe Acrobat, Internet Explorer, etc. This load managed group is not mission critical, but this group of servers experiences the highest user loads of all load managed groups. Although many users are connected to the servers, most applications are idle.

For example, most users keep their email client open all day, but only interact with the application when a new message appears. However, during certain periods throughout the year, this load managed group experiences a huge surge in utilization due to month-end and year-end report generation. Because it is essential that there are enough servers available his peak demand, the environment was designed for maximum usage, resulting in underutilized servers the rest of the year.

∙License Server: The license server receives license check-in and license check-out requests from XenApp server. This service is fairly lightweight, but often hosted on its own physical server. Most servers include dual or quad processors as standard, but as the license server is a single threaded application these additional processors remain unused. If the license server is unavailable for more than 30 days, users will be denied access. This has led some organizations to implement either a hot or cold standby. In either case, a new physical server is required but unused unless the primary license server fails. This server takes up data center space and potentially consumes power and cooling resources just to mitigate against the possibility that the primary server fails and cannot be restored in 30 days.

∙Data Store: The data store is a critical component as all static farm information is stored within the data base. Due to the criticality of this database, some organizations dedicate a server for this purpose or at least dedicate the server for additional XenApp farm databases like Configuration Logging, SmartAuditor, or EdgeSight. In this scenario, an entire physical server is being used to host multiple databases that could range in size from a few megabytes to gigabytes. Regardless of what the server is hosting, the important concern for the Data Store is that it is backed up and can be restored quickly in the event of a hardware failure.

∙Dev/Test Environment: A large percentage of XenApp environments have implemented some form of a development and test environment to validate operating system changes and application changes before being rolled out into production. The Dev/Test environment, to be of value, should mimic production as closely as possible. Dev/Test environments require their own dedicated physical infrastructure and must be built, managed and maintained in an identical fashion to production systems.

∙Hardware: Due to technical limitations within the operating system, organizations have been forced into relatively small server standards, which take up a considerable amount of real estate in the data center. Because of a 4GB limit on the Windows 32bit operating system, organizations have had to purchase many servers just to support the users. Moving towards a 64bit platform would go a long way in overcoming the memory bottleneck, but due to application or driver inconsistencies, many organizations are not ready to make the lead into 64bit computing. In a physical environment, this leaves organizations with few options.