本地主机缓存
为确保 Citrix Virtual Apps and Desktops 站点数据库始终可用,Citrix 建议按照 Microsoft 的高可用性最佳做法开始部署容错 SQL Server。(有关支持的 SQL Server 高可用性功能,请参阅数据库。)但是,网络问题和中断可能会导致用户无法连接到其应用程序或桌面。
本地主机缓存 (LHC) 功能允许在发生中断时,站点中的连接代理操作能够继续。本地 Citrix 环境中的 Delivery Controller 与站点数据库之间的连接失败时会出现中断。在站点数据库无法访问达 90 秒时,将使用本地主机缓存。
截至 XenApp and XenDesktop 7.16,连接租用功能(早期版本中的高可用性功能的前身)已从产品中删除,并且不再可用。
数据内容
本地主机缓存包含以下信息(主数据库中的一部分信息):
- 为其专门分配了对从站点发布的资源的权限的用户和组的身份。
- 当前正在使用或最近使用了站点中已发布资源的用户的身份。
- 站点中配置的 VDA 计算机(包括 Remote PC Access 计算机)的标识。
- 主动使用 Citrix Receiver 计算机连接到已发布的资源的客户端的标识(名称和 IP 地址)。
此外,它还包含主数据库不可用时建立且当前处于活动状态的连接的信息:
- Citrix Receiver 执行的任何客户端计算机端点分析的结果。
- 站点涉及的基础结构计算机(例如 NetScaler Gateway 和 StoreFront 服务器)的标识。
- 用户进行的最近活动的日期和时间以及类型。
工作原理
下图说明了正常操作过程中本地主机缓存组件和通信路径。
正常操作过程中:
- Controller 上的主 Broker (Citrix Broker Service) 接受来自 StoreFront 的连接请求,并与站点数据库通信,以将用户与已向 Controller 注册的 VDA 连接。
- 定期进行检查(之前的检查完成后一分钟),以确定是否对主 Broker 的配置进行了更改。PowerShell/Studio 操作(例如,更改交付组属性)或系统操作(例如,计算机分配)可能会启动那些更改。
- 如果自上次检查后做了更改,Citrix Config Synchronizer Service (CSS) 会将信息同步(复制)到 Controller 上的 Citrix High Availability Service。(在某些文档中,High Availability Service 又称为辅助 Broker。)复制所有 Broker 配置数据,而非仅复制自上次检查后更改的项目。High Availability Service 将数据导入 Controller 上的 Microsoft SQL Server Express LocalDB 数据库。CSS 确保 LocalDB 数据库中的信息与站点数据库中的信息一致。每次同步时,都会重新创建 LocalDB 数据库。
- 如果自上次检查后没有进行任何更改,则不复制数据。
下图说明了主 Broker 失去与站点数据库的联系时(中断开始)通信路径的变化。
当中断开始时:
- 主 Broker 不能再与站点数据库通信,并停止侦听 StoreFront 和 VDA 信息(图中标记了 X)。然后,主 Broker 指示 High Availability Service 开始侦听并处理连接请求(图中用红色虚线标记)。High Availability Service 丢弃来自 CSS 的所有调用。
- 中断开始时,High Availability Service 没有当前 VDA 注册数据,但当 VDA 与其通信时,就会立即触发重新注册过程。在该过程中,High Availability Service 还获取与该 VDA 的当前会话有关的信息。
- 在 High Availability Service 处理连接的同时,主 Broker 将继续监视与站点数据库的连接。恢复连接时,主 Broker 指示 High Availability Service 停止侦听连接信息,并且主 Broker 恢复代理操作。下次 VDA 与主 Broker 通信时,将触发重新注册过程。High Availability Service 将删除之前中断中的任何剩余的 VDA 注册,并使用从 CSS 收到的配置更改来更新 LocalDB 数据库。
标准模式与中断模式之间的转换不影响现有会话,仅影响新会话的启动。
在同步期间发生中断这种不太可能发生的事件中,会丢弃当前导入,并使用已知的最后一个配置。
事件日志提供有关同步和中断的信息。请参阅下文的“监视”一节了解详细信息。
您还可以有意触发中断;请参阅下文的“强制中断”一节了解有关为什么及如何执行此操作的详细信息。
具有多个 Controller 的站点
除其他任务外,CSS 还定期向 High Availability Service 提供与区域中所有 Controller 有关的信息。(如果您的部署中没有多个区域,此操作将影响站点中的所有 Controller。)有了该信息,每个 High Availability Service 都可以了解所有对端 High Availability Service。
High Availability Service 在单独的通道中相互通信。如果发生中断,这些服务将使用正在其中运行的计算机的按字母顺序排列的 FQDN 名称列表来确定(选择)哪个 High Availability Service 将负责在区域中执行代理操作。在中断期间,所有 VDA 都将在选定的 High Availability Service 中重新注册。区域中的非选定 High Availability Service 将主动拒绝传入连接和 VDA 注册请求。
如果中断期间选定的 High Availability Service 出现故障,则将选择另一个 High Availability Service 来接管,并且 VDA 将在新选定的 High Availability Service 中重新注册。
在中断期间,如果重新启动某个 Controller:
- 如果该 Controller 不是选定的主 Broker,则无法重新启动。
- 如果该 Controller 是选定的主 Broker,此时选择另一个 Controller,这会导致 VDA 重新注册。重新启动的 Controller 开启后,它会自动接管代理,这会导致 VDA 再次重新注册。在这种情况下,在重新注册期间,性能可能会受影响。
如果在正常操作期间关闭某个 Controller,然后在中断期间将其开启,如果该 Controller 被选为主 Broker,则无法在该 Controller 上使用本地主机缓存。
事件日志提供有关选择的信息。请参阅下文的“监视”一节。
设计考虑事项和要求
对中断模式下的操作没有时间限制。但应尽快将站点恢复到正常操作。
中断期间不可用的功能以及其他差异
- 无法使用 Studio 或运行 PowerShell cmdlet。
- 无法从 Host Service 获取虚拟机管理程序凭据。所有计算机都处于未知电源状态,因此无法发出任何电源操作。但是,已打开电源的主机上的 VM 可以用于连接请求。
- 仅当在正常操作过程中发生了分配时,才可以使用分配的计算机。在中断期间不能执行新分配。
- 不能自动注册和配置 Remote PC Access 计算机。但是,正常操作过程中注册和配置的计算机可以使用。
- 如果资源在不同的区域中,服务器托管的应用程序和桌面用户使用的会话可能超过其配置的会话限制。
- 用户只能从包含当前处于活动状态的/选定的 High Availability Service 的区域中已注册的 VDA 启动应用程序和桌面。中断期间不支持跨区域启动(从一个区域中的 High Availability Service 到另一个区域中的 VDA)。
- 如果对交付组中的 VDA 开始计划的重新启动之前发生站点数据库中断,则重新启动将在中断结束后开始。这可能会产生意想不到的结果。有关更多详细信息,请参阅计划的重新启动因数据库中断而延迟。
- 会话启动不支持使用标签来指定区域的标记限制。配置了此类标记限制并启用了 StoreFront 应用商店的高级运行状况检查选项后,会话可能会间歇性无法启动。
服务器托管的应用程序和桌面以及静态(已分配)桌面支持本地主机缓存。
默认情况下,在本地主机缓存事件期间,池交付组(由 MCS 或 Citrix Provisioning 创建)中启用了 ShutdownDesktopsAfterUse
属性的电源管理桌面 VDA 不可用于新连接。可以更改此默认值,以允许在本地主机缓存期间使用这些桌面。但是,中断期间您无法依赖电源管理。(正常操作恢复后,电源管理恢复。)此外,由于这些桌面未重新启动,它们可能包含前一个用户的数据。
要覆盖默认行为,必须在站点范围内并针对受影响的每个交付组启用它。运行以下 PowerShell cmdlet。
Set-BrokerSite -ReuseMachinesWithoutShutdownInOutageAllowed $true
Set-BrokerDesktopGroup -Name "name" -ReuseMachinesWithoutShutdownInOutage $true
在站点和交付组中启用此功能不会影响配置的“ShutdownDesktopsAfterUse”属性在正常操作期间的作用方式。启用此功能后,VDA 不会在 LHC 事件完成后自动重新启动。池交付组中进行电源管理的桌面 VDA 可以保留先前会话中的数据,直到 VDA 重新启动。当用户在非 LHC 操作期间注销 VDA 或者可以手动触发重新启动时,可能会出现这种情况。
重要:
如果不在站点级别启用 ReuseMachinesWithoutShutdownInOutageAllowed 以及不在交付组级别启用 ReuseMachinesWithoutShutdownInOutage,则在本地主机缓存事件期间,尝试对池化交付组中受电源管理的桌面 VDA 启动所有会话都将失败。
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 的速度增长。在正常操作恢复时,将重新创建本地数据库并返还空间。但是,安装了 LocalDB 的驱动器上必须有足够的空间,以允许在中断期间数据库增长。在中断期间,本地主机缓存中还会发生其他 I/O 操作:大约每秒 3 MB 的写入操作,以及数十万次读取操作。
性能注意事项
在中断期间,一个 High Availability Service 将处理所有连接,因此,在正常操作过程中在多个 Controller 之间进行负载平衡的站点(或区域)中,选定的 High Availability Service 需要处理的请求数可能远高于中断期间的正常数。因此,CPU 需求会比较高。站点(区域)中的每个 High Availability Service 都必须能够处理 LocalDB 和所有受影响的 VDA 造成的额外负载,因为在中断期间选择的 High Availability Service 可能会发生变化。
VDI 限制:
- 在单区域 VDI 部署中,中断期间最多可以有效处理 10,000 个 VDA。
- 在多区域 VDI 部署中,中断期间在每个区域中最多可以有效处理 10,000 个 VDA,在站点中最多可以处理 40,000 个 VDA。例如,在中断期间,可以有效处理以下站点之一:
- 具有四个区域的站点,每个区域包含 10,000 个 VDA。
- 具有七个区域的站点,一个区域包含 10,000 个 VDA,另外六个区域每个包含 5,000 个 VDA。
在中断期间,站点内的负载管理可能会受到影响。负载评估器(尤其是会话计数规则)可能会超额。
在所有 VDA 在 High Availability Service 中重新注册的这段时间内,该服务可能没有与当前会话有关的完整信息。因此,在该时间间隔内的用户连接请求可能会导致启动新会话,即使有可能重新连接到现有会话也是如此。此时间间隔(在此期间,在重新注册过程中,“新”High Availability Service 从所有 VDA 获取会话信息)无法避免。请注意,在该过渡时间间隔内,中断开始时已连接的会话不受影响,但新会话和会话重新连接会受影响。
每当 VDA 必须重新注册时,都会出现此时间间隔:
- 中断开始:从主 Broker 迁移到 High Availability Service 时。
- 中断期间出现 High Availability Service 故障:从出现故障的 High Availability Service 迁移到新选定的 High Availability Service 时。
- 从中断恢复:正常操作恢复且主 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
更改检测信号值时请务必小心谨慎。增大频率会导致处于标准模式和中断模式时 Controller 上的负载增加。
无论 VDA 注册的速度有多快,都无法完全消除该时间间隔。
在 High Availability Service 之间同步所需的时间会随对象(例如 VDA、应用程序、组)数增加。例如,同步 5000 个 VDA 可能需要 10 分钟或更长时间来完成。请参阅监视了解有关事件日志中的同步条目的信息。
XenApp 6.x 各版本中的差异
尽管此本地主机缓存实施与 XenApp 6.x 及更早 XenApp 版本中的本地主机缓存功能的名称相同,但进行了显著的改进。此实施更强大且不易损坏。维护要求降低到最小,例如,不再需要定期运行 dsmaint 命令。此本地主机缓存在技术上是完全不同的实现。
管理本地主机缓存
要使本地主机缓存正确工作,每个 Controller 上的 PowerShell 执行策略都必须设置为 RemoteSigned、Unrestricted 或 Bypass。
SQL Server Express LocalDB
在安装 Controller 或从低于 7.9 的版本升级 Controller 时,会自动安装本地主机缓存使用的 Microsoft SQL Server Express LocalDB。不需要对 LocalDB 执行管理员维护操作。只有 High Availability Service 与此数据库通信。不能使用 PowerShell cmdlet 更改与此数据库有关的任何内容。LocalDB 不能在多个 Controller 之间共享。
无论是否启用本地主机缓存,都会安装 SQL Server Express LocalDB 数据库软件。
要阻止其安装,请使用 XenDesktopServerSetup.exe 命令安装或升级 Controller,并包含 /exclude "Local Host Cache Storage (LocalDB)"
选项。但请注意,没有数据库时,无法使用本地主机缓存功能,并且不能将不同的数据库用于 High Availability Service。
安装此 LocalDB 数据库对您是否安装 SQL Server Express 以用作站点数据库没有影响。
有关将较早的 SQL Server Express LocalDB 版本替换为较新版本的信息,请参阅替换 SQL Server Express LocalDB。
产品安装和升级后的默认设置
在全新安装 Citrix Virtual Apps and Desktops(最低版本 7.16)过程中,启用本地主机缓存。升级(到 7.16 版或更高版本)后,如果整个部署中的 VDA 数量低于 10000,则将启用本地主机缓存。
启用和禁用本地主机缓存
-
要启用本地主机缓存,请输入:
Set-BrokerSite -LocalHostCacheEnabled $true
要确定是否已启用本地主机缓存,请输入:
Get-BrokerSite
检查 LocalHostCacheEnabled 属性是否设置为 True。
-
要禁用本地主机缓存,请输入:
Set-BrokerSite -LocalHostCacheEnabled $false
谨记:截至 XenApp and XenDesktop 7.16,连接租用(自版本 7.6 起提供的本地主机缓存功能之前的功能)已从产品中删除,并且不再可用。
验证本地主机缓存是否正在运行
要验证本地主机缓存是否已设置并正常运行,请执行以下操作:
- 确保同步导入成功完成。检查事件日志。
- 确保在每个 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
与 REG_DWORD
一样设置为 1。这指示 Broker 进入中断模式,无论数据库的状态是什么。将该值设置为 0 将使服务器退出中断模式。
监视
事件日志记录何时发生同步和中断。
Config Synchronizer Service:
正常操作过程中,CSS 通过使用 High Availability Service 复制并导出 Broker 配置,然后将其导入 LocalDB 时,会发生以下事件。
- 503:发现主 Broker 配置有更改,且正在开始导入。
- 504:已将 Broker 配置复制、导出并成功导入 LocalDB。
- 505:导入 LocalDB 失败;请参阅下文了解详细信息。
- 507: 由于存在挂起的中断,放弃了导入。在同步期间发生中断时,会丢弃当前的导入,并使用已知的最后一个配置。
- 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:发生了中断,辅助 High Availability Service 正在执行代理操作。
- 3503:已解决中断并已恢复正常操作。
- 3504:指示选择哪个 High Availability Service,以及参与选择的其他 High Availability Service。
故障排除
向 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
。