Sep. 22, 2016
Deployments that span widely-dispersed locations connected by a WAN can face challenges due to network latency and reliability. There are two options that mitigate those challenges:
This option is recommended for large enterprise deployments. Multiple Sites are managed separately, and each requires its own SQL Server Site database. Each Site is a separate XenApp deployment.
Configuring zones can help users in remote regions connect to resources without necessarily forcing their connections to traverse large segments of the WAN. Using zones allows effective Site management from a single Citrix Studio console, Citrix Director, and the Site database. This saves the costs of deploying, staffing, licensing, and operating additional Sites containing separate databases in remote locations.
Zones can be helpful in deployments of all sizes. You can use zones to keep applications and desktops closer to end users, which improves performance. A zone can have one or more Controllers installed locally for redundancy and resiliency, but it is not required.
Throughout this article the term local refers to the zone being discussed. For example, "A VDA registers with a local Controller" means that a VDA registers with a Controller in the zone where the VDA is located.
Zones in this release are similar, but not identical to zones in XenApp version 6.5 and earlier. For example, in this implementation of zones, there are no data collectors. All Controllers in the Site communicate with one Site database in the primary zone. Also, failover and preferred zones work differently in this release.
A Site always has one primary zone. It can also optionally have one or more satellite zones. Satellite zones can be used for disaster recovery, geographically-distant datacenters, branch offices, a cloud, or an availability zone in a cloud.
The primary zone has the default name "Primary," which contains the SQL Server Site database (and high availability SQL servers, if used), Studio, Director, Citrix StoreFront, Citrix License Server, and NetScaler Gateway. The Site database should always be in the primary zone.
The primary zone should also have at least two Controllers for redundancy, and may have one or more VDAs with applications that are tightly-coupled with the database and infrastructure.
A satellite zone contains one or more VDAs, Controllers, StoreFront servers, and NetScaler Gateway servers. Under normal operations, Controllers in a satellite zone communicate directly with the database in the primary zone.
A satellite zone, particularly a large one, might also contain a hypervisor that is used to provision and/or store machines for that zone. When you configure a satellite zone, you can associate a hypervisor or cloud service connection with it. (Be sure any Machine Catalogs that use that connection are in the same zone.)
A Site can have different types of satellite zones, based on your unique needs and environment. The following figure illustrates a primary zone and examples of satellite zones.
Satellite zone 1 contains a Controller, VDAs, and a StoreFront server. VDAs in this satellite zone register with the local Controller. The local Controller communicates with the Site database and license server in the primary zone.
If the WAN fails, the connection leasing feature allows the Controller in the satellite zone to continue brokering connections to VDAs in that zone. Such a deployment can be effective in an office where workers use a local StoreFront site and the local Controller to access their local resources, even if the WAN link connecting their office to the corporate network fails.
Satellite zone 2 contains two Controllers, VDAs, and a StoreFront server. This is the most resilient zone type, offering protection against a simultaneous failure of the WAN and one of the local Controllers.
In a Site containing primary and satellite zones, with VDAs at minimum version 7.7:
If all Controllers in the primary zone fail:
For Sites containing VDA versions earlier than 7.7:
Important: To use the zone preference feature, you must be using minimum StoreFront 3.7 and NetScaler Gateway 11.0-65.x.
In a multi-zone Site, the zone preference feature offers the administrator more flexibility to control which VDA is used to launch an application or desktop.
How zone preference works
There are three forms of zone preference. You might prefer to use a VDA in a particular zone, based on:
The following graphic shows an example multi-zone configuration.
In this example, VDAs are spread among three satellite zones, but they are all in the same Delivery Group. Therefore, the broker might have a choice which VDA to use for a user launch request. This example indicates where are a number of locations where users can be running their Citrix Receiver endpoints: User A is using a device with Citrix Receiver in satellite zone 1; User B is using a device in satellite zone 2. A user's documents could be stored in a number of locations: Users A and B use a share based in satellite zone 1; User C uses a share from satellite zone C. Also, one of the published applications uses a database located in satellite zone 1.
You associate a user or application with a zone by configuring a home zone for the user or application. The broker in the Delivery Controller then uses those associations to help select the zone where a session will be launched, if resources are available. You:
A user or an application can have only one home zone at a time. (An exception for users can occur when multiple zone memberships occur because of user group membership; see the "Other considerations" section. However, even in this case, the broker uses only one home zone.)
Although zone preferences for users and applications can be configured, the broker selects only one preferred zone for a launch. The default priority order for selecting the preferred zone is application home > user home > user location. (You can restrict the sequence, as described in the next section.) When a user launches an application:
Tailoring zone preference
When you configure (or remove) a home zone for a user or an application, you can also further restrict how zone preference will (or will not) be used.
How preferred zones affect session use
When a user launches an application or desktop, the broker prefers using the preferred zone rather than using an existing session.
If the user launching an application or desktop already has a session that is suitable for the resource being launched (for example, that can use session sharing for an application, or a session that is already running the resource being launched), but that session is running on a VDA in a zone other than the preferred zone for the user/application, then the system may create a new session. This satisfies launching in the correct zone (if it has available capacity), ahead of reconnecting to a session in a less-preferred zone for that user's session requirements.
To prevent an orphan session that can no longer be reached, reconnection is allowed to existing disconnected sessions, even if they are in a non-preferred zone.
The order of desirability for sessions to satisfy a launch is:
Other zone preference considerations
If a user has a configured home zone that was not acquired through group membership, that zone is used for zone preference. Any zone associations acquired through group membership are ignored.
If the user has multiple different zone associations acquired solely through group membership, the broker chooses among the zones randomly. Once the broker makes this choice, that zone is used for subsequent session launches, until the user's group membership changes.
A Full Administrator can perform all zone creation and management tasks. However, you can also create a custom role that allows you to create, edit, or delete a zone. Moving items between zones does not require zone-related permissions (except zone read permission); however, you must have edit permission for the items you are moving. For example, to move a Machine Catalog from one zone to another, you must have edit permission for that Machine Catalog. For more information, see the Delegated Administration article.
If you use Provisioning Services: The Provisioning Services console provided with this release is not aware of zones, so Citrix recommends using Studio to create Machine Catalogs that you want to place in satellite zones. Use the Studio wizard to create the catalog, specifying the correct satellite zone. Then, use the Provisioning Services console to provision machines in that catalog. (If you create the catalog using the Provisioning Services wizard, it will be placed in the primary zone, and you will need to use Studio to move it to the satellite zone later.)
As an alternative to this method, you can select one or more items in Studio and then select Create Zone in the Actions pane.
A confirmation message lists the items you selected and asks if you are sure you want to move all of them.
Remember: When a Machine Catalog uses a host connection to a hypervisor or cloud service, both the catalog and the connection should be in the same zone. Otherwise, performance can be affected. If you move one, move the other, too.
A zone must be empty before it can be deleted. You cannot delete the primary zone.
Configuring a home zone for a user is also known as adding a user to a zone.
For users with a configured home zone, you can require that sessions launch only from their home zone:
All sessions launched by a user in that Delivery Group must launch from machines in that user's home zone. If a user in the Delivery Group does not have a configured home zone, this setting has no effect.
This procedure is also known as removing a user from a zone.
Configuring a home zone for an application is also known as adding an application to a zone. By default, in a multi-zone environment, an application does not have a home zone.
An application's home zone is specified in the application's properties. You can configure application properties when you add the application to a group or later, by selecting the application in Studio and editing its properties.
On the Zones page of the application's properties/settings:
When you add a host connection or create a Machine Catalog (other than during Site creation), you can specify a zone where the item will be assigned, if you have already created at least one satellite zone.
In most cases, the primary zone is the default. When using Machine Creation Services to create a Machine Catalog, the zone that is configured for the host connection is automatically selected.
If the Site contains no satellite zones, the primary zone is assumed and the zone selection box does not appear.