Cloud Connector 的扩展和大小注意事项

在评估 Citrix Virtual Apps and Desktops 服务以确定规模和可扩展性时,请考虑所有组件。根据您的特定要求,研究和测试 Cloud Connector 和客户管理的 StoreFront 的配置。缩小计算机大小会对系统性能产生负面影响。本文提供了测试的最大容量的详细信息,以及 Cloud Connector 计算机配置的最佳实践建议。

摘要

此摘要中的所有结果均基于本文档的详细信息部分中配置的测试环境的结果。不同的系统配置可能会产生不同的结果。

测试的主要结果:

  • Citrix Virtual Apps and Desktops 服务大小和可扩展性
    • 对于托管不超过 5000 个工作站 VDA 的站点,建议使用一组三个 4-vCPU 的 Cloud Connector。
      • 这是一个 N+1 高可用性配置。
    • 与使用 Citrix 管理的 StoreFront 相比,使用客户管理的 StoreFront 启动 20000 个会话到 100 个服务器 VDA 的速度提高了 57%。
    • 预配 1000 个 VM 平均需要 140 分钟。
  • Citrix Virtual Desktops Essentials
    • 对于 1000 台 Windows 10 VM,建议在 Azure Standard_A2_v2 VM 上托管两个 Cloud Connector。
    • 向 Azure 中托管的 Windows 10 VM 启动 1000 个会话需要不到 20 分钟。
    • 测试发现,从用户登录 StoreFront 直到用户收到具有默认设置的功能性 VDI 桌面,大约需要 44 秒。
    • 在 Azure 中配置 1000 台 Windows 10 VM 平均需要 8 小时。

概览示意图

  • Citrix Cloud 负责管理 Cloud Connector 服务,客户负责管理计算机。
  • Citrix Virtual Desktops Essentials 的会话启动测试使用 NetScaler 设备。所有其他会话启动测试都使用到 StoreFront 的直接连接。

测试方法

进行了测试,以增加负载并测量环境组件的性能。通过收集性能数据和过程时间(例如登录时间、计算机创建时间)对组件进行监视。在某些情况下,专有的 Citrix 模拟工具用于模拟 VDA 和会话。这些工具旨在通过与传统 VDA 和会话相同的方式使用 Citrix 组件,而无需满足托管实际会话和 VDA 的相同资源要求。我们执行了以下测试:

  • 会话登录风暴:模拟大量登录周期的测试
  • VDA 注册风暴:模拟大量 VDA 注册周期的测试。例如,遵循升级周期或中断恢复。
  • Machine Creation Service 预配:测量执行任务(例如复制主映像、创建 Active Directory 帐户和创建计算机)的时间的测试。

我们使用从这些测试中收集的数据为 Cloud Connector 的大小调整建议。测试执行详细信息如下。

会话登录风暴测试

会话将在客户管理和 Citrix 管理的 StoreFront 服务器上单独启动。针对每个环境运行 1000 个会话、5000 个会话和 20000 个会话测试。我们收集了 StoreFront 登录、资源枚举、ICA 文件检索和活动桌面时间。活动桌面时间是指从 ICA 文件启动到资源完全加载并准备好使用的时间。

对于某些测试场景,我们使用模拟工具来方便测试较大的用户数量。模拟工具允许使用的硬件少于运行 5000 或 20000 个实际会话所需的硬件。这些模拟的会话将完成正常 StoreFront 登录、资源枚举和 ICA 文件检索过程,但不启动活动桌面。相反,模拟工具向 ICA 堆栈报告会话已启动。从 Broker 代理到 Broker 服务的所有通信都与实际会话的通信一致。性能指标是从 Cloud Connector 收集的。

为了确定环境如何响应会话启动,在整个测试期间保持了 25 个会话启动的持续并发性。因此,测量结果显示系统在整个测试过程中处于负载过轻的结果。

VDA 注册风暴测试

