Zones 编辑

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:

• Deploy multiple sites, each with their own SQL Server site database.

  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 Citrix Virtual Apps deployment.

• Configure multiple zones within a single site.

  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 more 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.

  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, we recommend that you limit the number of zones in your Citrix Virtual Apps or Citrix Virtual Desktops site to no more than 50.

  When the network latency of your zones is more than 250 ms RTT, we recommend that you deploy multiple sites instead of zones.

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.

Zone types

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 data centers, branch offices, a cloud, or an availability zone in a cloud.

Primary zone:

The primary zone has the default name “Primary”. This zone contains the SQL Server site database (and high availability SQL servers, if used), Studio, Director, Citrix StoreFront, Citrix License Server, and Citrix Gateway. Always keep the site database in the primary zone.

The primary zone should have at least two Controllers for redundancy. The primary zone can have VDAs with applications that are tightly coupled with the database and infrastructure.

Satellite zone:

A satellite zone contains one or more VDAs, Controllers, StoreFront servers, and Citrix 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 store machines for that zone. When you configure a satellite zone, you can associate a hypervisor or other service connection with it. (Be sure any catalogs that use that connection are in the same zone.)

A site can have satellite zones of different configurations, based on your unique needs and environment. The following figure illustrates a primary zone and examples of satellite zones.

In the illustration:

• Primary zone: Contains two Controllers, Studio, Director, StoreFront, License Server, and the site database (plus high availability SQL Server deployments). The Primary zone also contains several VDAs and a Citrix Gateway.

• Satellite zone 1: VDAs with Controller: 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 Local Host Cache 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.

• Satellite zone 2: VDAs with redundant Controllers: 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.

Where VDAs register and where Controllers fail over

In a site containing primary and satellite zones, with VDAs at minimum version 7.7:

• A VDA in the primary zone registers with a Controller in the primary zone. A VDA in the primary zone never attempts to register with a Controller in a satellite zone.
• A VDA in a satellite zone registers with a local Controller, if possible. (This is considered the preferred Controller.) If no local Controllers are available (for example, because they cannot accept more VDA registrations or they have failed), the VDA will attempt to register with a Controller in the primary zone. In this case, the VDA stays registered in the primary zone, even if a Controller in a satellite zone becomes available again. A VDA in a satellite zone never attempts to register with a Controller in another satellite zone.
• When auto-update is enabled for VDA discovery of Controllers, and you specify a list of Controller addresses during VDA installation, a Controller is randomly selected from that list for initial registration (regardless of which zone the Controller resides in). After the machine with that VDA is restarted, the VDA will start to prefer registering with a Controller in its local zone.
• If a Controller in a satellite zone fails, it fails over to another local Controller, if possible. If no local Controllers are available, it fails over to a Controller in the primary zone.
• If you move a Controller in or out of a zone, and auto-update is enabled, VDAs in both zones receive updated lists indicating which Controllers are local and which are in the primary zone, so they know with whom they can register and accept connections from.
• If you move a catalog to another zone, the VDAs in that catalog re-register with Controllers in the zone where you moved the catalog. (When you move a catalog to another zone, make sure this zone and the zone with the associated host connection are well connected. If there is limited bandwidth or high-latency, move the host connection to the same zone containing the associated machine catalog.)

If all Controllers in the primary zone fail:

• Studio cannot connect to the site.
• Connections to VDAs in the primary zone cannot be made.
• Site performance degrades until the Controllers in the primary zone become available.

For sites containing VDA versions earlier than 7.7:

• A VDA in a satellite zone accepts requests from Controllers in their local zone and the primary zone. (VDAs at minimum version 7.7 can accept Controller requests from other satellite zones.)
• A VDA in a satellite zone registers with a Controller in the primary zone or the local zone at random. (VDAs at minimum version 7.7 prefer the local zone.)

Zone preference

To use the zone preference feature, you must be using minimum StoreFront 3.7 and Citrix 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:

• Where the application’s data is stored. This is referred to as the application home.
• The location of the user’s home data, such as a profile or home share. This is referred to as the user home.
• The user’s current location (where the Citrix Workspace app is running). This is referred to as the user location.

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 there are several locations where users can be running their Citrix Workspace app endpoints:

• User A is using a device with Citrix Workspace app in satellite zone 1.
• User B is using a device in satellite zone 2.

• A user’s documents can be stored in various locations.

  • Users A and B use a share based in satellite zone 1.
  • User C uses a share from satellite zone C.
  • 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 can:

• Configure the home zone for a user by adding a user to a zone.
• Configure the home zone for an application by editing the application properties.

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; see Tailoring zone preference. When a user launches an application:

