设计决策:设计StoreFront 和多站点聚合

StoreFront 的一项核心功能是能够聚合和删除来自多个 Citrix Virtual Apps and Desktops(Citrix Virtual Apps and Desktops)站点的“常见”应用程序和桌面资源。此功能通常称为多站点聚合。基于匹配和Application Display Name 属性识别重复的应用程序Application Category 和桌面。从 3.5 版开始,此功能已在控制台中提供,以前是配置文件编辑。多站点聚合的目的是允许 Citrix 管理员构建冗余的 Citrix Virtual Apps and Desktops 站点(出于可扩展性或域故障原因),同时向用户显示单个应用程序或桌面图标,而不是每个站点的副本(如果没有此功能则会显示出来)。然后,StoreFront 控制如何在支持该资源的多个站点之间分配应用程序和桌面启动项。

本文将介绍如何在企业环境中实施这些设置,以及它们如何与其他相关设置(如应用程序关键字和订阅)集成,以进一步控制用户会话的路由和资源的呈现方式。

概述

多站点设置的配置是通过 StoreFront 控制台中的“管理交付控制器”向导完成的, 产品文档中详细介绍了各种配置。如果为应用商店配置了多个站点,则“用户映射和多站点聚合配置”下的配置按钮将变为启用状态,如下所示。

配置选项

选择后,系统会提示管理员配置用户映射和资源聚合,如下所示。“将用户映射到控制器”链接会提示管理员配置要应用这些设置的用户组。“聚合资源”链接是指定实际的多站点聚合设置的位置。

用户映射和资源聚合

在至少定义了一个用户组以将设置应用于之前,无法配置多站点聚合。如果要将一组聚合设置应用于连接到应用商店的所有用户,则可以使用内置的“所有人”组。配置这些设置后,如果用户不是此处指定的某个组的成员,则不会为该用户枚举任何应用程序或桌面。接下来的两节将从“聚合资源”选项开始,详细回顾可用的配置。

聚合选项

在聚合资源部分中,将向管理员显示所有列举的站点,并提示管理员选择具有重叠资源和聚合的站点,如下所示。

聚合资源设置

对于聚合的站点,还有两种配置控制资源的枚举方式以及在这些站点之间启动会话的方式。这些设置适用于标记为聚合的所有站点:

  • 控制器发布相同的资源:此设置控制枚举。如果两个站点被标记为“相同”,StoreFront 会将场置于同一个“等效场集”中,这意味着枚举请求会在站点之间进行负载平衡(轮循),因为假定资源集是等效的,从而节省枚举时间。如果两个站点未标记为“相同”,StoreFront 会向所有站点发送 XML 枚举请求,并从生成的资源集中消除公用应用程序和桌面的重复数据。
  • 跨控制器负载平衡资源: 此设置控制会话启动。启动请求要么在站点之间进行负载平衡(轮询),要么按故障转移顺序分发,无论站点是否“相同”。会话共享优先于负载平衡决策,请注意,负载平衡不考虑负载指数。因此,如果用户已经在站点 B 中有一个会话并启动了另一个应用程序或桌面,则该会话也将在站点 B 中启动(假设该应用程序或桌面在那里可用)。

有些没有通过 GUI 很好地处理的用例是负载平衡和故障转移的组合,或者是相同和不相同站点的组合。例如,如果有两个生产站点需要进行负载平衡,而一个灾难恢复站点仅在两个生产站点都关闭时才使用,则无法使用 GUI,而必须手动修改 web.config 文件(有关此文件的正确格式,请参阅 Citrix Docs )。

设计要点

要总结上一节:

  • 通过 StoreFront 聚合站点时,只使用一组“相同”站点中的一个来枚举应用程序和桌面
  • 会话启动可以是负载平衡的,也可以是跨聚合站点失败的

用户场映射

“将用户映射到控制器”设置通常被称为“用户场映射”,因为它们用于控制允许给定用户组枚举的站点,无论这些站点是否聚合。此功能有两个主要用例:

  1. 限制枚举:即使没有多站点聚合,StoreFront 中的一组用户分配给站点子集意味着 StoreFront 只会在该组中的用户进行身份验证时向这些站点发送 XML 枚举请求。在全局部署中,这种情况可能会对枚举时间产生重大影响,因为它会阻止 StoreFront 尝试与给定用户无论如何无需访问的站点进行通信。例如,这些设置可用于将美国用户映射到总部位于美国的Citrix Virtual Apps and Desktops站点,这样,当这些用户登录时,StoreFront无法访问其他分散在全球的站点。
  2. 分配聚合设置:如果配置了多站点聚合,则最好将不同的配置分配给不同的用户组,例如不同的故障切换配置或不同的站点组合。

