One of the new features of the 7.7 release of XenApp and XenDesktop is the ability to define ‘zones’ in a site and to place elements from the site into different zones.
The motivation behind this feature is described in a separate blog, but this article goes a little deeper into how this all works and what the implications are when you put items such as controllers, hypervisor connections and catalogs into zones.
Primary and Satellite Zones
Each XenApp and XenDesktop site has exactly one primary zone; the primary zone should be where the single central site database for the site exists, and there should be at least one controller in the primary zone.
In addition to the single primary zone, a site can have zero or more secondary or satellite zones. Controllers in the primary zone are assumed to have good connectivity to the site database, and also assumed to 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 in the site.
Elements that can be associated with Zones
A number of different classes of object in a XenApp or XenDesktop deployment can be associated with a satellite zone, which then affects how the XenApp or XenDesktop site interacts with those objects and other objects related to them. The elements that can be placed into satellite zones are:
- Controller machines
- Hypervisor Connections
- Catalogs
- NetScaler Gateways
When controller machines are placed into a satellite zone, it is then assumed that those machines have good (local) connectivity to hypervisors and VDA machines in the same satellite zone, and so the system arranges things to prefer to use those controllers for handling those hypervisors and VDA machines.
The hypervisor connection being placed into a satellite zone implies that all the hypervisors managed via that hypervisor connection are also assumed to reside in that satellite zone, and controllers in that zone are preferred to be used when communicating with that hypervisor connection. A catalog being placed into a satellite zone similarly implies that all the VDA machines in that catalog are in the satellite zone, and this will also control which controllers are preferred to be used when attempting to register with the site after the controller list auto-update mechanism has activated after the first registration of each VDA.
VDAs will prefer to register with controllers in the same local zone as themselves, but will fail over to registering with controllers in the primary zone. VDAs will not register with controllers in different satellite zones.
NetScaler Gateway instances can also be associated with zones, but this is done as part of the configuration of StoreFront rather than, as for the other element described here, being done as part of the XenApp or XenDesktop site configuration. When a NetScaler gateway is associated with a zone, it means that that gateway is preferred to be used when HDX connections to VDA machines in that zone are used, and it is configured as part of the StoreFront ‘Optimal HDX Routing’ configuration.
Connection Quality Limits
The controllers in the satellite zone perform SQL interactions with the site database directly. While some changes have been made to minimise this SQL interaction, this 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 again 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 small number of VDAs and sessions can function with a poorer quality connection back to the database than satellite zones with large numbers of VDAs and sessions. Some guidelines are:
| Number of Sessions to be Supported | Assumed Maximum Concurrent End User Session Launches | Minimum Acceptable Bandwidth | Maximum Acceptable Round -Trip Latency |
| Less than 50 | 20 | 1 Mbps | 250 ms |
| 50 to 500 | 25 | 1.5 Mbps | 100 ms |
| 500 to 1000 | 30 | 2 Mbps | 50 ms |
| 1000 to 3000 | 60 | 8 Mbps | 10 ms |
| Over 3000 | 60 | 8 Mbps | 5 ms |
The above numbers are from preliminary testing results and we hope to be releasing some more comprehensive numbers and guidelines in the near future.
High Availability
In XenApp 7.7 and XenDesktop 7.7, the connection leasing feature is available to support maintaining high availability of brokering new connections to end users while there is some form of system outage. With zones, the cause of the outage could now be loss of communications between a satellite zone and the primary zone, particularly as the database resides in the primary zone. In this case, the controllers in the satellite zone will switch into leasing mode and still allow end users to broker new connections to applications and desktops, as long as the VDAs that those app and desktop sessions would run on are still accessible from the satellite zone controllers being used. To limit the file system load for controller machines in satellite zones, only connection lease data for VDA machines in that same zone or in the primary zone are replicated to controllers in satellite zones.
Numbers of Zones
The number of controllers configured into the site can be seen to have some effect on the performance of some operations, such as adding new controllers to the site itself. In order to avoid this it is recommended to limit the number of zones configured in the site, with the 7.7 release, to no more than 10 zones.
StoreFront deployment
In order to take advantage of the high availability of brokering, using connection leasing, when a satellite zone is isolated from the primary zone, it will be necessary to deploy a StoreFront instance in each satellite zone. This is because a centrally deployed StoreFront instance in the primary zone alone would not necessarily be able to contact the controllers in the satellite zones if the connectivity between the primary and satellite zones in disrupted in an outage.
Low Level Configuration Settings and Tweaks
A few 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 zones 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 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 new registry setting has been added to allow control of a throttling of concurrent end user launches; the primary part of this 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, could lead to launches experiencing long delays due to a backlog of earlier launches being dealt with.
Other Tips
There have been some reports that after upgrading a site the zones node is not present in Studio, and this can be due in some cases to a part of the upgrade having failed when the updated ‘role configuration’ file failed to be imported. This can be fixed by manually performing the import of the new 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