XenApp and XenDesktop

本地主机缓存

为确保 XenApp 和 XenDesktop 站点数据库始终可用,Citrix 建议按照 Microsoft 的高可用性最佳做法开始部署容错 SQL Server。(系统要求一文中的“数据库”一节列出了 XenApp 和 XenDesktop 中支持的 SQL Server 高可用性功能。)但是,网络问题和中断可能会导致用户无法连接到其应用程序或桌面。

本地主机缓存 (LHC) 功能允许在发生中断时,XenApp 或 XenDesktop 站点中的连接代理操作能够继续。Delivery Controller 与站点数据库之间的连接失败时会出现中断。在站点数据库无法访问达 90 秒时,将使用本地主机缓存。

本地主机缓存是 XenApp 和 XenDesktop 中最全面的高可用性功能。它是替代 XenApp 7.6 中引入的连接租用功能的更强大功能。

尽管此本地主机缓存实施与 XenApp 6.x 及更早 XenApp 版本中的本地主机缓存功能的名称相同,但进行了显著的改进。此实施更强大且不易损坏。维护要求降低到最小,例如,不再需要定期运行 dsmaint 命令。此本地主机缓存在技术上是完全不同的实施;请继续阅读,了解其工作原理。

注意:

虽然在版本 7.15 LTSR 中支持连接租用,但在以下版本中将删除该功能。

数据内容

本地主机缓存包含以下信息(主数据库中的一部分信息):

  • 为其专门分配了对从站点发布的资源的权限的用户和组的身份。
  • 当前正在使用或最近使用了站点中已发布资源的用户的身份。
  • 站点中配置的 VDA 计算机(包括 Remote PC Access 计算机)的标识。
  • 主动使用 Citrix Receiver 计算机连接到已发布的资源的客户端的标识(名称和 IP 地址)。

此外,它还包含主数据库不可用时建立且当前处于活动状态的连接的信息:

  • Citrix Receiver 执行的任何客户端计算机端点分析的结果。
  • 站点涉及的基础结构计算机(例如 NetScaler Gateway 和 StoreFront 服务器)的标识。
  • 用户进行的最近活动的日期和时间以及类型。

工作原理

下图说明了正常操作过程中本地主机缓存组件和通信路径。

LHC - 正常

正常操作过程中

  • Controller 上的主 Broker (Citrix Broker Service) 接受来自 StoreFront 的连接请求,并与站点数据库通信,以将用户与已向 Controller 注册的 VDA 连接。
  • 每两分钟进行一次检查,以确定是否对主 Broker 的配置进行了更改。PowerShell/Studio 操作(例如,更改交付组属性)或系统操作(例如,计算机分配)可能会启动那些更改。
  • 如果自上次检查后做了更改,主 Broker 将使用 Citrix Config Synchronizer Service (CSS) 将信息同步(复制)到 Controller 上的辅助 Broker (Citrix High Availability Service)。所有 Broker 配置数据都会被复制,而不仅仅是自上次检查后更改的项。辅助 Broker 将数据导入 Controller 上的 Microsoft SQL Server Express LocalDB 数据库。CSS 确保辅助 Broker 的 LocalDB 数据库中的信息与站点数据库中的信息一致。每次同步时,都会重新创建 LocalDB 数据库。
  • 如果自上次检查后没有进行任何更改,则不复制数据。

下图说明了主 Broker 失去与站点数据库的联系时(中断开始)通信路径的变化:

LHC - 中断

