本地主机缓存的规模和大小注意事项
本文包含有关本地主机缓存测试的详细信息，以及配置部署时的注意事项。有关本地主机缓存及其工作原理的一般信息，请参见本地主机缓存．
概述
Citrix虚拟应用和桌面服务中的本地主机缓存特性允许站点中的连接代理在中断时继续。在Citrix Cloud环境中，如果站点和管理控制台之间的WAN链接发生故障，就会发生中断。2017年12月，我们使用Citrix虚拟应用程序和台式机服务本地主机缓存功能测试了Citrix云连接器机器配置。本文档中提供的测试结果详细说明了2017年12月的测试最大值。最佳实践建议是基于那些经过测试的最大值。
本文假设读者可以根据推荐的标准设置和配置Citrix Cloud环境，其中至少有三个Cloud connector。
本地主机缓存仅支持每个资源位置或资源分区中的本地StoreFront。
当中断模式处于活动状态时，如果代理会话的选定云连接器发生中断，则第二个云连接器将成为选定的高可用性服务。选举之后，第二个云连接器接管代理会话。在云连接器虚拟机配置中，本地主机缓存特性仅使用一个多核cpu插槽。在这个场景中，我们推荐4核1插座的配置。
总结
本摘要中的所有结果都基于我们在下面的章节中详细配置的测试环境的结果。不同的系统配置产生不同的结果。
基于测试结果的关键建议
- 对于承载不超过5,000个工作站或500个服务器VDAs的高可用性站点，我们建议您配置3个专用于云连接器的虚拟机。每个Cloud Connector VM需要4vcpu和4gb RAM。此配置是N+1高可用性配置。云连接器部署在高可用性集中。云连接器不是负载平衡的。由于每个CPU只能处理有限数量的连接，因此CPU是与所支持的工作站或服务器VDAs数量相关的最大限制因素。
- 尽管本文档的重点是使用两个云连接器进行测试，但推荐使用N+1组3个云连接器。
- 在同步和导入新配置后，我们进行了会话启动测试，以比较本地主机缓存中断模式的活动和非活动。启动测试涵盖了针对各自可用工作站数量的5,000、20,000和1,000会话启动的场景。
- 针对5000个工作站VDAs启动了5000个会话
- 测试使用2个云连接器虚拟机，每个虚拟机有4个vCPU和4 GB RAM。基于N + 1配置的建议，生产环境应该包括3个满足这些规范的Cloud Connector vm。
- 本地主机缓存服务峰值消耗91%的CPU资源，平均可用内存为563 MB。
- 从高可用性服务检测到所有VDAs的中断到向高可用性服务(High Availability Service，现在是代理)重新注册大约需要10分钟。我们测量了从高可用性服务进入中断模式到高可用性服务准备再次代理会话的时间。
- 在500个服务器VDAs中启动20,000个会话
- 测试使用2个云连接器虚拟机，每个虚拟机有4个vCPU和4 GB RAM。基于N + 1配置的建议，生产环境应该包括3个满足这些规范的Cloud Connector vm。
- 本地主机缓存服务峰值消耗90%的CPU资源，平均可用内存为471mb。
- 从高可用性服务检测到所有VDAs都中断到向高可用性服务重新注册大约需要8分钟。我们测量了从高可用性服务进入中断模式到高可用性服务准备再次代理会话的时间。
- 针对1000个工作站VDAs启动了1000个会话
- 测试使用2个云连接器虚拟机，每个虚拟机有2个vCPU和4 GB RAM。基于N + 1配置的建议，生产环境应该包括3个满足这些规范的Cloud Connector vm。
- 本地主机缓存服务峰值消耗95%的CPU资源，平均可用内存为589 MB
- 从高可用性服务检测到所有VDAs的中断到向高可用性服务(High Availability Service，现在是代理)重新注册大约需要7分钟。我们测量了从高可用性服务进入中断模式到高可用性服务准备再次代理会话的时间。
- 针对5000个工作站VDAs启动了5000个会话
Citrix Cloud管理云连接器服务，客户管理机器。
测试方法
我们通过添加负载来进行测试，然后测量环境组件的性能:
- CPU
- 内存
- 数据库负载
- Citrix远程代理提供者服务
- Citrix高可用服务
我们收集性能数据、登录时间，或者两者都收集。在某些情况下，使用专有的Citrix仿真工具来模拟VDAs和会话。仿真工具被设计成以与传统vda和会话相同的方式运行Citrix组件，而不需要相同的资源需求来承载真实的会话和vda。
本地主机缓存支持一个高可用性服务，每个分区，而不是每个站点。例如，如果您有五个区域，则在每个区域中选择一个Cloud Connector作为代理。Citrix配置同步器服务负责导入Citrix管理的站点数据库。每次配置同步都会创建一个数据库，因此需要初始配置，例如在第一次使用数据库时编译存储过程。我们在配置同步之后执行了所有测试。
会话启动测试
在客户管理的StoreFront服务器上，我们启动了5,000和20,000个会话测试。监视工具收集StoreFront登录时间、资源枚举和ICA文件检索。
Citrix使用仿真工具来促进大批量用户测试。模拟工具是Citrix专有的，它允许我们在更少的硬件上运行测试，而不是在这些级别(5,000和20,000个会话)使用真实会话运行测试所需的硬件。这些模拟会话将通过正常的StoreFront登录、资源枚举和ICA文件检索，但不启动活动桌面。相反，模拟工具向ICA堆栈报告会话已经启动，并且代理代理和代理服务之间的所有通信都与实际会话的通信一致。性能指标是从Citrix云连接器中收集的。为了确定环境如何响应会话启动，在整个测试期间的任何给定时间都保持25个会话启动的持续并发。因此，测量结果显示了整个测试中系统在负载下的结果。
测试结果
会话启动
下表比较了在导入新的配置同步后，本地主机缓存停用模式活动和本地主机缓存停用模式不活动之间的会话启动测试。每个表都显示了测试中启动的会话数的结果。
5000工作站VDA会话
| 本地主机缓存中断模式未激活(正常操作)/平均定时 | 本地主机缓存中断模式主动/平均定时 | |
|---|---|---|
| 进行身份验证 | 193毫秒 | 95毫秒 |
| 列举 | 697毫秒 | 75毫秒 |
| 总登录时间 | 890毫秒 | 170毫秒 |
| 检索ICA文件 | 4191毫秒 | 156毫秒 |
20,000个服务器VDA会话
| 本地主机缓存中断模式未激活(正常操作)/平均定时 | 本地主机缓存中断模式主动/平均定时 | |
|---|---|---|
| 进行身份验证 | 135毫秒 | 112毫秒 |
| 列举 | 317毫秒 | 91毫秒 |
| 总登录时间 | 452毫秒 | 203毫秒 |
| 检索ICA文件 | 762毫秒 | 174毫秒 |
- 5000工作站VDA会话启动测试
- 当本地主机缓存中断模式处于非活动状态时，Citrix云连接器和Citrix交付控制器之间大约有30毫秒的延迟。
- 当StoreFront处于负载状态时，本地主机缓存中断模式活动与非活动的登录过程之间存在720毫秒的差异。
- 最大的时间差是在检索ICA文件时，时间差为4秒。这主要是因为云连接器执行代理，而通常StoreFront流量通过云连接器到Azure中的Citrix交付控制器并返回。
- 20,000服务器VDA会话启动测试
- 当StoreFront处于负载状态时，本地主机缓存中断模式是活动的还是非活动的，在登录过程中会有249ms的差异。
- 检索ICA文件的时间差约为1秒。
- 与5000个工作站的VDA会话启动相比，20,000个会话启动测试只包含500个服务器VDA，从而减少了从Citrix Delivery Controller到VDA的调用，从而降低了响应时间。
平均CPU使用率比较
| 会话启动测试 | 平均CPU % | CPU峰值% | |
|---|---|---|---|
| 5000工作站VDA会话 | 连接器1 | 8．3 | 38.2 |
| 连接器2 | 8．4 | 33.3 | |
| 5,000工作站VDA会话-本地主机缓存中断模式活跃 | 连接器1(当选的高可用性服务) | 42 | 91 |
| 连接器2 | 0．8 | 5 | |
| 20,000个服务器VDA会话 | 连接器1 | 23 | 62 |
| 连接器2 | 23 | 55 | |
| 20,000个服务器VDA会话-本地主机缓存停用模式活跃 | 连接器1(当选的高可用性服务) | 57 | 90 |
| 连接器2 | 0．8 | 6．6 |
- 该表比较了在5,000工作站VDA和20,000服务器VDA会话启动测试期间，Citrix Cloud Connector CPU使用情况与活跃的本地主机缓存中断模式和不活跃的本地主机缓存模式。
- 所有的云连接器都是4vcpu和4gb RAM
- 当选的高可用性服务机器的CPU总量分别达到91%和90%。值得注意的是，虽然非当选的高可用性服务没有太多的使用，但如果当选的高可用性服务出现故障，它可能会成为活动的。因此，云连接器具有相同的Clouc连接器规范至关重要。
可用内存使用情况
| 会话启动测试 | 平均可用内存(工作集MB) | 峰值可用内存(工作集MB) | |
|---|---|---|---|
| 5000工作站VDA会话 | 连接器1 | 636 | 657 |
| 连接器2 | 786 | 801 | |
| 5,000工作站VDA会话-本地主机缓存中断模式活跃 | 连接器1(当选的高可用性服务) | 563 | 618 |
| 连接器2 | 912 | 918 | |
| 20,000个服务器VDA会话 | 连接器1 | 1030 | 1195 |
| 连接器2 | 1178 | 1329 | |
| 20,000个服务器VDA会话-本地主机缓存停用模式活跃 | 连接器1(当选的高可用性服务) | 471 | 687 |
| 连接器2 | 1210 | 1227 |
- 该表比较了在5,000工作站VDA和20,000服务器VDA会话启动测试期间，本地主机缓存中断模式活动和本地主机缓存模式不活动的可用内存使用情况。
- 会话的数量会减少可用内存的数量。
- 当本地主机缓存关闭模式处于活动状态时，20000个服务器VDA会话会增加54.35% (559 MB)的内存使用量，主要是由于SQL服务器的内存消耗。
云连接器按组件的CPU使用率
| 会话启动测试 | 组件 | 平均CPU % | CPU峰值% |
|---|---|---|---|
| 5000工作站VDA会话 | 连接器1补丁 | 2．4 | 10．7 |
| 连接器1 XaXdCloudProxy | 3．5 | 18．5 | |
| 连接器2补丁 | 2．5 | 12.9 | |
| 连接器2 XaXdCloudProxy | 3．5 | 21.2 | |
| 5,000工作站VDA会话本地主机缓存中断模式激活 | 连接器1(选为高可用服务)LSASS | 12.9 | 29.5 |
| 连接器1(选为高可用性服务 | 14．7 | 49.7 | |
| 20,000个服务器VDA会话 | 连接器1补丁 | 7 | 12．2 |
| 连接器1 XaXdCloudProxy | 8．7 | 15.5 | |
| 连接器2补丁 | 7 | 12．5 | |
| 连接器2 XaXdCloudProxy | 9 | 15.7 | |
| 20,000个会话本地主机缓存停用模式激活 | 连接器1(选为高可用服务)LSASS | 4．3 | 17.2 |
| 连接器1(选为高可用性服务)高可用性服务 | 4．5 | 18．2 |
- 上表显示了在5000工作站VDA和20000服务器VDA会话启动测试期间，本地主机缓存中断模式处于活动状态时消耗最多CPU资源的进程，与本地主机缓存中断模式处于非活动状态时的进程相比。
- 当本地主机缓存中断模式处于非活动状态时，Citrix远程代理提供者服务(XaXdCloudProxy)是最高的CPU消耗者。
- LSASS (Local Security Authority Subsystem Service)在会话登录时使用CPU。来自Citrix管理的服务的所有身份验证必须遍历Citrix云连接器，以与客户管理的Active Directory通信。
- 使用Citrix高可用性服务代理会话，当本地主机缓存停用模式处于活动状态时，会导致更高的CPU占用率。此外，CPU使用率在5,000工作站VDA会话启动期间达到49.7%的峰值，而在20,000服务器VDA会话启动期间(500vda)仅为18.25%。差异是由于vda的数量。
- Cloud Connector 2没有任何有意义的指标，因为它不是当选的高可用性服务。
切换到本地主机缓存时的VDA重新注册时间
在交付控制器中断期间，5,000个工作站VDAs必须向选定的本地主机缓存代理重新注册。这个重新注册时间大约是10分钟。500个服务器VDAs的重新注册时间约为8分钟。
| 数量的共识 | 注册的时间 |
|---|---|
| 5000工作站的共识 | ~ 10分钟 |
| 500服务器的共识 | ~ 8分钟 |
停机时间
| 宕机事件 | 数量的共识 | 时间 |
|---|---|---|
| 进入中断模式 | 10分钟 | |
| 所选高可用性服务的重新注册时间 | 500 | ~ 8分钟 |
| 5000 | ~ 10分钟 | |
| 退出中断模式 | 10分钟 | |
| 向思杰交付控制器重新注册时间 | 500 | ~ 1.5分钟 |
| 5000 | ~ 5.5分钟 |
- 由于需要进行多次Citrix Delivery Controller运行状况检查，因此总共需要20分钟进入(10分钟)和退出(10分钟)停用模式。重新注册VDAs所需的时间增加了总停机时间。
- 如果网络反复地上下波动，则强制中断直到网络问题解决，以防止正常模式和中断模式之间的持续转换。
带有本地主机缓存的数据库和高可用性服务度量
| 会话启动测试 | 平均高可用性服务数据库事务/秒 | 峰值高可用性服务数据库事务/秒 |
|---|---|---|
| 5000工作站VDA会话 | 436 | 1344 |
| 20,000个服务器VDA会话 | 590 | 2061 |
上表显示了所选高可用性服务上的每秒数据库事务数。
StoreFront CPU使用率比较
| 会话启动测试 | 平均CPU % | CPU峰值% |
|---|---|---|
| 5000工作站VDA会话 | 4．5 | 32.4 |
| 5,000服务器VDA会话本地主机缓存停用模式 | 13．8 | 32.6 |
| 20,000个服务器VDA会话 | 11．4 | 22．1 |
| 20,000个服务器VDA会话-本地主机缓存停用模式 | 18．6 | 33.2 |
- 上表比较了在5,000工作站VDA和20,000服务器VDA会话启动测试期间，本地主机缓存中断模式处于活动状态和本地主机缓存模式处于非活动状态时的StoreFront CPU使用情况。
- StoreFront机器的规格如下:Windows 2012 R2, 8vcpu(2插槽，4核)，8gb内存
- 当本地主机缓存中断模式处于活动状态时，5,000工作站VDA的平均CPU使用率约增加9%，20,000服务器VDA会话启动测试的平均CPU使用率约增加7%。增加的主要原因是，当本地主机缓存停用模式处于活动状态时，IIS工作人员处理的请求更多。由于StoreFront处理会话的启动速度比关闭模式处于非活动状态时要快，所以会有更多的CPU占用。
StoreFront可用内存使用情况比较
| 会话启动测试 | 平均可用内存(工作集MB) | 峰值可用内存(工作集MB) |
|---|---|---|
| 5000工作站VDA会话 | 5731 | 6821 |
| 5,000工作站VDA会话本地主机缓存中断模式 | 5345 | 5420 |
| 20,000个服务器VDA会话 | 4671 | 4924 |
| 20,000个服务器VDA会话-本地主机缓存停用模式 | 4730 | 5027 |
- 上表比较了在5,000工作站VDA和20,000服务器VDA会话启动测试期间，当本地主机缓存中断模式处于活动状态和本地主机缓存模式处于非活动状态时StoreFront可用内存的使用情况。
- 当本地主机缓存模式处于活动状态时，在5,000工作站VDA会话启动测试期间，内存使用量增加了6.73%。
下表比较了在导入新的配置同步、启动1,000个会话到1,000个带有本地主机缓存的工作站VDAs、并使用配置了2个vCPU vm的Citrix Cloud Connectors后的active和inactive中断模式。
会话启动的比较
| 本地主机缓存停用模式未激活(正常操作) | 本地主机缓存停用模式已激活 | |
|---|---|---|
| 进行身份验证 | 359毫秒 | 89毫秒 |
| 列举 | 436毫秒 | 180毫秒 |
| 总登录时间 | 795毫秒 | 269毫秒 |
| 检索ICA文件 | 804毫秒 | 549毫秒 |
- 虽然StoreFront处于负载状态，但当本地主机缓存停用模式处于活动状态时，与本地主机缓存停用模式处于非活动状态时，登录过程中存在526毫秒的差异。
- 当本地主机缓存模式处于激活状态时，与本地主机缓存模式处于非激活状态时，检索ICA文件的时间相差255毫秒。这种差异会随着会话的次数而增加。
平均CPU使用率比较
所选的高可用性服务峰值达到了总CPU的95%，这表明1000工作站VDA是2vcpu云连接器VM的最佳配置。
平均内存使用比较
上面的图显示了在1,000工作站VDA会话启动期间，本地主机缓存中断模式为活动模式和非活动模式时Citrix Cloud Connector可用使用情况的比较。根据本地主机缓存停用模式，内存没有显著差异。
通过组件比较，云连接器的CPU使用率
上图显示了当本地主机缓存停用模式处于非活动状态时，消耗最多CPU资源的进程。
- 上图显示了在“本地主机缓存中断模式”激活时，消耗CPU资源最多的进程。
- 连接器2没有任何有意义的度量。
切换到本地主机缓存时的VDA重新注册时间
在交付控制器中断期间，1000个工作站VDAs必须向选定的本地主机缓存代理重新注册。重新注册时间约为7分钟。
带有本地主机缓存的数据库和高可用性服务度量
上面的图显示了所选高可用性服务上每秒的数据库事务数量。
随着区域数量的增加，对数据库导入时间的影响
测试站点中添加了一个额外的区域(带有一对自己的云连接器)，以了解其影响。第一个区域包含5500个独特的对象(2个目录)。辅助区域是第一个区域的镜像，有自己独特的对象，总共11000个对象。需要注意的是，本地主机缓存仅推荐用于对象不超过10,000的分区。在我们添加辅助区域之前，Cloud Connectors上的数据库导入时间大约是4分20秒。在我们添加了次级区域并在其中填充了11000个对象后，导入时间从大约30秒增加到大约4分50秒。增加更多目录对进口时间的影响很小。导致性能下降和导入时间增加的最大因素是分配的机器、用户和远程pc的数量。此外，5500个对象被划分到两个区域，并且导入时间保持不变
| 数量的区域 | 对象总数 | 导入的时间 |
|---|---|---|
| 1 | 5500年 | 4分20秒 |
| 2 | 11，000 | 4分50秒 |
| 2 | 5500年 | 4分20秒 |
连接器分级指导
为获得最佳性能，当启用本地主机缓存模式时，Citrix Cloud Connector的推荐配置如下。
建议1:使用使用Citrix云连接器的本地主机缓存模式支持1000个工作站VDAs
- 2台Windows 2012 R2虚拟机，每个虚拟机分配2个vCPU (1 socket, 2核)，4gb内存
- 这个建议的大小是基于峰值的Citrix Cloud Connector总体95%的CPU使用率和589 MB平均可用内存，而本地主机缓存模式是活动的
建议2:使用本地主机缓存和Citrix云连接器支持5,000工作站VDAs或500服务器VDAs
- 2台Windows 2012 R2虚拟机，每个虚拟机分配4个vCPU(1个插槽，4核)，4gb内存
- 推荐的分级是基于
- 5000工作站VDA会话启动，本地主机缓存模式激活
- 总体91%的峰值CPU使用率
- 563 MB平均可用内存
- 20,000个服务器VDA会话在本地主机缓存模式激活时启动
- 总体90%的峰值CPU使用率
- 471 MB平均可用内存
- 5000工作站VDA会话启动，本地主机缓存模式激活
有关一般可伸缩性调整的更多信息，请参阅Citrix云虚拟应用和桌面服务调整和可伸缩性考虑的白皮书。
测试环境
测试环境采用了内部开发的、专有的测试工具，以及按照以下部分中的规范配置的vm。
工具使用
我们使用内部测试工具从被测试机器收集性能数据和指标，并驱动会话启动。内部测试工具协调用户会话启动到Citrix虚拟应用程序和桌面环境。测试工具还提供了一个中心位置，我们可以在这里收集响应时间数据和性能指标。本质上，测试工具管理测试并收集结果。
测试配置- Citrix虚拟应用程序和桌面服务
以下是Citrix虚拟应用和桌面服务测试使用的机器和操作系统规格列表。
- 云连接器:
- 2台Windows 2012 R2虚拟机，每个虚拟机分配4个vCPU(1个socket, 4核)，4gb内存
- 2个Windows 2012 R2虚拟机，每个虚拟机分配2个vCPU (1 socket, 2核)，4gb内存
- 店面(Customer-managed):Windows 2012 R2, 8 vCPU(2插槽，每个4核)，8gb RAM
- 管理程序:Citrix XenServer 7.0 +升级，5倍HP Blade BL 460C Gen 9, 2倍Intel E5-2620 CPU, 256 GB RAM
- 虚拟机监控程序存储:2tb NetApp 3250的NFS共享
- 的共识:Windows 2012 R2
数据收集
我们从每个测试中收集以下指标:平均总体CPU、内存、组件(云进程)使用量增加。
- 切换到选择的本地主机缓存高可用性服务时的VDA重新注册时间
- 数据库和高可用性服务指标时，本地主机缓存停用模式是活跃的
- 会话启动比较，平均计时
- 身份验证
- 枚举
- ICA文件检索
- 增加分区数量时对数据库同步时间的影响
- 配置更改后同步所需的时间
RAM的大小考虑
SQL Server Express LocalDB可以使用高达1.2 GB的RAM(最多1gb用于数据库缓存，另外200 MB用于运行SQL Server Express LocalDB)。高可用性服务(本地主机缓存代理)最多可以使用1gb的RAM，如果停机时间持续较长，并且出现多次登录(例如，对于10K用户，12小时)。这些内存需求是在云连接器的正常RAM需求之外的。考虑增加RAM容量的总量。
CPU核心和插座配置注意事项
云连接器的CPU配置，特别是SQL Server Express LocalDB可用的核数，直接影响本地主机缓存的性能，甚至超过内存分配。这种CPU开销仅在数据库不可访问且本地主机缓存代理处于活动状态时观察到。
虽然SQL Server Express LocalDB可以使用多个内核(最多4个)，但它只能使用一个插槽。添加更多的套接字并不会提高性能(例如，拥有4个套接字，每个套接字有一个核心)。
储存注意事项
当用户在停机期间访问资源时，本地主机缓存数据库就会增长。例如，在以每秒10次登录运行的登录/注销测试期间，数据库每2到3分钟增长1 MB。当正常操作恢复时，当检测到配置更改时，将重新创建本地主机缓存数据库。本地主机缓存代理必须在安装本地主机缓存数据库的驱动器上有足够的空间，以允许数据库在停机期间增长。本地主机缓存在停机期间也会招致更多的I/O:大约每秒3 MB的写操作，以及几十万的读操作。