XenApp and XenDesktop 7.7: Zones Deep Dive
This article goes a little deeper into how the zones feature works in XenApp and XenDesktop 7.7, as well as the implications of putting items like Delivery Controllers, hypervisor connections, and machine catalogs into different zones. It may be useful to first read about zones in the Citrix product documentation: https://docs.citrix.com/en-us/categories/legacy-archive/xenapp-and-xendesktop.html.
Primary and satellite zones
Each XenApp and XenDesktop 7.7 Site has one primary zone, which should include the central Site database and at least two Delivery Controllers.
Secondary, or satellite zones, should include one or more VDAs, Controllers, StoreFront servers, and NetScaler Gateway servers. 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
A number of different elements in a XenApp or XenDesktop deployment can be associated with a satellite zone, which then affects how the 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
- Machine 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 machine 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 other satellite zones.
NetScaler Gateway instances can also be associated with zones, but this is done as part of the StoreFront Optimal HDX Routing configuration rather than, as for the other elements described here, as part of the XenApp or XenDesktop Site configuration. When a NetScaler Gateway is associated with a zone, it means that it is preferred to be used when HDX connections to VDA machines in that zone are used.
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, 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 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 1,000||30||2 Mbps||50 ms|
|1,000 to 3,000||60||8 Mbps||10 ms|
|Over 3,000||60||8 Mbps||5 ms|
High availability with connection leasing
In XenApp and XenDesktop 7.7, the connection leasing feature can help maintain high availability of brokering new connections to end users if there’s a system outage. If you’re using zones, the outage could be caused by a communications loss between a satellite zone and the primary zone (particularly as the database resides in the primary zone). In this case, the satellite zone’s Controllers will switch into leasing mode 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. To limit the file system load for Controller machines in satellite zones, only connection-lease data for VDA machines in that same zone.
If you want to take advantage of the high availability of brokering using connection leasing, when a satellite zone is isolated from the primary zone, it’s 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 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 this, it is recommended to limit the number of zones in your XenApp or XenDesktop 7.7 Site to no more than 10. In XenApp or XenDesktop 7.11 and later versions, the limit is 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 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 delayed launches due to a backlog of earlier launches.
There have been some reports that the zones node in Studio has disappeared after upgrading a Site. This may be because the “role configuration” file failed to import during the upgrade. You can fix this 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
This article has been modified from a blog post written by William Charnell. To read the original blog and to see the comments, go to https://www.citrix.com/blogs/2016/01/12/deep-dive-xenapp-and-xendesktop-7-7-zones/?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+CitrixBlogs+%28Citrix+Blogs%29.