当中断开始时

  • 主 Broker 不能再与站点数据库通信,并停止侦听 StoreFront 和 VDA 信息(图中标记了 X)。然后,主 Broker 指示辅助 Broker (High Availability Service) 开始侦听并处理连接请求(图中用红色虚线标记)。
  • 中断开始时,辅助 Broker 没有当前 VDA 注册数据,但当 VDA 与其通信时,就会立即触发重新注册过程。在该过程中,辅助 Broker 还获取有关该 VDA 的当前会话信息。
  • 在辅助 Broker 处理连接的同时,主 Broker 继续监视与站点数据库的连接。恢复连接时,主 Broker 指示辅助 Broker 停止侦听连接信息,且主 Broker 恢复代理操作。下次 VDA 与主 Broker 通信时,将触发重新注册过程。辅助 Broker 将删除之前中断中的任何剩余的 VDA 注册,并使用从 CSS 收到的配置更改来更新 LocalDB 数据库。

在同步期间发生中断这种不太可能发生的事件中,会丢弃当前导入,并使用已知的最后一个配置。

事件日志提供有关同步和中断的信息。请参阅下文的“监视”一节了解详细信息。

您还可以有意触发中断;请参阅下文的“强制中断”一节了解有关为什么及如何执行此操作的详细信息。

具有多个 Controller 的站点

除了其他任务外,CSS 还定期向辅助 Broker 提供有关区域中所有 Controller 的信息。(如果您的部署中没有多个区域,则此操作影响站点中的所有 Controller。)有了那些信息,每个辅助 Broker 都可以了解所有对等辅助 Broker。

辅助 Broker 在单独的通道中相互通信。如果发生中断,它们使用正在其中运行的计算机的 FQDN 名称的字母列表来确定(选择)哪个辅助 Broker 将负责在区域中执行代理操作。在中断期间,所有 VDA 向选定的辅助 Broker 重新注册。区域中的非选定辅助 Broker 将主动拒绝传入连接和 VDA 注册请求。

如果在中断期间某个选定的辅助 Broker 发生故障,将选择另一个辅助 Broker 来接管,且 VDA 将向新选定的辅助 Broker 重新注册。

在中断期间,如果重新启动某个 Controller:

  • 如果该 Controller 不是选定的主 Broker,则无法重新启动。
  • 如果该 Controller 是选定的主 Broker,此时选择另一个 Controller,这会导致 VDA 重新注册。重新启动的 Controller 开启后,它会自动接管代理,这会导致 VDA 再次重新注册。在这种情况下,在重新注册期间,性能可能会受影响。

如果在正常操作期间关闭某个 Controller,然后在中断期间将其开启,如果该 Controller 被选为主 Broker,则无法在该 Controller 上使用本地主机缓存。

事件日志提供有关选择的信息。请参阅下文的“监视”一节。

设计考虑事项和要求

对于服务器托管的应用程序和桌面以及静态(分配的)桌面,支持本地主机缓存;而对于池 VDI 桌面(由 MCS 或 PVS 创建),不支持本地主机缓存。

对中断模式下的操作没有时间限制。但应尽快将站点恢复到正常操作。

中断期间不可用或更改内容:

  • 无法使用 Studio 或运行 PowerShell cmdlet。
  • 无法从 Host Service 获取虚拟机管理程序凭据。所有计算机都处于未知电源状态,因此无法发出任何电源操作。但是,已打开电源的主机上的 VM 可以用于连接请求。
  • 仅当在正常操作过程中发生了分配时,才可以使用分配的计算机。在中断期间不能执行新分配。
  • 不能自动注册和配置 Remote PC Access 计算机。但是,正常操作过程中注册和配置的计算机可以使用。
  • 如果资源在不同的区域中,服务器托管的应用程序和桌面用户使用的会话可能超过其配置的会话限制。
  • 用户只能从包含当前处于活动状态的/选定的(二级)Broker 的区域中已注册的 VDA 启动应用程序和桌面。断电期间不支持跨区域启动(从一个区域中的 Broker 到另一个区域中的 VDA)。

默认情况下,发生中断时,启用了 ShutdownDesktopsAfterUse 属性的池交付组中进行电源管理的桌面 VDA 被置于维护模式。您可以更改此默认值,以允许在中断期间使用这些桌面。但是,中断期间您无法依赖电源管理。(正常操作恢复后,电源管理恢复。)此外,由于这些桌面未重新启动,它们可能包含前一个用户的数据。

