高级概念

本地主机缓存大小调整和扩展

注意:

有关使用本地主机缓存的 Citrix DaaS 部署的最新 大小和规模建议,请参阅云连接器的大小和缩放注意事项

XenApp 和 XenDesktop 7.12 中引入了本地主机缓存,以取代 XenDesktop 7.6 中提供的连接租用功能。本地主机缓存比连接租用涵盖更多场景,但需要不同的设计注意事项。

  • 本地主机缓存支持的用例多于连接租用。
  • 运行时,本地主机缓存需要比连接租用更多的资源(CPU 和内存)。
  • 在中断模式下,每个区域只有一个代理将处理 VDA 注册和代理会话。
  • 选举过程决定中断期间哪个经纪商将处于活动状态,但不考虑经纪商资源。
  • 如果区域中的任何一个 broker 在正常操作期间无法处理所有登录,则在中断模式下将无法正常工作。
  • 在停机模式下,没有可用的站点管理。
  • 高可用性的 SQL Server 仍然是推荐的设计。
  • 对于间歇性数据库连接情形,最好隔离 SQL Server 并将站点置于中断模式,直到修复所有基本问题。
  • 每个区域限制为 5,000 个 VDA(未强制执行)。
  • 没有 14 天的限制。
  • 在默认配置中,在中断模式下不支持池桌面。

体系结构

XenDesktop 7.6 中引入了连接租赁,允许在站点数据库停机期间继续访问资源。它不支持 VDI 池桌面,默认情况下,用户必须在过去 14 天内连接到资源。另一个限制是,它会尝试将用户连接到他们在正常操作期间连接的最后一个桌面或应用程序主机。如果这不可用,则不会代理连接。

这两种技术(连接租用和本地主机缓存)的体系结构非常不同,它们需要不同的资源才能运行。连接租用会创建单独的 XML 租用文件,这可能需要几个 GB 的磁盘空间,具体取决于站点中的资源数量。本地主机缓存使用本地 SQL Server 数据库,在磁盘空间使用方面效率更高,但确实需要比连接租用更多的内存和 CPU。两者都有同步阶段,其中来自主站点数据库的详细信息将同步到代理(Controller)。由于在文件系统上创建的单个文件数量庞大,连接租用初始同步可能会导致相当大的 IOPS。虽然本地主机缓存使用仍需要 IOPS 的 SQL 数据库,但它具有 SQL 优化这些写入的优势。

在具有多个代理的连接租赁设置中,每个代理都有一份 XML 租约的副本,并且能够在中断期间代理连接,从而帮助平衡负载。但是,对于本地主机缓存,会选择单个代理来代理所有连接并处理 VDA 注册。站点中的所有 VDA 都将向该单一代理重新注册,因此,与正常运行的多代理站点相比,该代理将面临更高的资源需求,尤其是在具有大量 VDA 的站点中。

本地主机缓存使用 Microsoft LocalDB,它在任务管理器中作为 sqlserver.exe 进程显示。它已被配置为使用最多 1 GB 的内存来缓存数据库缓冲池。但是,由于 SQL 引擎需要内存用于自身和其他较小的缓存,因此该过程将超出此范围。通常,中断时间越长,在中断模式下访问的资源越多,LocalDB 内存使用量就会越多。但是,恢复站点数据库连接后,sqlserver.exe 将保留此内存,而不会立即将其返回到主池。

中断模式下 CPU 插槽和内核的影响

在以前的 XenApp 和 XenDesktop 版本中,管理员不一定关心代理(控制器)计算机的 CPU 配置:物理机或虚拟机中插槽和内核数量的布局。

本地主机缓存使用名为 LocalDB 的 SQL Server 运行时版本,该版本具有特定的许可,将其限制为四个内核或单个套接字中的较小者。当物理机或虚拟机配置了多个套接字且仅使用单核或双核时,这可能会对性能产生显著影响。具有4个套接字和每个套接字一个内核的代理机器将限制LocalDB使用单个内核,而配置为1插槽4核机器的相同虚拟机意味着LocalDB可以访问所有4个内核(尽管与其他进程共享它们)。在中断模式下,LocalDB 将运行与正常操作期间相同的代理和 SQL 代码。许多 SQL 查询可能占用 CPU 资源,并且会直接影响中断模式下的代理性能。

其他因素包括站点配置本身:

  • 已发布应用程序的数量
  • 被代理的用户数量
  • 用户尝试启动会话的速率
  • Active Directory 性能

随着代理 CPU 总利用率接近 100%,代理响应时间将增加,登录将需要更长的时间来处理,某些登录尝试可能会失败。

拥有多个经纪人的站点

在站点中断模式下,只有一个 Broker 处理注册和登录请求。在多经纪商站点中,将进行选举过程以提名将在中断期间处于活动状态的经纪人。但是,这个选举过程没有考虑经纪人可用的实物资源。这意味着,在经纪人拥有不同数量资源的站点中,当选的经纪商不一定在CPU或RAM方面最强大,这可能会导致中断模式下的性能不佳。每个 Broker 都必须满足本地主机缓存的其他要求,以防它被选中。