• If that application has a configured zone association (an application home), then the preferred zone is the home zone for that application.
• If the application does not have a configured zone association, but the user has a configured zone association (a user home), then the preferred zone is the home zone for that user.
• If neither the application nor the user has a configured zone association, then the preferred zone is the zone where the user is running a Citrix Workspace app instance (the user location). If that zone is not defined, a random VDA and zone selection is used. Load balancing is applied to all VDAs in the preferred zone. If there is no preferred zone, load balancing is applied to all VDAs in the Delivery Group.

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 is used.

• Mandatory user home zone use: In a Delivery Group, you can specify that a sessions launch in the user’s home zone (if configured), with no failover to another zone if the home zone doesn’t have available resources. This restriction is helpful when you must avoid the risk of copying large profiles or data files between zones. In other words, you would rather deny a session launch than to launch the session in a different zone.
• Mandatory application home zone use: Similarly, when you configure a home zone for an application, you can indicate that the application be launched only in that zone, with no failover to a different zone if resources are not available in the application’s home zone.
• No application home zone, and ignore configured user home zone: If you do not specify a home zone for an application, you can also indicate that no configured user zones be considered when launching that application. For example, you might prefer that users run an application on a VDA near their device, using the user location zone preference, even though some users might have a different home zone.

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 might 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:

1. Reconnect to an existing session in the preferred zone.
2. Reconnect to an existing disconnected session in a zone other than the preferred zone.
3. Start a new session in the preferred zone.
4. Reconnect to a connected existing session in a zone other than the preferred zone.
5. Start a new session in a zone other than the preferred zone.

Other zone preference considerations

• If you configure a home zone for a user group (such as a security group), that group’s users (through direct or indirect membership) are associated with the specified zone. However, a user can be a member of multiple security groups, and therefore might have a different home zone configured through other group membership. In such cases, determination of that user’s home zone can be ambiguous.

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.

• The user location zone preference requires detection of Citrix Workspace app on the endpoint device by the Citrix Gateway through which that device is connecting. The Citrix Gateway must be configured to associate ranges of IP addresses with particular zones, and discovered zone identity must be passed through StoreFront to the Controller.

For more information about zone preference, see Zone preference internals.

Considerations, requirements, and best practice

• You can place the following items in a zone: Controllers, machine catalogs, host connections, users, and applications. If a catalog uses a host connection, be sure the catalog and the connection are in the same zone. (However, with a low-latency high-bandwidth connection available, they can be in different zones.)

• When you place items in a satellite zone it affects how the site interacts with them and with other objects related to them.

  • When Controllers are placed into a satellite zone, it is assumed that those machines have good (local) connectivity to hypervisors and VDAs in the same zone. Controllers in that satellite zone are then used in preference to Controllers in the primary zone for handling those hypervisors and VDA machines.
  • When a hypervisor connection is placed into a satellite zone, it is assumed that all the hypervisors managed via that hypervisor connection also reside in that satellite zone. Controllers in that satellite zone are then used in preference to Controllers in the primary zone when communicating with that hypervisor connection.
  • When a machine catalog is placed into a satellite zone, it is assumed that all the VDA machines in that catalog are in the satellite zone. Local Controllers are used in preference to Controllers in the primary zone when attempting to register with the site, after the Controller list auto-update mechanism has activated after the first registration of each VDA.
  • Citrix Gateway instances can also be associated with zones. 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 site configuration. When a Citrix Gateway is associated with a zone, it is preferred to be used when HDX connections to VDA machines in that zone are used.

• When you create a production site and then create the first catalog and Delivery Group, all items are in the primary zone – you cannot create satellite zones until after you complete that initial setup. (If you create an empty site, the primary zone will initially contain only a Controller. You can create satellite zones before or after creating a catalog and Delivery Group.)

• When you create the first satellite zone containing one or more items, all other items in your site remain in the primary zone.

• The primary zone is named ‘Primary’ by default; you can change that name. Although the Studio display indicates which zone is the primary zone, it is best practice to use an easily identifiable name for the primary zone. You can reassign the primary zone (that is, make another zone the primary zone), but it should always contain the site database and any high availability servers.

• Always keep the site database in the primary zone.

• After you create a zone, you can later move items from one zone to another. This flexibility allows you to potentially separate items that work best in close proximity. For example, moving a catalog to a different zone than the connection (host) that creates the machines in the catalog, can affect performance. Consider potential unintended effects before moving items between zones. Keep a catalog and the host connection it uses in the same zone, or in zones which are well connected (for example, via a low-latency and high-bandwidth network).

• For optimal performance, install Studio and Director only in the primary zone. If you want another Studio instance in a satellite zone (for example, a satellite zone containing Controllers to use as failover if the primary zone becomes inaccessible), run Studio as a locally published application. You can also access Director from a satellite zone because it is a web application.

• Ideally, Citrix Gateway in a satellite zone is used for user connections coming into that zone from other zones or external locations, although you can use it for connections within the zone.