要覆盖默认行为,必须在站点范围内并针对受影响的每个交付组启用它。

对于该站点,请运行以下 PowerShell cmdlet:

Set-BrokerSite -ReuseMachinesWithoutShutdownInOutageAllowed $true

对于每个受影响的交付组,请运行以下 PowerShell cmdlet:

Set-BrokerDesktopGroup -Name "\<*name*\>" -ReuseMachinesWithoutShutdownInOutage $true

在站点和交付组中启用此功能不会影响配置的 ShutdownDesktopsAfterUse 属性在正常操作期间的作用方式。

RAM 大小:

LocalDB 服务可以使用大约 1.2 GB 的 RAM(每个数据库缓存最多 1 GB,另加 200 MB 用于运行 SQL Server Express LocalDB)。如果中断持续较长时间,且发生了很多登录(例如,12 个小时内 10K 用户),则 High Availability Service 最多可以使用 1 GB 的 RAM。这些内存要求是 Controller 的正常 RAM 要求之外的要求,因此您可能需要增加 RAM 总容量。

请注意,如果您对站点数据库使用 SQL Server Express 安装,则服务器将有两个 sqlserver.exe 进程。

CPU 核心和套接字配置:

Controller 的 CPU 配置,尤其是可用于 SQL Server Express LocalDB 的核心数,直接影响本地主机缓存性能,甚至比内存分配还要严重。仅在数据库不可访问且 High Availability Service 处于活动状态时,在中断期间观察此 CPU 开销。

虽然 LocalDB 可以使用多个核心(最多 4 个),但只能使用一个套接字。添加多个套接字不会提高性能(例如,每个有 4 个套接字和 1 个核心)。相反,Citrix 建议结合使用多个套接字和多个核心。在 Citrix 测试中,2x3(2 个套接字,3 个核心)配置提供的性能优于 4x1 和 6x1 配置。

存储:

由于在中断期间用户访问资源,LocalDB 会增长。例如,在以每秒 10 次登录运行的登录/注销测试期间,数据库以每 2-3 分钟 1 MB 的速度增长。在正常操作恢复时,将重新创建本地数据库并返还空间。但是,Broker 必须在安装 LocalDB 的驱动器上有足够的空间,以允许在中断期间数据库增长。在中断期间,本地主机缓存中还会发生其他 I/O 操作:大约每秒 3 MB 的写入操作,以及数十万次读取操作。

性能:

在中断期间,一个 Broker 处理所有连接,因此,在正常操作过程中在多个 Controller 之间进行负载平衡的站点(或区域)中,选定的 Broker 需要处理的请求数可能远高于中断期间的正常数。因此,CPU 需求会比较高。站点(区域)中的每个 Broker 都必须能够处理 LocalDB 和所有受影响的 VDA 造成的额外负载,因为在中断期间选择的 Broker 可能会更改。

VDI 限制:

  • 在单区域 VDI 部署中,中断期间最多可以有效处理 10,000 个 VDA。
  • 在多区域 VDI 部署中,中断期间在每个区域中最多可以有效处理 10,000 个 VDA,在站点中最多可以处理 40,000 个 VDA。例如,在中断期间,可以有效处理以下站点之一:
    • 具有四个区域的站点,每个区域包含 10,000 个 VDA。
    • 具有七个区域的站点,一个区域包含 10,000 个 VDA,另外六个区域每个包含 5,000 个 VDA。

在中断期间,站点内的负载管理可能会受到影响。负载评估器(尤其是会话计数规则)可能会超额。

