Design Consideration

Presentation Server 4.5

Consulting Solutions

The Definitive Guide to Zone Design

Overview
One of the major decisions with a Citrix Presentation Server 4.5 design is deciding on the number of zones required. As
additional versions of Presentation Server are released the details behind zone communication are also changed. As
zone communication continues to improve, the basis for deciding on the number of zones also changes.
This article will discuss the design considerations for zones when building a Presentation Server 4.5 environment.

Zone Communication1
In order to understand the impact zone creation has on an architecture, one must first understand the four main types of
communication occurring within and between zones.
Full Update: Member Server
Data Collector
Full Update: Data Collector
Data Collector
Session Update: Member Server
Data Collector
Session Update: Data Collector
Data Collector

Full Update: Member Server
Data Collector

During a full update, the member server notifies the data collector of all usage as related to sessions and published
application usage. Once the data collector receives this information, it responds back to the member server with additional
information. This process occurs during the following instances:
When a member server is brought online
When a new data collector is elected
To calculate how much round-trip data is transmitted between the member server and data collector, use the following
calculation:
KilobytesT ransferred = (3.43 + (.05 Connections ) + (.04 Disconnections ) + (.0013 Apps )) 1.5
Connections are per server
Disconnections are per server
Apps are published applications per server

1
All calculations assume zones do NOT share load information
 2

Full Update: Data Collector
Data Collector

During a full update between data collectors, the initial data collector informs all other data collectors of the status within
its own zone. Once the initial data collector sends this information, the receiver responds with its own information. This
process occurs during the following instances:
When a new Data Collector is elected
To calculate how much round-trip data is transmitted from the initial data collector to all other data collectors, use the
following calculation:
KilobytesT ransferred = ((3.5 + (.06 Connections ) + (.06 Disconnections ) + (.06 Apps SrvPerZones ))
Connections are per zone
Disconnections are per zone
Apps are published applications per farm
SrvPerZones are the number of servers in the zone
As can be discerned, the more zones there are, the greater the impact on the environment.

Session Update: Member Server
Data Collector

To initiate a session update, an event occurs on the member server regarding the state of a session, such as a new user
making a connection. For each event, network traffic is generated to inform the data collector about the change in state.
This communication is as follows:
Action Traffic
Connection .240 Kilobytes
Disconnection .370 Kilobytes
Reconnection .400 Kilobytes
Logoff .650 Kilobytes

Session Update: Data Collector
Data Collector

Once a member server performs a session update to the data collector, the data collect must contact every other data
collector to relay information about the change in state. For each connection, disconnection, reconnection and logoff
occurring on a member server, the same amount of traffic is generated by the data collector, but the traffic is multiplied by
the number of zones. This traffic is as follows:
Action Traffic
Connection Kilobytes = .240 ( Zones 1)
Disconnection Kilobytes = .370 ( Zones 1)
Reconnection Kilobytes = .400 ( Zones 1)
Logoff Kilobytes = .650 ( Zones 1)

Real-World Example
Consider the following real-world example when designing zones to determine how varied numbers of zones would incur
different amounts of network traffic. The example specifics are as follows:
Number of servers: 100
 3

Number of published applications: 240

Average number of published applications per server: 30
Average number of connected users per server: 50
Average number of disconnected users per server: 2
Average number of connections per hour per server: 30
Average number of disconnections per hour per server: 15
Average number of reconnections per hour per server: 10
Average number of logoffs per hour per server: 20

Description of Events 1 Zone 2 Zones 4 Zones 8 Zones

New Data Collector (Member Server -> Data Collector) 7.61 7.61 7.61 7.61
New Data Collector (Data Collector -> Data Collector) 5 305 605 905
Total Data Transmitted for New Data Collector Event 13 313 613 913
Description of Events 1 Zone 2 Zones 4 Zones 8 Zones
Traffic generated by one server per hour 28.25 28.25 28.25 28.25
Traffic generated within one zone per hour 2,825 1,412.5 706.25 353.125
Traffic generated within all zones per hour 2,825 2,825 2,825 2,825
Traffic generated from one data collector per hour 0 1,412.5 2,118.75 2,471.875
Total traffic sent by all data collectors per hour 0 2,825 8,475 19,775
Total inter and intra-zone traffic per hour 2,825 5,650 11,300 22,600
Table 1: Kilobytes Transmitted

Design Considerations
Based on the real-world scenario, it is clear that as the number of zones increase, the amount of traffic generated
increases significantly. This occurs because each data collector communicates with every other zone data collector.
Each time a connection event occurs on a member server, the data collector is updated. Because the data collectors
information changed, it must contact every other data collector. This process occurs to all other zones, meaning, adding
zones will have a negative impact on network traffic.
Also, each additional zone has a negative impact on data collector scalability. As the number of zones increase, so too
does the amount of data each data collector must consume. If there are two zones, with one zone having 90 servers and
another having 10 servers, the smaller zone data collector must still be just as powerful as the data collector in the larger
zone because when a session event occurs in the larger zone, it is propagated to the other zone.
As a general recommendation, it is advisable to dedicate zone data collectors when enough activity in the zone warrants
the creation. The processor utilization and Application Resolution time should be monitored as the farm grows. As the
processor increases, it would be warranted to dedicate the data collector. Also, as the Application Resolution time
increases, the server should be dedicated so it can use all of its processes to manage resolutions, which is the time it
takes between a user requesting an application and the data collector responding with the preferred server.

When to Create Additional Zones

The network traffic data alone justifies the recommendation to designate the fewest number of zones, with one being
optimal. However, multiple zones do play a critical part in overall architecture for a distributed Presentation Server
environment. In environments where large numbers of servers are located in geographically dispersed locations, it
may be advisable to designate multiple zones if:
Presentation Server is part of a disaster plan that fails over to an alternate location
 4

The same published applications are hosted in multiple zones

Users need to access the closest application in a geographically dispersed environment
User-specific backend data is located in other locations than the main data center
Based on these items, an organization may find it advantageous to use Zone Preference and Failover functionality.
This will allow an architect to design the environment so users connect to the servers closest to them and also where
their backend data is located. Zone Preference and Failover will eliminate the need for publishing the same application
with different names like Microsoft Word North America and Microsoft Word Europe).