在 VDA 注册风暴中,会同时注册数百个或数千个 VDA 以模拟站点恢复。大批量 VDA 注册通常会在升级周期后每两周进行一次,在“星期一上午”场景中,或者当系统从客户管理的计算机与 Citrix 管理的服务之间的中断中恢复时进行。使用 5000 个 VDA 进行测试,并通过在每次测试期间收集性能数据来监视 Cloud Connector。数据包括 Perfmon 计数器(CPU、内存、磁盘利用率)和 VDA 注册时间。

Machine Creation Service 预配测试

通过创建具有不同计数的目录来执行预配测试。测量各种任务(主映像复制、AD 帐户创建和计算机创建)的时间以衡量性能。我们在 Azure 中测试了目录大小增加情况。Azure 和客户管理的虚拟机管理程序都进行了 1000 次计算机预配测试。Azure 中的测试仅限于 Windows 10 VM,因为 Windows 10 是 Citrix Virtual Desktops Essentials 唯一支持的操作系统。客户管理的虚拟机管理程序在 Windows 10 和 Windows 2012 R2 上进行了测试。

测试环境

测试环境配置包括 Citrix Cloud Connector、Citrix Virtual Apps and Desktops 服务以及 Citrix Virtual Apps and Desktops 组件。本文提供了我们使用的计算机和操作系统规格,因此您可以将我们的配置和测试结果与您自己的配置和要求进行比较。

使用的工具

内部测试工具从被测计算机收集性能数据和指标,并推动会话启动。此专有工具可协调用户会话启动到 Citrix Virtual Apps and Desktops 环境,并提供收集响应时间数据和性能指标的集中位置。实质上,测试工具管理测试并收集结果。

测试配置 - Citrix Virtual Apps and Desktops

下面是 Citrix Virtual Apps and Desktops 测试期间使用的计算机和操作系统规范的列表。

  • Cloud Connector:
    • 方案一: 两个 Windows 2012 R2、2 个 vCPU、4 GB 内存
    • 方案二: 量个 Windows 2012 R2、4 个 vCPU、4 GB 内存
  • StoreFront(客户管理): 一个 Windows 2012 R2、8 个 vCPU 和 8 GB 内存
  • 虚拟机管理程序: 八个VMware vSphere ESXi 6.0 Update 1、HP ProLiant BL 460c Gen9,两个 Intel E5-2620 CPU、256 GB 内存
  • 虚拟机管理程序存储: NetApp 3250 上的 2-TB NFS 共享
  • VDA: Windows 2012 R2 和 Windows 10 32 位 Build 1607

测试配置 - Citrix Virtual Desktops Essentials

会话是从 100 台 Windows 2012 R2 客户端启动器计算机启动的。会话已针对 Azure 中托管的 Windows Active Directory 进行身份验证。漫游配置文件存储在 Azure 中的 Windows 文件服务器上。

  • VDA: 1000 个 Windows 10 64 位 Build 1607、2 个 vCPU、7 GB 内存(Standard_D2_v2 实例)
  • 客户端: 100 个 Windows 2012 R2 服务器、8 个 vCPU、8 GB 内存
  • 域控制器: 两个 Windows 2012 R2、4 个 vCPU、14 GB 内存(Standard_D3_v2 实例)
  • 文件服务器: 一个 Windows 2012 R2、DS11 实例
  • NetScaler VPX: 一个 NetScaler 11.0、具有 1000 个 Platinum 许可证的 Standard_D3_v2 实例
  • Cloud Connector:
    • 方案一: 两个 Windows 2012 R2、2 个 vCPU、4 GB 内存(Standard_A2_v2 实例)
    • 方案二: 量个 Windows 2012 R2、4 个 vCPU、74 GB 内存(Standard_A3 实例)
  • StoreFront(客户管理): 一个 Windows 2012 R2、DSv2 实例

客户管理的计算机注意事项