在所有 VDA 向 Broker 重新注册的这段时间,该 Broker 可能没有有关当前会话的完整信息。因此,在该时间间隔内的用户连接请求可能会导致启动新会话,即使有可能重新连接到现有会话也是如此。此时间间隔(在此期间,在重新注册过程中,“新”Broker 从所有 VDA 获取会话信息)无法避免。请注意,在该过渡时间间隔内,中断开始时已连接的会话不受影响,但新会话和会话重新连接会受影响。

每当 VDA 必须向不同的 Broker 重新注册时,都会出现此时间间隔:

  • 中断开始:从主 Broker 迁移到辅助 Broker 时。
  • 中断期间 Broker 发生故障:从发生故障的辅助 Broker 迁移到新选定的辅助 Broker 时。
  • 从中断恢复:正常操作恢复且主 Broker 恢复控制时。

可以通过降低 Citrix Broker Protocol 的 HeartbeatPeriodMs 注册表值(默认为 600000 毫秒,即 10 分钟)来缩短该时间间隔。此检测信号值是 VDA 执行 ping 操作的时间间隔的两倍,因此,默认值将导致 ping 操作每隔 5 分钟执行一次。

例如,以下命令将检测信号更改为 5 分钟(300000 毫秒),这将导致 ping 操作每隔 2.5 分钟执行一次:

New-ItemProperty -Path HKLM:\SOFTWARE\Citrix\DesktopServer -Name HeartbeatPeriodMs -PropertyType DWORD –Value 300000

无论 VDA 注册的速度有多快,都无法完全消除该时间间隔。

在 Broker 之间同步所需的时间会随对象(例如 VDA、应用程序、组)数增加。例如,同步 5000 个 VDA 可能需要 10 分钟或更长时间来完成。请参阅下文的“监视”一节,了解有关事件日志中的同步条目的信息。

管理本地主机缓存

要使本地主机缓存正确工作,每个 Controller 上的 PowerShell 执行策略都必须设置为 RemoteSigned、Unrestricted 或 Bypass。

SQL Server Express LocalDB

在安装 Controller 或从低于 7.9 的版本升级 Controller 时,会自动安装本地主机缓存使用的 Microsoft SQL Server Express LocalDB。不需要对 LocalDB 执行管理员维护操作。仅辅助 Broker 与此数据库通信;不能使用 PowerShell cmdlet 更改有关此数据库的任何内容。LocalDB 不能在多个 Controller 之间共享。

无论是否启用本地主机缓存,都会安装 SQL Server Express LocalDB 数据库软件。

要阻止其安装,请使用 XenDesktopServerSetup.exe 命令安装或升级 Controller,并包含 /exclude “Local Host Cache Storage (LocalDB)” 选项。但是,请注意,没有数据库时,无法使用本地主机缓存功能,并且不能将不同的数据库用于辅助 Broker。

安装此 LocalDB 数据库对您是否安装 SQL Server Express 以用作站点数据库没有影响。

安装和升级 XenApp 或 XenDesktop 后的默认设置

全新安装 XenApp 和 XenDesktop 的过程中,默认启用本地主机缓存。(连接租用默认处于禁用状态。)

升级后,本地主机缓存设置保持不变。例如,如果本地主机缓存在早期版本中处于启用状态,在升级后的版本中也会保持启用状态。如果本地主机缓存在早期版本中处于禁用状态(或不受支持),在升级后的版本中也会保持禁用状态。

启用和禁用本地主机缓存

要启用本地主机缓存,请输入:

Set-BrokerSite -LocalHostCacheEnabled $true -ConnectionLeasingEnabled $false

此 cmdlet 还禁用连接租用功能。请勿启用本地主机缓存和连接租用。

要确定是否已启用本地主机缓存,请输入:

Get-BrokerSite

检查 LocalHostCacheEnabled 属性是否为 True 以及 ConnectionLeasingEnabled 属性是否为 False。

要禁用本地主机缓存(和启用连接租用),请输入:

Set-BrokerSite -LocalHostCacheEnabled $false -ConnectionLeasingEnabled $true

验证本地主机缓存是否正在运行