• Remember: To use the zone preference feature, you must be using minimum StoreFront 3.7 and Citrix Gateway 11.0-65.x.

Connection quality limits

The Controllers in the satellite zone perform SQL interactions directly with the site database. This imposes some limits on the quality of the link between the satellite zone and the primary zone containing the site 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.

For more information, see Latency and SQL Blocking Query Improvements.

The impact of latency on brokering performance

Although zones allow users to be on higher-latency links, providing that there is a local broker, the additional latency inevitably impacts end-user experience. For most work that users do, they experience slowness caused by round trips between Controllers in the satellite zone and the site database.

For launching applications, extra delays occur while the session brokering process identifies suitable VDAs to send session launch requests to.

Create and manage zones

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 catalog from one zone to another, you must have edit permission for that catalog. For more information, see Delegated administration.

If you use Citrix Provisioning: The Citrix Provisioning console is not aware of zones, so Citrix recommends using Studio to create catalogs for satellite zones. Create the catalog in Studio, specifying the correct satellite zone. Then use the Citrix Provisioning console to provision machines in that catalog. (If you create the catalog using the Citrix Provisioning wizard, the catalog is placed in the primary zone. You will have to use Studio to move it to the satellite zone later.)

Create a zone

1. Select Configuration > Zones in the Studio navigation pane.
2. Select Create Zone in the Actions pane.
3. Enter a name for the zone, and a description (optional). The name must be unique within the site.
4. Select the items to place in the new zone. You can filter or search the list of items from which you can select. You can also create an empty zone; simply do not select any items.
5. Click Save.

As an alternative to this method, you can select one or more items in Studio and then select Create Zone in the Actions pane.

Change a zone name or description

1. Select Configuration > Zones in the Studio navigation pane.
2. Select a zone in the middle pane and then select Edit Zone in the Actions pane.
3. Change the zone name, description, or both. If you change the name of the primary zone, make sure the zone remains easily identifiable as the primary zone.
4. Click OK or Apply.

Move items from one zone to another zone

1. Select Configuration > Zones in the Studio navigation pane.
2. Select a zone in the middle pane, and then select one or more items.
3. Either drag the items to the destination zone or select Move Items in the Actions pane and then specify which zone to move them to.

A confirmation message lists the items you selected and asks if you are sure you want to move all of them.

Remember: When a catalog uses a host connection to a hypervisor or other service, place both the catalog and the connection in the same zone. Otherwise, performance can be affected. If you move one, move the other, too.

Delete a zone

A zone must be empty before it can be deleted. You cannot delete the primary zone.

1. Select Configuration > Zones in the Studio navigation pane.
2. Select a zone in the middle pane.
3. Select Delete Zone from the Actions pane. If the zone is not empty (it contains items), you are asked to choose the zone where those items will be moved.
4. Confirm the deletion.

Add a home zone for a user

Configuring a home zone for a user is also known as adding a user to a zone.

1. Select Configuration > Zones in the Studio navigation pane and then select a zone in the middle pane.
2. Select Add Users to Zone in the Actions pane.
3. In the Add Users to Zone dialog box, click Add and then select the users and user groups to add to the zone. If you specify users who already have a home zone, a message offers two choices: Yes = add only those users you specified who do not have a home zone; No = return to the user selection dialog.
4. Click OK.

For users with a configured home zone, you can require that sessions launch only from their home zone:

1. Create or edit a Delivery Group.
2. On the Users page, select the Sessions must launch in a user’s home zone, if configured check box.

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.

Remove a home zone for a user

This procedure is also known as removing a user from a zone.

1. Select Configuration > Zones in the Studio navigation pane and then select a zone in the middle pane.
2. Select Remove Users from Zone in the Actions pane.
3. In the Add Users to Zone dialog box, click Remove and then select the users and groups to remove from the zone. This action removes the users only from the zone; those users remain in the Delivery Groups and Application Groups to which they belong.
4. Confirm the removal when prompted.

Manage home zones for applications

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.

• When creating a Delivery Group, creating an Application Group, or adding applications to existing groups, select Properties on the Applications page of the wizard.
• To change an application’s properties after the application is added, select Applications in the Studio navigation pane. Select an application and then select Edit Application Properties in the Actions pane.

On the Zones page of the application’s properties/settings:

• If you want the application to have a home zone:
  • Select Use the selected zone to decide radio button and then select the zone.
  • If you want the application to launch only from the selected zone (and not from any other zone), select the check box under the zone selection.
• If you do not want the application to have a home zone:
  • Select the Do not configure a home zone radio button.
  • If you do not want the broker to consider any configured user zones when launching this application, select the check box under the radio button. In this case, neither application or user home zones are used to determine where to launch this application.

Other actions that include specifying zones

After you create at least one satellite zone, you can specify a zone when you add a host connection or create a catalog.

Usually, the primary zone is the default. When using Machine Creation Services to create a 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.