与站点数据库同步

CitrixConfigSync 服务负责将数据从站点数据库导入代理的本地副本。它监视站点数据库中的站点配置更改,并在发生更改时触发新的导入。在导入开始之前创建当前本地数据库的副本。站点中的资源(如 VDA)数量越多,导入所需的时间就越长,但对于具有 5000 个 VDA 的站点,导入时间应少于 10 分钟。

数据库位置

本地数据库存储在:

C:\Windows\ServiceProfiles\NetworkService\HaDatabaseName.mdf

为确保可靠性,CitrixConfigSync 服务会在开始新的站点数据库同步之前对先前成功的同步数据库导入进行备份。如果由于任何原因同步未成功,则在成功完成同步之前使用备份。不应手动复制数据库。

本地主机缓存与连接租用的比较

  连接租用 本地主机缓存
磁盘空间 建议使用 2 GB 取决于站点配置。对于拥有 125 K 用户的 50 台 RDS 主机, 使用 300 MB。
RAM 100 MB 3 GB,大约 1GB 用于 SQL Server,2 GB 用于高可用性服务和 CitrixConfigSync 服务。
是时候同步配置了 取决于 IOPS; 40,000 个 VDA: 约 26 分钟 5,000 个 VDA:大约 7 分钟
停机期间的激活时间 150 秒,30 秒默认 SQL 超时 + 120 秒等待时间(可配置) 取决于 VDA 的数量以及与代理的上次注册同步。在中断模式下,只有单个代理可用于 VDA 注册,因此对于大量 VDA,可能需要几分钟才能注册所有 VDA。
是时候恢复正常运行了 租赁停用 120 秒,然后 VDA 必须向经纪商重新注册 如上所述,VDA 需要从二级代理注销注册并在主代理处重新注册。
支持的 VDA 数量 50,000 5,000. 一个站点可以有超过此值,但同步站点数据库所需的时间将随着 VDA 数量的增加而增加。具有大量 VDA 的单个 Broker 的性能可能会导致在中断期间无法代理某些连接。
停机期间的现场管理

配置本地数据库内存限制

用于缓存的 LocalDB 进程限制为 1 GB RAM,这通常不需要更改。如果需要,可以更改此值;为了使更改生效,站点必须处于正常运行(而不是中断模式),并且必须强制进行站点数据库同步。

要将内存减少到 768 MB,请执行以下操作:

步骤 1. 编辑文件 C:\Program Files\ Citrix\ Broker\ 服务\ HighavailabilityService.exe.config。

查找 <appSettings> 部分并添加一个条目:

<add key="MaxServerMemoryInMB" value="768" />

步骤 2. 要强制数据库同步,请停止高可用性服务。如果 sqlserver.exe 正在运行,请使用任务管理器或 PowerShell 将其停止。

步骤 3. 现在对站点进行微不足道的更改,例如通过添加 “.” 更改交付组的描述,然后再次将其删除。然后,启动高可用性服务;这将启动 sqlserver.exe 并进行同步。

过多地减少内存会影响性能,因此不建议这样做。但是,将其增加到 2 GB 并不能显著提高性能,而且 CPU 资源比 RAM 更像是一个瓶颈。

启用或禁用本地主机缓存

可以禁用连接租用和本地主机缓存,但一次只能有一个处于活动状态。

set-brokerSite — 连接租赁已启用 $False

设置经纪人站点 — 本地主机缓存已启用 $True

限制

必须先分配桌面,然后才能在中断模式下使用它们。未分配的桌面将不可用于代理。这可能会导致桌面不可用并报告 “处于维护模式”,如果在同步所有分配之前发生中断,尽管实际上已为用户分配了桌面。

在默认配置中,在中断模式下不支持池桌面。有一种解决方法,但它具有潜在的安全性和性能影响。如果将包含池桌面的交付组配置为注销时不重新启动,则该组中所有已打开电源的池桌面都将在中断模式下可用。但是,用户注销后,桌面将不会处于干净状态,因为桌面未重新启动。在任何情况下,这都可能是一个安全问题。如果该桌面的下一个用户是该桌面的本地管理员,则可以访问以前用户的数据。尽管标准(非管理员)用户不太关心这种风险,但请记住,随着时间的推移,应用程序可能会出现不当行为并导致性能问题。重要信息: 管理员应仔细考虑使用此变通方法在中断模式下使用未重新启动的池桌面的潜在影响。

与连接租用一样,在中断期间不能对站点进行任何更改;数据库实际上是主站点数据库的快照,每次进行新的同步时都会丢弃该数据库。

压力条件下 6 和 8 vCPU 代理的性能比较

一个站点配置了 50 个 RDS 工作进程和 5075 个 VDI VDA。每个 RDS 工作线程都能支持 2500 个模拟用户。启动速率设定为每秒 20 个用户。网站中添加了不同数量的已发布应用程序。

对于 RDS 工作人员, 为 VDI 5075 启动了 100,000 个用户。

测试是在正常模式和本地主机缓存操作(中断)模式下进行的。