要验证本地主机缓存是否已设置并正常运行,请执行以下操作:

  • 确保同步导入成功完成。检查事件日志
  • 确保在每个 Delivery Controller 上创建 SQL Server Express LocalDB 数据库。这确认了如果需要,高可用性服务可以接管。
  • 在 Delivery Controller 服务器上,浏览到 C:\Windows\ServiceProfiles\NetworkService.
  • 验证是否已创建 HaDatabaseName.mdf 和 HaDatabaseName_log.ldf。
  • 在 Delivery Controller 上强制中断。验证本地主机缓存是否正常运行后,请记住将所有 Controller 重置回普通模式。这可能需要大约 15 分钟才能避免出现 VDA 注册风暴。

强制中断

您可能希望有意强制数据库中断。

  • 如果您的网络反复开启和关闭。在网络问题解决之前强制中断可以防止持续在正常模式和中断模式之间转换。
  • 要测试灾难恢复计划。
  • 更换或维修站点数据库服务器时。

要强制中断,请编辑包含 Delivery Controller 的每个服务器的注册表。

  • 在 HKLM\Software\Citrix\DesktopServer\LHC 中,将 OutageModeForced 设置为 1。这指示 Broker 进入中断模式,无论数据库的状态是什么。 (将该值设置为 0 将使服务器退出中断模式。)
  • 在 Citrix Cloud 场景中,连接器进入中断模式,无论与控制平面或主要区域的连接的状态是什么。

监视

事件日志记录何时发生同步和中断。

Config Synchronizer Service:

正常操作过程中,CSS 通过使用 High Availability Service(辅助 Broker)复制并导出 Broker 配置,然后将其导入 LocalDB 时,会发生以下事件。

  • 503:发现主 Broker 配置有更改,且正在开始导入。
  • 504:已将 Broker 配置复制、导出并成功导入 LocalDB。
  • 505:导入 LocalDB 失败;请参阅下文了解详细信息。
  • 510: No Configuration Service configuration data received from primary Configuration Service.(510: 未从主 Configuration Service 收到任何 Configuration Service 配置数据。)
  • 517: There was a problem communicating with the primary Broker.(517: 与主 Broker 通信时出现问题。)
  • 518: Config Sync 脚本已中止,因为次要 Broker (高可用性服务)未在运行。

High Availability Service:

  • 3502:发生了中断,辅助 Broker (High Availability Service) 正在执行代理操作。
  • 3503:已解决中断并已恢复正常操作。
  • 3504:指示选择哪个辅助 Broker,以及参与选择的其他 Broker。

故障排除

向 LocalDB 的同步导入失败且发布了 505 事件时,可以使用多个故障排除工具。

CDF 跟踪: 包含用于 ConfigSyncServer 模块和 BrokerLHC 模块的选项。那些选项与其他 Broker 模块一起可能会确定问题。

报告: 如果同步导入失败,可以生成报告。此报告在导致出错的对象所在的位置停止。此报告功能影响同步速度,因此,Citrix 建议在不使用时禁用它。

要启用并生成 CSS 跟踪报告,请输入以下命令:

New-ItemProperty -Path HKLM:\SOFTWARE\Citrix\DesktopServer\LHC -Name EnableCssTraceMode -PropertyType DWORD -Value 1

HTML 报告发布在 C:\\Windows\\ServiceProfiles\\NetworkService\\AppData\\Local\\Temp\\CitrixBrokerConfigSyncReport.html 上。

生成报告后,输入以下命令以禁用报告功能:

Set-ItemProperty -Path HKLM:\SOFTWARE\Citrix\DesktopServer\LHC -Name EnableCssTraceMode -Value 0

导出 Broker 配置: 提供准确的配置以用于调试目的。

Export-BrokerConfiguration | Out-File file-pathname

例如 Export-BrokerConfiguration | Out-File C:\\BrokerConfig.xml