Citrix Systems XenServer User Manual

Worldwide Consulting Solutions

Reference Architecture
XenServer 4.1

XenServer for XenApp - Better Together

Overview

For the last few years, IT professionals have questioned whether it makes sense to virtualize XenApp environments. The
answer has always been “it depends.” In short, that answer has not changed. Most organizations realize that having an
environment that is 100% physical or 100% virtual may not be the best solution. Adding server virtualization impacts
single server scalability, requires management and technical expertise, and adds environmental complexity. However, the
benefits can include higher utilization, greater availability and increased flexibility. Before deciding the best solution for
your environment, the challenges must be considered, the goals must be understood and the environment must be
conducive for server virtualization.

Objectives

IT organizations everywhere are either currently evaluating or in the early phases of investigating server virtualization
solutions. While there are many compelling arguments for the adoption of virtualization technologies, the main drivers
from both a business and a technical perspective can be categorized into three distinct groups:

 Higher utilization
 Greater availability
 Increased flexibility

Higher Utilization

Organizations have built XenApp server farms to deliver varied types of applications, ranging from mission-critical line­of-business applications to the outdated, resource-intensive applications that are only occasionally used. Depending
on the application and server resources, a single XenApp server has the potential to deliver applications to a handful of
users or several hundred users simultaneously. Increased scalability can have a large impact on reducing the overall
environment‟s server footprint if overall resource utilization can be increased. Trying to get more efficiency from of a
XenApp environment without requiring huge investments in hardware is a challenge organizations face. This
challenge focuses on the following questions:

 How to best fully utilize servers without sacrificing the user experience?
 How to allow systems to perform multiple functions without requiring significant integration testing?

2

Greater Availability

Organizations are looking for ways to provide greater availability and responsiveness to applications. This means
being able to overcome faults, failures and surges in application usage without significantly increasing the hardware
footprint of the XenApp infrastructure, raising the questions:

 How to provide adequate availability taking into account cyclical surges peaks in usage?
 How to overcome faults in the environment without significantly increasing hardware resources?
 How to make applications available quickly in lieu of a disaster?

Increased Flexibility

There are more options than ever for delivering applications to users, and there are likewise more requirements than
ever for providing the optimal working environment. Organizations must be able to develop and test system changes
before rolling out into production, as well as find ways to integrate technical solutions into the XenApp environment.
Providing a greater level of flexibility requires one to look into the following aspects:

 How to provide a development/test environment that closely mimics production?
 How to assimilate a mixed 32/64 bit environment?
 How to deliver a XenApp environment faster?
 How to provide the optimal IT environment allowing the business to grow?

Challenges

Currently, most XenApp deployments are functioning in a purely physical environment. Each server in the infrastructure
has a single purpose either to function as Web Interface, licensing, zone data collector, data store or member server
resulting in a 1:1 relationship between role and physical device. These environments typically resemble something like
Figure 1.

3

XenApp Farm

Data Store

Application Hub

Primary Data Collector

Line-of-Business

Load Managed Group

Core Business Applications

Load Managed Group

Backup Data Collector

Web Interface

License Server

Business Unit

Line-of-Business

Load Managed Group

Figure 1: Physical XenApp Architecture

Improving availability and flexibility often results in lower utilization rates because more physical servers are required. For
example, look at the following aspects of this architecture:

 Web Interface: The Web Interface servers are responsible for delivering applications to the users by acquiring

their authentication information, enumerating and displaying available applications and forwarding the application
launch request to the XenApp server. Because Web Interface is a critical component, redundant servers must be
available to provide fault tolerance. As the XenApp farm increases in size, additional Web Interface servers will
be added to handle the greater potential workload. Providing fault tolerance and designing for the maximum
possible workload results in an even greater number of underutilized servers.

 Data Collector: The data collector is responsible for authenticating users, identifying accessible applications, and

identifying which XenApp server a user should connect. The data collector is the brokering mechanism for
requests coming from the end user and Web Interface destined to the XenApp farm. As the size of the XenApp
farm increase, the data collector moves from becoming a shared server, responsible for delivering applications, to
a dedicated server. If the primary data collector were to fail, a backup, with the same hardware and software
configuration, should also be available. Similar to Web Interface, providing fault tolerance through the use of
additional allocated hardware and providing optimal responses through the use of dedicated hardware requires
more physical servers resulting in an even greater number of underutilized servers

 Load Managed Groups: Whether applications are installed or delivered via streaming to the XenApp servers,

organizations might create load managed groups based on business requirements. Load managed groups are
created to focus a set of XenApp servers on a particular set of applications. This is done for numerous business
and technical reasons including application update frequency, business unit server ownership, application
criticality, regional applications, and application and server language requirements.

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:

o Line-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.

o Business 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.

o Core 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.