客户管理的计算机可以位于客户办公室、数据中心或云帐户(例如 Azure 或 AWS)中。根据我们的定义,客户管理的计算机完全处于客户控制之下。客户管理的计算机包括:Cloud Connector、StoreFront 服务器、RDS 服务器、VDI 计算机和 Remote PC Access 计算机(测试期间未涵盖)。为简洁起见,我们在本报告中将 RDS 服务器、VDI 计算机和 Remote PC Access 计算机统称为 VDA。

StoreFront 服务器

测试 Citrix Virtual Apps and Desktops 服务时,我们使用了 8-vCPU、8 GB 内存计算机作为客户管理的 StoreFront 服务器。对于 Citrix Virtual Desktops Essentials 测试,我们为客户管理的 StoreFront 服务器使用了 Azure Standard_DS2_v2(2 个 vCPU、7 GB 内存)。请参阅 StoreFront 规划指南,为您的环境正确调整 StoreFront 服务器的大小。

Cloud Connector

我们测试了托管在 VM 上的客户管理的 Cloud Connector,这些 VM 在一个场景中配备 2-vCPU 和 4 GB 内存,在另一个场景中配备 4-vCPU 和 4 GB 内存。在 Azure 中,Cloud Connector 在 Standard_A2_v2(2 个 vCPU、4 GB 内存)和 Standard_A3(4 个 vCPU、7 GB 内存)实例上进行了测试。

在我们的测试中,Cloud Connector 部署在高可用性集中(它们的负载不平衡)。虽然本文档侧重于测试包含两个 Cloud Connector 的环境,但建议使用 N+1 组三个 Cloud Connector。本报告的其余部分重点介绍 Cloud Connector 以及如何调整其大小以获得最佳性能。

测试结果

VDA 注册风暴

VDA 注册风暴测试提供了显示 Cloud Connector 大小调整与环境稳定性之间的关系的数据。在客户管理的位置与 Citrix 管理的服务之间发生网络中断的情况下,将测试环境稳定性。当 Delivery Controller 和站点数据库升级时(通常每两周升级一次),可触发 VDA 注册风暴。

Cloud Connector CPU 大小比较 2 个 vCPU 与 4 个 vCPU

Cloud Connector CPU 大小比较

  • 平均使用情况相似,但 2-vCPU 计算机的 CPU 在测试期间有压力,偶尔会观察到 VDA 取消注册。
  • 为了保持稳定,建议对大约包含 5000 个 VDA 的站点使用 4-vCPU Cloud Connector。
  • 对于托管 2500 个 VDA 的站点,建议使用 2-vCPU Cloud Connector。
  • Cloud Connector 是一个高可用性集,未进行负载平衡。
  • 对于托管 5000 个 VDA 的站点,我们不推荐使用 2-vCPU Cloud Connector 的原因之一是计算机分配的随机性。由于 Cloud Connector 未进行负载平衡,因此您无法预测要传送到任何一个 Cloud Connector 的负载大小。有时,我们发现超过 60% 的负载传送到一台计算机。
VDA 数量 需要 Cloud Connector
< 2500 2 个 VM + 1,每个 VM 配备 2 个 vCPU
< 5000 2 个 VM + 1,每个 VM 配备 4 个 vCPU

Cloud Connector 高可用性对 VDA 注册风暴时间比较

Cloud Connector 大小 VDA 计数 注册时间
2 vCPU 5000 11:03
4 vCPU 5000 5:46
  • 配备 4 个 vCPU 的 Cloud Connector 在测试过程中证明更加稳定。
  • 当 Cloud Connector 配备 4 个 vCPU 时,VDA 注册速度更快。
  • 在使用 2-vCPU Cloud Connector 进行测试期间,观察到 VDA 重新注册。
    • 注册尝试超时或 VDA 通信检测信号延迟时,可能会发生重新注册。