When Not to Create Zones

Test Environments: When planning a test or development environment, creating an additional zone has a
negative impact to the production environment. Not only is additional network traffic generated to support an
additional zone, but the configuration of those servers, e.g., hotfixes, can impact the capabilities and
communication flows. As such, it is advisable that organizations segregate test and development
environments into a distinct server farm.
Optimizing Data Store Communication: Communications with the Data Store are not impacted by the zone
configuration. Each server communicated directly or indirectly with the Data Store, and zone configuration has
no bearing on that communications flow.
Business Separation: In many organizations, multiple departments unite to create an integrated Presentation
Server farm, but each group still wants to maintain direct control over their resources. Organizations utilize
zones as a means of business delineation or security boundary, which it is not. In these circumstances, zones
should not be created, but instead delegated administration and folder usage within the management consoles
is warranted.
Network Infrastructure Limitations. Designing a single farm with multiple zones to support multiple sites
typically assumes there is sufficient network bandwidth available to support IMA traffic and inter-zone
communications. However, it is important to take into consideration the quality of the network connection. If the
network connection is so poor that intra-zone or inter-zone communications cannot occur, this type of a
situation might warrant multiple farms or a single farm with an integrated WAN optimization solution, like Citrix
WANScaler. The network quality issue is a typical problem with satellite links and links to international sites.
Security and Regulatory Compliance: Divisions with high security standards may need to segregate their IT
infrastructure based on security level: low, medium, high, and/or top secret. Other types of divisions may need to
comply with government regulations such as FDA, HIPAA, Sarbanes/Oxley, etc. Each division may interpret the
government regulations differently and they end up building their IT infrastructure based on these interpretations. Adding
new zones for each group is not the best solution as zones are not meant for configuration or security boundaries. Either
delegated administration or multiple farms is recommended.

Conclusion
When designing a Citrix Presentation Server 4.5 environment, the pros (Zone Preference and Failover) and cons (network
traffic impact) must be weighed. Only when taking these items into account will an architect be able to select the best
design for the organization, which could be the creation of a new zone, the collapsing of zones, or the creation of a new
farm.
 5

Notice
The information in this publication is subject to change without notice.
THIS PUBLICATION IS PROVIDED AS IS WITHOUT WARRANTIES OF ANY KIND, EXPRESS OR IMPLIED,
INCLUDING ANY WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE OR NON-
INFRINGEMENT. CITRIX SYSTEMS, INC. (CITRIX), SHALL NOT BE LIABLE FOR TECHNICAL OR EDITORIAL
ERRORS OR OMISSIONS CONTAINED HEREIN, NOR FOR DIRECT, INCIDENTAL, CONSEQUENTIAL OR ANY
OTHER DAMAGES RESULTING FROM THE FURNISHING, PERFORMANCE, OR USE OF THIS PUBLICATION,
EVEN IF CITRIX HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES IN ADVANCE.
This publication contains information protected by copyright. Except for internal distribution, no part of this publication
may be photocopied or reproduced in any form without prior written consent from Citrix.

The exclusive warranty for Citrix products, if any, is stated in the product documentation accompanying such products.
Citrix does not warrant products other than its own.

Product names mentioned herein may be trademarks and/or registered trademarks of their respective companies.
Copyright 2007 Citrix Systems, Inc., 851 West Cypress Creek Road, Ft. Lauderdale, Florida 33309-2009
U.S.A. All rights reserved.

Version History
Author Version Change Log Date
Daniel Feller Version 1.0 Content created January 22, 2006
Daniel Feller Version 1.1 Updated to include new calculations April 24, 2006
Daniel Feller Version 1.2 Validated for Version 4.5. Formulas, calculations and tables were September 24, 2007
all updated.

851 West Cypress Creek Road Fort Lauderdale, FL 33309 954-267-3000 http://www.citrix.com

Copyright 2007 Citrix Systems, Inc. All rights reserved. Citrix, the Citrix logo, Citrix ICA, Citrix MetaFrame, and other Citrix product names are
trademarks of Citrix Systems, Inc. All other product names, company names, marks, logos, and symbols are trademarks of their respective owners.