Citrix Virtual Apps and Desktops - Zones Deep Dive

This article goes into depth on how zones work in Citrix Virtual Apps and Desktops environments. We also discuss the implications of putting items like delivery controllers, hypervisor connections, and machine catalogs into different zones. You might want to start by reading about zones in the Citrix product documentation.

Primary and satellite zones

Each site has one primary zone, which includes the central Site database and at least two Delivery Controllers.

Secondary, or satellite zones, include one or more VDAs, Controllers, StoreFront servers, and NetScaler Gateways. Under normal operations, Controllers in a satellite zone communicate directly with the central Site database in the primary zone.

Controllers in the primary zone are assumed to have good connectivity to the Site database and have some connectivity to all satellite zones. But elements in each satellite zone are not assumed to have connectivity to elements in other satellite zones.

Elements that can be associated with zones

Several elements in a deployment can be associated with a satellite zone. The elements in the satellite zone affect how the Site interacts with those elements and other objects related to them. The elements that can be placed into satellite zones are:

• Controller machines
• Hypervisor connections
• Machine catalogs
• NetScaler Gateway

When Controller machines are placed into a satellite zone, it is assumed those machines have good local connectivity to hypervisors and VDA machines in the same satellite zone. Assuming good local connectivity, the system arranges a preference to use the Controllers within the zone for handling those hypervisors and VDA machines.

When the hypervisor connection is placed into a satellite zone, all hypervisors managed with that hypervisor connection are also assumed to reside in that satellite zone. Controllers in that zone are preferred for communication with that hypervisor connection.

A machine catalog placed in a satellite zone similarly implies that all VDA machines in that catalog are in the satellite zone. After the first registration of each VDA, the Controller list auto-update mechanism activates. Satellite zone placement also determines which Controllers are preferred when VDAs register with the Site.

VDAs prefer to register with Controllers within their local zone and fail over to registering with Controllers in the primary zone. VDAs do not register with Controllers in other satellite zones.

NetScaler Gateway instances can also be associated with zones, but the Gateway association is made in the StoreFront Optimal HDX Routing configuration rather than, as for the other elements described here, as part of the Site configuration. When a NetScaler Gateway is associated with a zone, it means that the zone's Gateway is preferred for HDX connections to VDA machines in that zone.

Connection quality limits

The Controllers in the satellite zone perform SQL interactions directly with the Site database. While some changes have been made to minimize this SQL interaction, it does impose some limits on the quality of the link between the satellite zone and the primary zone containing the database. The specific limits are relative to the number of VDAs and user sessions on those VDAs that are deployed in the satellite zone. So satellite zones with only a few VDAs and sessions can function with a poorer-quality connection to the database than satellite zones with large numbers of VDAs and sessions. Some guidelines are:

High availability with local host cache

Local host cache can help maintain high availability of brokering new connections to end users if there’s a system outage. If you’re using zones, a communication loss between a satellite zone and the primary zone might cause the outage, because the database resides in the primary zone. In this case, the satellite zone’s Controllers switch to local host cache and still allow end users to broker new connections to applications and desktops. The VDAs that those sessions run on, however, must be accessible from the Controllers in the satellite zone.

Among its other tasks, the Citrix Config Synchronizer Service (CSS) routinely provides the High Availability Service with information about all Controllers in the zone. Having that information, each High Availability Service knows about all peer High Availability Services.

The High Availability Services communicate with each other on a separate channel. They use an alphabetical list of FQDN names of the machines they’re running on to determine (elect) which High Availability Service is in charge of brokering operations in the zone if an outage occurs. During the outage, all VDAs re-register with the elected High Availability Service. The non-elected High Availability Services in the zone actively reject incoming connection and VDA registration requests.

If an elected High Availability Service fails during an outage, another High Availability Service is elected to take over, and VDAs re-register with the newly elected High Availability Service.

During an outage, if a Controller is restarted:

• If that Controller is not the elected primary broker, the restart has no impact.
• If that Controller is the elected primary broker, a different Controller is elected, causing VDAs to re-register. After the restarted Controller powers on, it automatically takes over brokering, which causes VDAs to re-register again. In this scenario, performance might be affected during the re-registrations.
• If you power off a Controller during normal operations and then power it on during an outage, Local Host Cache cannot be used on that Controller if it is elected as the primary broker.

StoreFront deployment

If you want to take advantage of the high availability of brokering when a satellite zone is isolated from the primary zone, deploy a StoreFront instance in each satellite zone. The StoreFront instance is needed in the satellite zone because a single StoreFront instance in the primary zone alone cannot contact the Controllers in the satellite zones if the connectivity between the primary and satellite zones is disrupted in an outage.

Numbers of zones

The number of Controllers configured in the Site can affect the performance of some operations, such as adding new Controllers to the Site itself. To avoid compromised performance, it is recommended to limit the number of zones in your Site to no more than 50.

Low-level configuration settings and tweaks

Some new configuration items have been added to support zones, including adding the definition of zones at the PowerShell SDK level, which is part of the configuration service SDK rather than, for example, being part of the Broker Service SDK. Other parts of the zone configuration can be done in other FMA service PowerShell SDKs, particularly where elements are associated with zones, which is done by the service that has most ownership of those objects. Consequently, the zone membership of machine catalogs is defined using the Broker Service SDK, and the zone membership of hypervisor connections is configured using the host service SDK.

In addition, a registry setting is available to allow control of throttling concurrent end user launches. The primary part of the registry setting is at HKLM\\Software\\Citrix\\DesktopServer\\ThrottledRequestAddressMaxConcurrentTransactions. In some test situations, we found that high latencies between satellite zones and the database in the primary zone, coupled with a relatively high rate of app and desktop connection launches by end users using a Controller in the satellite zone, led to delayed launches due to a backlog of earlier launches.

Other tips

There have been some reports that the zones node in Studio has disappeared after upgrading a Site. The zones node sometimes disappears because the role configuration file failed to import during the upgrade. You can fix the failed import manually by importing the file via the PowerShell SDK:

cd 'C:\Program Files\Citrix\XenDesktopPoshSdk\Module\Citrix.XenDesktop.Admin.V1\Citrix.XenDesktop.Admin\StudioRoleConfig'
Import-AdminRoleConfiguration –Path .\RoleConfigSigned.xml