5000 个 VDA 的注册风暴期间 Cloud Connector 上的组件使用内存量

内存使用量示意图

  • 此图表是 Citrix 组件和 Microsoft LSASS(Local Security Authority Subsystem Service,本地安全机构子系统服务)在注册风暴测试期间的内存使用量的详细视图。
  • Cloud Connector 上的 LSASS 过程在注册和会话启动中起着重要作用。Citrix Cloud 服务进行的所有 Active Directory 身份验证都通过 Cloud Connector 代理到客户管理的 Active Directory。
  • VDA 注册期间内存使用量达到高峰,在所有 VDA 成功注册后会降低。
  • 在配备 4 GB 内存的 Cloud Connector 上观察到高内存利用率。

会话启动 (Citrix Virtual Desktops Essentials)

使用 Citrix Virtual Desktops Essentials 进行了 1000 次会话启动测试。测试比较不同大小的 Cloud Connector 实例。我们测试了 Standard_A2_v2(2 个 vCPU、4 GB 内存)和 Standard_A3(4 个 vCPU、7 GB 内存)实例。

在会话启动测试期间,Citrix 管理的 StoreFront 的 CPU 使用率

Connector CPU 使用率示意图

  • 测试期间 CPU 争用较低。在高负载会话启动测试期间,Standard_A2_v2 实例大小更能够处理 1000 台计算机 VDI 部署。
  • 对于此站点大小,Standard_A3 实例被视为过多,因此我们继续对 Standard_A2_v2 进行细分。
  • 较大的 VDI 站点可能会看到使用 Standard_A3 的要求。

在 1000 个会话启动期间,A2v2 Cloud Connector 上排名前几位的组件的 CPU 使用率

CPU 使用率示意图

Cloud Connector 上运行的更多进程不会显示,因为这些进程没有注册有意义的指标。

  • Citrix Remote Broker Provider (XaXdCloudProxy) 处理客户管理的 VDA 计算机与 Citrix 管理的服务 (Delivery Controller) 之间的通信。
  • Cloud Connector 上的 LSASS 处理所有 Active Directory 身份验证。Citrix Cloud Services 进行的身份验证通过 Cloud Connector 代理到客户管理的 Active Directory。
  • 此图表显示了在测试期间收到较高负载量的单个 Cloud Connector 的使用量。测试中的额外 Cloud Connector 显示 CPU 使用率较低,且未包含在图表中。

Cloud Connector 内存使用量实例比较

Cloud Connector 内存示意图

  • Standard_A2_v2(4 GB 内存)上的可用内存较低显示 Standard_A2_v2 VM 上的内存利用率较高。
  • 内存利用率高是由 Azure 中保持 1000 台计算机的电源状态的 Citrix Remote HCL Server (RemoteHCLServer) 进程造成的。
    • 由于 Azure API 速率限制,无法定期查询状态。
  • 在我们的测试后对 Citrix Remote HCL Server (RemoteHCLServer) 进行的更改允许 Delivery Controller 将计算机状态直接传达到 Azure。
    • 此更改显著降低了内存使用量,并允许 Standard_A2_v2 实例管理 1000 个 VDA 站点而不会出现问题。

会话启动时间

Standard_A2_v2 和 Standard_A3 与客户管理和 Citrix 管理的 StoreFront 服务器的比较

  客户管理的 StoreFront* 客户管理的 StoreFront* Citrix 管理的 StoreFront Citrix 管理的 StoreFront
  A3 A2v2 A3 A2v2
身份验证 561 毫秒 575 毫秒 1996 毫秒 2051 毫秒
枚举 1132 毫秒 1054 毫秒 1410 毫秒 1577 毫秒
登录总数 1693 毫秒 1629 毫秒 3406 毫秒 3621 毫秒
         
检索 ICA 文件 3464 毫秒 3659 毫秒 4730 毫秒 6222 毫秒
操作系统登录完成 38.83 秒 41.91 秒 37.67 秒 40.08 秒
总启动次数 42.3 秒 45.6 秒 42.4 秒 42.4 秒