“将用户映射到控制器”首先提示管理员指定用户组,然后提示管理员指定用户组被分配到的站点(尽管对话框显示“Controller”,但它是为应用商店定义的站点)。有一列表示选定的站点之前是否已配置为聚合,如下所示。此外,如果聚合站点配置为故障转移(“控制器之间的负载平衡资源”未清除),则可以在此处通过右侧的箭头指定站点的顺序。

用户映射设置

一个用户可以成为多个用户组映射的一部分。当 StoreFront 读取已配置用户组的列表时,它不会在找到用户的匹配项后停止处理。所有已配置的组都将被处理,并枚举所有返回的站点。Citrix 管理员通常可以访问所有应用程序和桌面,并且是多个用户组的成员,以便能够测试和重现报告的用户问题,可以预期这种情况会出现这种情况。这只是意味着管理员(或多个组成员的其他用户)可能会遇到与其中一个组中的用户不同的启动行为,因为他们应用了多个配置。 在配置方面,唯一的考虑因素是两个用户组是否可以访问具有不同聚合设置的同一组站点。在单个用户的上下文中,一个站点只能属于一个聚合组,否则会显示错误。通过在两个用户组映射之间命名相同的聚合组来解决这个问题,默认情况下,这是通过 GUI 完成的,但是,如果 Web.config 文件正在手动修改以获得先前引用的更高级的配置集,则可能需要考虑因素。

设计要点

要总结上一节:

  • 将用户组分配到站点,即使没有配置聚合,也可以用来帮助限制枚举流量,从而缩短此过程的完成时间
  • 聚合站点的故障转移顺序在用户组分配向导中指定
  • 如果配置了多个用户组映射,其中包含一些相同的聚合站点,并且用户属于多个组,则聚合组的命名必须相同

应用程序关键字

控制资源显示和启动的另一种方法是在应用程序描述字段中使用关键字。在商店设置中,可以根据自定义关键字过滤显示内容,如 文章 CTX223451 所述。还有一些具有独特功能的预定义特殊关键字。其中两个是“主要”和“次要”,这影响了跨多个站点的会话启动。当发布了同一应用程序的两个实例时,具有指定关键字“主”的实例将始终优先于带有关键字“二级”的实例。 此设置将覆盖前面部分中介绍的任何站点聚合设置,这意味着这些设置经常一起使用。

例如,如果有两个 Citrix Virtual Apps and Desktops 站点,即站点 A 和站点 B,几乎所有应用程序都需要从站点 A(基于后端应用架构)启动并故障转移到站点 B,但是有几个应用程序主要托管在站点 B 之外,将按故障转移顺序为所有用户配置多站点聚合,首先列出站点 A。主要由站点 B 托管的特殊应用程序将在站点 B 中使用关键字 primary 进行配置,在站点 A 中使用辅助关键字。

设计要点

要总结上一节:

• “主”和“次要”关键字可用于进一步控制跨多个站点的应用程序启动,优先于站点聚合设置

订阅

StoreFront 中的订阅是允许用户使用“收藏”应用程序的方式,并将其存储在每个 StoreFront 服务器的本地数据库中,并在服务器组中自动复制。默认情况下,订阅记录以格式存储<SiteName>.<DisplayName>。这是因为默认情况下,StoreFront 将枚举来自所有 Citrix Virtual Apps and Desktops 站点的资源并单独显示它们。如果两个资源恰好在不同的站点中以相同名称发布,则会单独跟踪对它们的订阅。因此,我们需要某种网站标签来区分这些订阅。

这种情况随着站点聚合而改变,其中站点之间的相同资源不会单独显示和跟踪,而是聚合在同一订阅快捷方式后站点标记不再有意义,因为单个订阅记录必须涵盖来自多个站点的相同资源。因此,配置站点聚合后,聚合资源的订阅记录将以格式存储 <AggregationGroup>.<DisplayPath>\<DisplayName>

这意味着,如果 StoreFront 多站点聚合是在以前单独提供站点(启用了订阅)之后配置的,则由于订阅记录格式的更改,新聚合资源的任何用户订阅都将消失。之前的订阅记录不再有效,因为应用程序不再绑定到站点,而是一个聚合组。解决方法是通过 PowerShell 导出订阅数据库,替换将以适当格式聚合的资源的所有记录,并在配置站点聚合后重新导入订阅数据库。否则,用户必须重新订阅其应用程序。

设计要点

要总结前面的章节:

  • 多站点聚合会更改订阅数据库中用户订阅的格式,如果在上线后实施聚合,则必须考虑该格式

引用

产品文档:StoreFront 多站点设置

StoreFront 关键词用法

设计决策:设计StoreFront 和多站点聚合