Zones within Citrix infrastructures are logical segments within a Citrix farm. Every zone has a data collector (described in the next paragraph). Servers in a zone will communicate with his zone data collector where the data collectors of every zone will exchange information which each other about his zones.

When determine the needs for zones and the amount of zones used the following considerations:

• Available bandwidth

When there is limited bandwidth available the traffic between the servers within one zone can be too much for the network link. If this is the case it is a good idea to create zones to regulate the traffic of the Citrix infrastructure.

Zones are useful in traffic controlling.

• Amount of changes in the Farm

Every change made in the farm is logically distributed to the Citrix server to reflect the changed settings. How more changes are made logically more traffic is generated between the Citrix servers. Together with the available bandwidth the amount of changes can be a reason to divide the farm into zones.

• Citrix advices a maximum of 25 zones

There is a limitation on the amount of zones. Citrix advises not to create more than 25 zones.

• Citrix Policy “Zone Preferences”

Within the enterprise edition there is a policy available that makes it possible to route users automatically to another (set of) server(s) if the Published Application is not available on the first group. This policy based on zones, so if you would like to use this policy zones are necessary.

• Load Sharing between servers

When using zones load sharing between servers can be arranged in two ways. There is a possibility to share the load over all servers despite if there are zones configured or the load is shared between servers in de zone only. Using the first method the session of the user can be started on any server, while using the second methodology the users will be redirected to the server in the zone of the data collector, which handled his request.

• Each zone needs to have a Data Collector

Remember that each zone needs a data collector. Although every server can facilitate the role of data collector logically this role requires some resources available to carry out the tasks. Keep this in mind when determine the amount of servers to host the applications and check the considerations in the next paragraph about the data collector.

Best practices concerning the zones are using as less zone as possible, use zones only when low bandwidth connections are available between servers and/or if the zone preferences policy is necessary for your environment (for example when using a back-up/disaster site).

Data Collector Architecture & Design

The data collector is a role on a Citrix XenApp server which is collecting, maintaining and managing dynamic information about the farm and zone. The data collector also passes the user to the least busy server. Every Citrix XenApp server can be facilitating the server role, but of course some resources are needed for this role.

When creating the design the following topics should be considered.

• Dedicated Data Collector versus Non Dedicated Data Collector

Dependent on the size of the Citrix infrastructure (based on the amount of server, amount of users and logon/logoff activities) a decision should be made to use a dedicated server or a non dedicated server. A dedicated data collector is a server with Citrix XenApp installed, but the server is not hosting any Published Applications or Desktops. When using a Non Dedicated Data Collector think of using a different Load Evaluator with lower values. Also do not remember that data collector role should be assigned within the farm settings.

• Back-up Data Collector

When the primary data collector fails or is unavailable the Citrix farm will organize an election to select a new data collector. The election is primary based on settings about the data collector role, but also on the version of the software and (some) hot fixes. Again dependent the back-up data collector can be dedicated server or a shared server.

• Amount of Zones

As mentioned earlier in the zones part every zone has a data collector. When you have lots of zones you probably will choose for a non dedicated data collector in comparison with situations when there is/are just one or two zones.

• Designing Zones for a XenApp Deployment

A zone is a configurable grouping of XenApp servers. All farms have at least one zone. All servers must belong to a zone. Unless otherwise specified during XenApp Setup, all servers in the farm belong to the same zone, which is named Default Zone.

Zones have two purposes:

• Collect data from member servers in a hierarchical structure
• Efficiently distribute changes to all servers in the farm

Each zone contains a server designated as its data collector. Data collectors store information about the zone’s servers and published applications. In farms with more than one zone, data collectors also act as communication gateways between zones.

This illustration depicts a server farm with multiple zones. Each zone’s data collector communicates with the other data collectors across the WAN link.

Because session and load information within a XenApp farm can become large in enterprise deployments—up to several megabytes—to ensure a scalable and resilient XenApp farm, it is imperative that you design zones based on your network topology.

XenApp member servers replicate their dynamic data to the ZDC designated for their zone. XenApp uses a star topology for replication among zones—each ZDC replicates all of its zone dynamic data to all other ZDCs in the farm. Thus, it is important to design zones so that there is adequate bandwidth among ZDCs.

When designing zones, the most important variables to consider are latency and bandwidth. The amount of bandwidth and the impacts of latency are highly dependent on your XenApp deployment. The lower the bandwidth and the higher the latency, the longer a farm takes to resynchronize the dynamic data among zones after an election.

In farms distributed across WANs, zones enhance performance by grouping geographically related servers together. Citrix does not recommend having more than one zone in a farm unless it has servers in geographically distributed sites. Zones are not necessary to divide large numbers of servers. There are 1000-server farms that have only one zone.

Data collectors generate a lot of network traffic because they communicate with each other constantly:

• Each zone data collector has an open connection to all data collectors in the farm.
• During a zone update, member servers update the data collector with any requests and changed data.
• Data collectors relay changes to the other data collectors. Consequently, data collectors have the session information for all zones.

In general, Citrix recommends using the fewest number of zones possible, with one being optimal. If all farm servers are in one location, configuring only one zone for the farm does not reduce performance or make the farm harder to manage. However, in large networks, such as organizations with data centers on different continents, grouping geographically-related servers in zones can improve farm performance.

Keep in mind that data collectors must replicate changes to all other data collectors in the farm. Also, bandwidth consumption and network traffic increase with the number of zones.

Separate zones are not required for remote sites, even ones on separate continents; latency is the biggest factor in determining if servers should be put in their own zone. For large farms with servers in different geographic regions, create zones based on the location of significant numbers of servers.

Also decide if you want to configure failover zones or preferred zones. If a zone fails, you can configure for user connections to be redirected to another zone (failover) or control to which zones specific users connect (preference). Failover requirements might determine the number of zones required.

For example, an organization with 20 farm servers in London, 50 servers in New York, and three servers in Sydney could create two or three zones. If the Sydney location has good connectivity to either New York or London, Citrix recommends grouping Sydney with the larger location. Conversely, if the WAN connection between Sydney and the other locations is poor, and zone preference and failover is required, Citrix recommends configuring three zones.

Consider these zone design guidelines:

• Minimize the number of zones in your farm.
• Create zones for major datacenters in different geographic regions.
• If a site has a small number of servers, group that site in a larger site’s zone.
• If your organization has branch offices with low bandwidth or unreliable connectivity, do not place those branch offices in their own zone. Instead, group them with other sites with which they have the best connectivity. When combined with other zones, this might form a hub-and-spoke zone configuration.
• If you have more than five sites, group the smaller sites with the larger zones. Citrix does not recommend exceeding five zones.