时间是所有测试运行的平均值。Azure 中的客户管理的 StoreFront 服务器: Standard_DS2_v2(2 个 vCPU、7 GB 内存)

  • Citrix 管理的 StoreFront 会话在负载过轻时会遇到时间缓慢的问题,因为 StoreFront 必须通过 WAN 借助客户管理的 Active Directory 进行身份验证。
  • 测试期间,客户端计算机与 NetScaler 之间大约存在 30 毫秒的延迟。
  • 当环境受到压力时,将 Standard_A3 实例用于 Cloud Connector 时,会话启动平均会缩短 3 至 4 秒。
    • Standard_A3 VM 的 CPU 核心数量是 Standard_A2_v2 的两倍
    • 在测试期间,Standard_A2_v2 实例上的内存利用率较高。
      • 当我们从 Azure ARM 部署中的 Cloud Connector 中删除 RemoteHCLServer 通信时,解决了高内存利用率问题。

1000 个 Windows 10 会话的会话登录时间

会话登录示意图

  • 所有计算机在测试前都已打开电源。
  • 测试过程在大约 8 分钟的时间内启动了 1000 次课程。
  • 使用 Standard_D2_v2 实例 Windows 10 64 位 VDA 的活动桌面的平均时间大约为 37.67 秒。
  • 此图表显示测试过程中的单个登录时间,即从检索 ICA 文件到显示有效的可用桌面为止。
    • 绿色和黄色区域分别表示一个和两个标准差。
  • 虽然会话启动时间是一致的,但存在一些异常值。网络条件的瞬间变化可能会导致异常值,影响:
    • 通过 Cloud Connector 代理的 NetScaler 上的 Secure Ticket Authority (STA) 票据交换。
    • 通过 WAN 建立 HDX 连接。
    • Azure 存储。测试使用标准存储。

模拟的会话启动

模拟的会话启动测试会给 Cloud Connector、Delivery Controller 和站点数据库带来压力。模拟的会话启动测试组件处理大量并发登录并在持续负载下维持这些会话的能力。测试了 5000 次和 20000 次的会话次数。本文档重点介绍了 20000 次会话测试。两个测试之间的启动速率和组件 行为几乎相同。20000 个会话测试运行时间更长,可以更广泛地了解随时间推移的服务使用情况。25 个会话尽可能快地同时启动。尽可能快地启动会话的设置允许被测系统指定环境响应连接的速率。

会话启动测试期间 Cloud Connector 高可用性集 CPU 使用率

Cloud Connector 高可用性示意图

  • 此图表显示了在 20000 个会话启动期间 Cloud Connector CPU 使用率的比较。
  • 部署了两个 Cloud Connector,用于压力和负载测试。为了实现高可用性利用率,建议使用三个 Cloud Connector 的 N+1 部署。
  • 测试期间没有观察到 CPU 争用情况。

20000 个会话启动测试期间的 Cloud Connector CPU 使用率(按组件)

Cloud Connector CPU 示意图

  • LSASS(本地安全机构子系统服务)在会话登录期间使用 CPU,同时使用 Citrix 管理和客户管理的 StoreFront。
  • 来自 Citrix 管理的服务的所有身份验证都必须遍历 Cloud Connector,以便与客户管理的 Active Directory 进行通信。

20000 个会话启动期间的内存使用量(按组件)

内存使用量示意图

  • 会话启动期间内存压力较低。
  • 大多数组件的内存使用量在整个测试过程中不会发生变化,因为观察到的最大值和平均值几乎相等。

客户管理和 Citrix 管理的 StoreFront 服务器的会话启动比较

  客户管理的 StoreFront* Citrix 管理的 StoreFront
