• View Communities
    • Citrix Developer Network
      The place for unfiltered straight talk on Citrix products. Blogs, code downloads, best practices, APIs, and more can all be found here.
    • Citrix Ready Community Verified
      Does it work with Citrix? Application compatibility questions are a thing of the past with the new Citrix Community Verified site.
    • Blogs
      Learn the latest from the Citrix employees who are building application delivery infrastructure technologies.
    • Blogosphere
      The Citrix Blogosphere is a window into the thousands of conversations taking place about Citrix and Application Delivery.
  •  Sign In
XenApp Developer Network

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 Communication

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.

  1. Full Update: Member Server -> Data Collector
  2. Full Update: Data Collector -> Data Collector
  3. Session Update: Member Server -> Data Collector
  4. 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:

  1. When a member server is brought online
  2. 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:
  • Connections are per server
  • Disconnections are per server
  • Apps are published applications per server

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:

  1. 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:
  • 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
Disconnection
Reconnection
Logoff

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:

  1. Number of servers: 100
  2. Number of published applications: 240
  3. Average number of published applications per server: 30
  4. Average number of connected users per server: 50
  5. Average number of disconnected users per server: 2
  6. Average number of connections per hour per server: 30
  7. Average number of disconnections per hour per server: 15
  8. Average number of reconnections per hour per server: 10
  9. 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 collector's 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
  • 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.

[adi:1]All calculations assume zones do NOT share load information

Tags

farms farms Delete
xenapp xenapp Delete
zones zones Delete
cps cps Delete
best practices best practices Delete
Enter tags to add to this page:
Please wait 
Looking for a tag? Just start typing.
Related Links