在 6 vCPU 系统中,CPU 余量很小,例外情况也很少 0 <10) occurred when the published app count was >。

组策略禁用了 Windows 更新,因为在多次运行期间,发现 tiworker.exe 进程(Windows 安装程序模块)在很长一段时间内几乎使用了整个内核。这导致了大量的启动失败,因此重新运行了测试。代理处理器已经相当老了,但是 tiworker 进程将消耗较新处理器的单个内核,从而影响测试。

虚拟机管理程序配置

  • XenServer 7.0
  • AMD 皓龙 8431 2.4 GHz — 4x6 内核
  • 128 GB 内存
  • 已启用读缓存
  • Windows 存储服务器 2012R2 带基于固态硬盘的存储

经纪商配置

  • 2 个带有 3 个内核的插槽和 2 个带 4 个内核的插槽
  • 10 GB 内存
  • Windows Server 2016
  • 每个 VDA 类型的单个交付组
  • 所有应用程序对用户可见
  • XenDesktop 7.12

StoreFront 配置

  • 6 台StoreFront 服务器
  • Windows Server 2016
  • 4 vCPU
  • 10 GB 内存

NetScaler 配置

  • VPX 8000 版本 11.063.16

SQL Server 配置

  • 英特尔 E5-2630 2.3GHz 2x12 内核
  • SQL Server 2012
  • 64 GB 内存

注意: 只有站点数据库处于脱机状态;在测试期间仍可访问监控和配置数据库。这意味着监控服务在测试期间消耗了一些 CPU。

显示登录响应时间的图形

通常,随着应用程序数量的增加,登录响应时间会增加,中断响应时间会比正常操作更糟糕。增加 vCPU 的数量可以缩短响应时间。请记住,测试中使用的CPU相当陈旧,更现代的CPU通常会提供更好的性能。

显示登录时间的图表

“理论上最小” 行是指如果环境能够每秒处理 20 次启动,则为 100,000 名用户登录所需的绝对最短时间,即 1 小时 23 分 20 秒。在这些测试中,0 个应用程序行在 6 vCPU 的情况下管理了 1:30:57,在 8 vCPU 的情况下管理了 1:30:48。Active Directory 域的性能将对用户进行身份验证的速度产生一定影响。

显示本地主机高速缓存本地数据库内存使用情况的图形

在正常情况下,LocalDB 内存使用量在运行期间会增加,除非系统承受压力,否则会挂在该内存上;处理的用户越多,使用的内存就越大,最高可达到 1 GB 的限制。在第一个 VDI 测试中,LocalDB 没有释放之前运行的 RDS 的内存。对于后续的 VDI 测试,代理在测试之前已重新启动,并且使用的内存较少。

显示本地主机缓存高可用性服务内存使用情况的图形

显示本地主机缓存 CPU 使用情况的图形

注意: 值已标准化为系统总CPU,因此在 8 个 vCPU 设置中,33.33% 是六个内核中的两个,30% 是 2-1/2 个内核。

术语 “关闭” 是指正常的站点操作;“开” 表示本地主机缓存处于活动状态。

即使在正常操作下,每秒20个用户的请求启动速度对经纪商来说也非常苛刻。在正常运行下,6 vCPU 系统没有余量;代理 CPU 会随着已发布应用程序数量的增加而增加,从而导致响应时间变慢。当本地主机缓存处于活动状态时,辅助代理 (HA) 服务必须与 LocalDB (SQL) 争夺 CPU 资源,从而使响应时间比正常操作更差。

在8 vCPU系统中,有一些余量,LocalDB将向上扩展,但是在这种环境中,尽管仍有少量的CPU可用,但它仍达到2-1/2内核的峰值。

在正常操作期间,除非进行同步,否则 LocalDB 不会消耗 CPU。

在中断期间,主代理几乎不使用 CPU。

数据库大小

对于 5075 VDI 配置,LocalDB 约为 40 MB,对于 100,000 个 RDS,则在 100-300 MB 之间变化,具体取决于应用程序和登录次数。由于数据库的副本是在新导入开始之前获取的,因此为 LocalDB 留出 1 GB 的空间。

摘要

在站点数据库中断期间,本地主机缓存支持比连接租用更广泛的资源和条件,但在运行时需要更多的 CPU 和内存。

在多个经纪商站点中,任何经纪商都可能被选为中断经纪人,因此所有经纪人都必须有足够的资源来应对中断模式。没有对经纪商资源进行评估,因此在经纪人越来越少、更强大的站点中,在中断期间有可能选出最弱势的经纪人。

内核和插槽的布局必须被视为经纪商设计的一部分。

已发布应用程序的数量将影响登录响应时间和最大登录吞吐量。

CPU 资源不足的代理可能会导致启动失败。

与连接租用相比,在本地主机缓存中断模式下,另外两个内核和 2 GB RAM 是测试性能的良好起点。

1 GB 的磁盘空间足以容纳 LocalDB 数据库。

过载的代理将导致连接失败。

本文由 Joe Deller 撰写。