身份验证 261 毫秒 1629 毫秒
枚举 1075 毫秒 1275 毫秒
登录总数 1336 毫秒 2904 毫秒
     
检索 ICA 文件 2132 毫秒 2715 毫秒

注意:

用于测试的客户管理的 StoreFront 服务器是一个 8 vCPU、8 GB 内存、2012 R2 VM。Citrix 管理的 StoreFront 位于 Delivery Controller 上,并与其他 Citrix 服务共享资源。

  • 由于通过 WAN 进行 AD 身份验证所需的时间,客户管理的 StoreFront 服务器的使用速度会更快。
  • 在测试期间,Cloud Connector 与 Delivery Controller 之间存在大约 30 毫秒的延迟。
  • 当 StoreFront 服务器负载过轻时,使用 Citrix 管理的 StoreFront 服务器与客户管理的 StoreFront 服务器的登录过程有 2 秒的差异。
  • 观察到检索 ICA 文件的平均时间有 1.2 秒的差异。这是一个 83% 的增长。
  • 对于需要大量并发会话启动的客户,建议使用客户管理的 StoreFront 服务器。

Machine Creation Service 预配

Citrix Virtual Desktops Essentials MCS 测试 Azure Resource Manager

Machine Creation Service 允许您在 Azure 中创建和删除虚拟桌面 (VDA)。第一步是创建一个 Windows 10 VHD,然后将 VHD 上载到 Azure。主映像是基于 VHD 创建的。Citrix Virtual Desktops Essentials 允许您基于主映像创建虚拟机。

计算机计数 主映像副本 Active directory 帐户创建 计算机创建
10 30 分钟 1 分钟 7 分钟
100 30 分钟 7 分钟 50 分钟
250 40 分钟 8 分钟 2 小时
500 55 分钟 15 分钟 4 小时
1000 65 分钟 30 分钟 8 小时

时间基于多次测试运行的近似值,并且可能会有所差别。

  • 我们使用各种计算机计数测试了计算机创建过程,以测量所需的时间:
    • 复制主映像
    • 创建计算机帐户
    • 预配计算机
  • 时间不会线性增加,因为必须将主映像的副本复制到每个存储帐户。复制将并行进行,并且随任务数的增多而变得更慢
    • 每个存储帐户的计算机限制为 40 台。此限制需要为 1000 个 VM 环境提供 25 个存储帐户。
    • 每个资源位置的计算机限制为 760 台。
  • Active Directory 帐户创建必须通过 Cloud Connector 代理,这会增加完成任务所需的时间。Active Directory 帐户以大约每分钟 33 个的速率创建。
  • 测试使用 Standard_A2_v2 Cloud Connector。没有观察到资源瓶颈。

Citrix Virtual Apps and Desktops 服务 MCS 测试

MCS 预配测试是在 VMware ESXi 6.0 虚拟机管理程序上执行的。群集中有八个 vSphere 主机,并且 NetApp 共享上的共享存储为 NFS。

操作系统 计算机计数 主映像副本 Active directory 帐户创建 计算机创建
WIN 2012 R2 100 4 分钟 3 分钟 4 分钟
WIN 2012 R2 1000 5 分钟 30 分钟 100 分钟
WIN 10 32 位 100 4 分钟 3 分钟 4 分钟
WIN 10 32 位 100 4 分钟 3 分钟 4 分钟

时间基于多次测试运行的近似值,并且可能会有所差别。来自这些运行的测试数据在表中显示平均值。

  • 计算机创建过程所需的时间与 XenApp 和 XenDesktop 7.x 版本所需的时间相似。这些测试中的主要区别是 Active Directory 帐户创建。在云环境中,帐户创建必须通过 Cloud Connector 代理。云环境中的 Active Directory 帐户以大约每分钟 33 个的速率创建。
  • 我们使用两个 4-vCPU、4 GB 内存 VM 针对 Cloud Connector 进行了测试。测试期间没有观察到资源争用情况。