可扩展性注意事项
Session Recording 是一个高度可扩展的系统，可处理数千或数万个会话。安装和运行 Session Recording 除了运行 Citrix Virtual Apps and Desktops™ 或 Citrix DaaS（以前称为 Citrix Virtual Apps and Desktops 服务）所需的资源外，几乎不需要额外的资源。但是，如果您计划录制许多会话，或者您计划录制的会话可能导致大型会话文件（例如，图形密集型应用程序），我们仍然建议您考虑系统的性能。
本文介绍了 Session Recording 如何实现高可扩展性以及如何以最低成本充分利用您的录制系统。
会话录制为何能良好扩展
与竞品相比，Session Recording 良好扩展主要有两个原因：
-
文件大小小
使用 Session Recording 制作的录制会话文件高度紧凑。它比使用屏幕抓取解决方案制作的等效视频录制文件小几个数量级。传输/存储录制会话文件所需的网络带宽、磁盘空间和磁盘 IOPS 通常比等效视频文件至少小 10 倍。
录制会话文件的小尺寸意味着视频帧的渲染更快、更流畅。录制也是无损的，并且没有大多数紧凑视频格式中常见的像素化。录制中的文本在播放期间易于阅读，就像在原始会话中一样。为了保持较小的文件大小，Session Recording 不会在文件中记录关键帧。Session Recording 可以在录制正在运行视频的会话时丢弃 H.264 包，从而减小录制文件大小。要使用此功能，请在 Session Recording 代理上将
HKEY_LOCAL_MACHINE\SOFTWARE\Citrix\SmartAuditor\Agent\DropH264Enabled设置为1，并将 Use video codec for compression 的值设置为 For actively changing regions。
-
生成文件所需的处理量低
录制的会话文件包含会话的 ICA® 协议数据，这些数据几乎以其本机格式提取。该文件捕获用于与 Citrix Workspace™ 应用程序通信的 ICA 协议数据流。无需运行昂贵的转码或编码软件组件来实时更改数据格式。低处理量对于 VDA 可扩展性也很重要。它确保当从同一 VDA 录制许多会话时，最终用户体验得以保持。
此外，仅记录可回放的 ICA 虚拟通道，这会带来进一步的优化。例如，打印机和客户端驱动器映射通道不会录制。这些通道可以生成大量数据，但对视频播放没有任何好处。
估算数据输入和处理速率
Session Recording 服务器是录制会话文件的中央收集点。每台运行启用了 Session Recording 的多会话操作系统 VDA 的计算机都会将录制的会话数据发送到 Session Recording 服务器。Session Recording 可以处理大量数据，并且可以容忍突发和故障。但是，单个服务器可以处理的数据量存在物理限制。
考虑您发送到每个 Session Recording 服务器的数据量。估算服务器处理和存储数据的速度。您的系统存储传入数据的速率必须高于数据输入速率。
要估算您的数据输入速率，请执行以下计算：
- 将已录制会话的数量乘以平均会话大小。
- 将该总量除以您录制会话的持续时间。
例如，您可能在 8 小时工作日内录制 5,000 个 Microsoft Outlook 会话，每个会话 20 MB。在这种情况下，数据输入速率约为 28 Mbps（5,000 个会话乘以 20 MB，除以 8 小时，再除以每小时 3,600 秒，然后乘以 8 转换为 Mbps）。连接到 100 Mbps LAN 并具有足够磁盘空间来存储录制数据的典型会话录制服务器可以以大约 5.0 Mbps 的速率处理数据。此速率是基于磁盘和网络 IOPS 施加的物理限制的处理速率。在此示例中，处理速率（5.0 Mbps）低于输入速率（28 Mbps），因此无法录制 5,000 个 Outlook 会话。
每个会话的数据量因录制内容的不同而差异很大。屏幕分辨率、颜色深度和图形模式等其他因素也会产生影响。运行 CAD 的会话可能比用户在 Outlook 中发送和接收电子邮件的会话生成更大的录制文件。因此，录制相同数量的 CAD 会话可能会产生高输入速率，并需要使用更多的会话录制服务器。
突发和故障
前面的示例假设数据吞吐量简单且均匀，但没有解释系统如何处理短时间内的更高活动（称为突发）。突发可能发生在所有用户在早上同时登录时，这被称为“9 点高峰”。当他们同时在 Outlook 收件箱中收到相同的电子邮件时，也可能发生突发。会话录制服务器 5.0 Mbps 的处理速率在处理这种突发需求时是远远不够的。
在每个 VDA 上运行的会话录制代理使用 Microsoft 消息队列 (MSMQ) 将录制数据发送到在中央会话录制服务器上运行的存储管理器。数据以存储转发方式发送，类似于电子邮件在发件人、邮件服务器和收件人之间传递的方式。如果会话录制服务器或网络无法在突发情况下处理高速率数据，则录制数据会暂时存储。如果网络拥塞，数据消息可能会暂时存储在 VDA 上的传出队列中。另一种情况是数据已通过网络，但存储管理器正忙于处理其他消息。在这种情况下，数据消息存储在会话录制服务器的接收队列中。
MSMQ 还可用作容错机制。如果会话录制服务器发生故障或链接中断，录制数据将保留在每个 VDA 上的传出队列中。故障排除后，所有排队数据将一起发送。MSMQ 还允许您在不中断会话录制和不丢失数据的情况下，将服务器脱机进行升级或维护。
MSMQ 的主要限制是用于临时存储数据消息的磁盘空间是有限的。此限制限制了突发、故障或维护事件在数据最终丢失之前可以持续多长时间。系统在数据丢失后仍可继续运行，但在这种情况下，单个录制文件会缺少部分数据。缺少数据的文件仍然可以播放，但只能播放到数据首次丢失的点。请注意以下事项：
-
为每台服务器（尤其是会话录制服务器）增加更多磁盘空间，并使其可用于 MSMQ，可以提高对突发和故障的容忍度。
-
务必为每个会话录制代理将“消息生存期”设置配置为适当的级别（在会话录制代理属性的“连接”选项卡上）。默认值为 7,200 秒（两小时）。这意味着每个录制的数据消息有两小时的时间到达存储管理器，否则存储管理器会将其丢弃并损坏录制文件。如果可用磁盘空间更大（或要录制的会话更少），您可以选择增加此值。最大值为 365 天。
MSMQ 的另一个限制是，当数据积压时，队列中会产生额外的磁盘 IOPS 来读取和写入数据消息。通常，存储管理器直接从网络接收和处理数据，而数据消息从未写入磁盘。存储数据涉及对磁盘进行一次写入操作，该操作将追加录制的会话文件。当数据积压时，磁盘 IOPS 会增加三倍：每个消息都必须写入磁盘、从磁盘读取并写入文件。由于存储管理器严重受 IOPS 限制，会话录制服务器的处理速率会下降，直到消息积压被清除。为了减轻这种额外 IOPS 的影响，请采纳以下建议：
-
确保 MSMQ 存储消息的磁盘与录制文件存储文件夹不同。即使 IOPS 总线流量增加三倍，实际处理速率的下降也绝不会那么严重。
-
仅在非高峰时段计划中断。根据预算限制，遵循公认的方法来构建高可用性服务器。这些方法包括使用不间断电源 (UPS)、双网卡、冗余交换机以及热插拔内存和磁盘。
设计时预留备用容量
录制会话数据的数据速率不太可能均匀，可能会出现突发和故障，并且清除消息积压在 IOPS 方面开销很大。因此，请为每个会话录制服务器设计充足的备用容量。如后续章节所述，添加更多服务器或改进现有服务器的规格始终能为您带来额外的容量。一般经验法则是让每个会话录制服务器以其总容量的最多 50% 运行。在前面的示例中，如果服务器可以处理 5.0 Mbps，则目标是让系统仅以 2.5 Mbps 运行。
积压和实时播放
实时播放是指审阅者在会话仍处于活动状态时打开会话录制进行播放。在实时播放期间，负责的会话录制代理会切换到该会话的流模式。录制数据会立即发送到存储管理器，无需内部缓冲。由于录制文件不断更新，播放器可以继续获取来自实时会话的最新数据。但是，从代理发送到存储管理器的数据通过 MSMQ，因此前面描述的排队规则适用。在这种情况下可能会出现问题。当 MSMQ 出现积压时，可用于实时播放的新录制数据会像所有其他数据消息一样排队。审阅者仍然可以播放文件，但查看最新的实时录制数据会延迟。如果实时播放对审阅者来说是重要功能，请确保积压的可能性较低。您可以在部署中设计备用容量和容错能力。
系统可伸缩性
会话录制从不降低会话性能，也从不因录制数据积压而停止会话。维护最终用户体验和单服务器可伸缩性在会话录制系统的设计中至关重要。如果录制系统不可逆转地过载，录制会话数据将被丢弃。录制 ICA 会话对 VDA 的性能和可伸缩性影响很小。影响大小取决于平台、可用内存以及正在录制会话的图形特性。通过以下配置，您可以预期单服务器可伸缩性影响在 1% 到 5% 之间。换句话说，如果一台服务器在未安装会话录制的情况下可以托管 100 个用户，那么安装后可以托管 95–99 个用户：
- 运行多会话操作系统 VDA 的 64 位服务器，配备 8 GB 内存
- 所有会话均运行 Office 生产力应用程序，例如 Outlook 和 Excel
- 应用程序的使用是活跃且持续的
- 所有会话均根据会话录制策略的配置进行录制
如果录制会话较少，或者会话活动持续性较差且更零星，则影响较小。通常情况下，可伸缩性影响可以忽略不计，并且每服务器用户密度保持不变。如前所述，影响较小是由于每个 VDA 上的会话录制组件的处理要求简单。录制数据从 ICA 会话堆栈中提取，并通过 MSMQ 原样发送到会话录制服务器。没有昂贵的数据编码。
即使没有录制任何会话，使用会话录制也会产生轻微开销。如果您不打算从特定服务器录制任何会话，则可以在该服务器上禁用录制。删除会话录制是一种方法。侵入性较小的方法是清除“会话录制代理属性”中“会话录制”选项卡上的“为此 VDA 计算机启用会话录制”复选框。如果将来需要会话录制，请重新选择此复选框。
测量吞吐量
您可以测量从发送 VDA 到接收会话录制服务器的录制会话数据的吞吐量。一种简单有效的方法是观察录制文件的大小以及会话录制服务器上磁盘空间的消耗速度。写入磁盘的数据量密切反映了生成的网络流量。Windows 性能监视器工具 (perfmon.exe) 具有标准系统计数器，您可以观察这些计数器以及会话录制提供的一些计数器。计数器可用于测量吞吐量，并识别瓶颈和系统问题。下表概述了一些最有用的性能计数器。
| 性能对象 | 计数器名称 | 描述 |
|---|---|---|
| Citrix Session Recording Agent | Active Recording Count |
在特定 VDA 上当前正在录制的会话数。 |
| Citrix Session Recording Agent | Bytes read from the Session Recording Driver |
从负责获取会话数据的内核组件读取的字节数。可用于确定单个 VDA 为该服务器上录制的所有会话生成了多少数据。 |
| Citrix Session Recording Storage Manager | Active Recording Count |
与 Citrix 会话录制代理计数器类似，但适用于会话录制服务器。指示所有服务器当前正在录制的会话总数。 |
| Citrix Session Recording Storage Manager | Message bytes/sec |
所有录制会话的吞吐量。可用于确定存储管理器处理数据的速率。如果 MSMQ 消息积压，存储管理器将全速运行。此值可用于指示存储管理器的最大处理速率。 |
| LogicalDisk | Disk Write Bytes/sec |
可用于测量磁盘直写性能，这对于实现会话录制服务器的高可伸缩性非常重要。还可以观察单个驱动器的性能。 |
| MSMQ Queue | Bytes in Queue |
可用于确定 CitrixSmAudData 消息队列中积压的数据量。如果此值随时间增加，则从网络接收的录制数据速率大于存储管理器处理数据的速率。此计数器可用于观察数据突发和故障的影响。 |
| MSMQ Queue | Message in Queue |
与“队列中的字节数”计数器类似，但测量的是消息数。 |
| Network Interface | Bytes Total/sec |
可用于测量链接的两端，以观察录制会话时生成了多少数据。在会话录制服务器上测量时，此计数器指示接收传入数据的速率。与测量数据处理速率的 Citrix 会话录制存储管理器 Message bytes/sec 计数器形成对比。如果网络速率大于此值，则消息会在消息队列中累积。 |
| Processor | % Processor Time |
值得监控，尽管 CPU 不太可能成为瓶颈。 |
会话录制服务器硬件
通过仔细选择 Session Recording 服务器硬件，可以提高部署容量。您有两种选择：纵向扩展（通过增加每台服务器的容量）或横向扩展（通过添加更多服务器）。无论选择哪种方式，您的目标都是以最低成本提高可扩展性。
纵向扩展
在检查单个 Session Recording 服务器时，请考虑以下最佳实践，以确保在可用预算内实现最佳性能。系统依赖于 IOPS，以确保将记录的数据从网络高吞吐量地写入磁盘。因此，投资适当的网络和磁盘硬件非常重要。对于高性能 Session Recording 服务器，建议使用双 CPU 或双核 CPU，但更高规格的配置收益甚微。建议使用 64 位处理器架构，但 x86 处理器类型也适用。建议使用 4 GB RAM，但增加更多 RAM 的收益同样甚微。
横向扩展
即使采用最佳的纵向扩展实践，单个 Session Recording 服务器在录制大量会话时，其性能和可扩展性也存在局限性。可能需要添加额外的服务器来满足负载。您可以在不同的计算机上安装更多 Session Recording 服务器，使这些服务器作为负载平衡池工作。在此类部署中，Session Recording 服务器共享存储和数据库。要分发负载，请将 Session Recording 代理指向负责工作负载分发的负载平衡器。
网络容量
100 Mbps 网络链路适用于连接 Session Recording 服务器。千兆以太网连接可能会提高性能，但其性能不会比 100 Mbps 链路高出 10 倍。实际上，吞吐量的增益会更小。
确保 Session Recording 使用的网络交换机不与可能争用可用网络带宽的第三方应用程序共享。理想情况下，网络交换机应专用于 Session Recording 服务器。如果网络拥塞被证明是瓶颈，则网络升级是提高系统可扩展性的一种相对经济的方式。
存储
对磁盘和存储硬件的投资是服务器可扩展性中最重要的单一因素。数据写入磁盘的速度越快，整个系统的性能就越高。在选择存储解决方案时，请更多地关注写入性能而非读取性能。
将数据存储在 RAID 或 SAN 上。
注意：
将数据存储在基于文件协议（例如 SMB 和 NFS）的 NAS 上，可能会带来性能和安全隐患。请使用最新版本的协议以避免安全隐患，并执行规模测试以确保适当的性能。
对于本地驱动器设置，请选择带有内置缓存内存的磁盘控制器。缓存允许控制器在回写期间使用电梯排序。它最大限度地减少了磁盘磁头移动，并确保写入操作在不等待物理磁盘操作完成的情况下完成。它可以在最小的额外成本下显著提高写入性能。然而，缓存确实会带来断电后数据丢失的问题。为确保数据和文件系统的完整性，请考虑为缓存磁盘控制器配备电池备份设施。
考虑使用合适的 RAID 存储解决方案。根据性能和冗余要求，有多种 RAID 级别可用。下表详细说明了每种 RAID 级别以及每种标准对会话录制 (Session Recording) 的适用性。
| RAID 级别 | 类型 | 最少磁盘数 | 说明 |
|---|---|---|---|
| RAID 0 | 无奇偶校验的带区集 | 2 | 提供高性能但无冗余。任何磁盘的丢失都会破坏阵列。RAID 0 是一种低成本解决方案，适用于存储数据丢失影响较小的录制会话文件。通过添加更多磁盘可轻松扩展性能。 |
| RAID 1 | 无奇偶校验的镜像集 | 2 | 与单个磁盘相比没有性能提升，使其成为相对昂贵的解决方案。仅当需要高冗余级别时才使用此解决方案。 |
| RAID 3 | 带有专用奇偶校验的带区集 | 3 | 提供高写入性能，其冗余特性类似于 RAID 5。RAID 3 推荐用于视频制作和直播应用程序。由于会话录制 (Session Recording) 属于此类应用程序，因此强烈推荐 RAID 3，但它并不常见。 |
| RAID 5 | 带有分布式奇偶校验的带区集 | 3 | 提供高读取性能和冗余，但代价是写入性能较慢。RAID 5 是通用用途最常见的。但由于写入性能较慢，不建议将 RAID 5 用于会话录制 (Session Recording)。RAID 3 可以以相似的成本部署，但具有更好的写入性能。 |
| RAID 10 | 镜像集和带区集 | 4 | 提供 RAID 0 的性能特性和 RAID 1 的冗余优势。一种昂贵的解决方案，不建议用于会话录制 (Session Recording)。 |
RAID 0 和 RAID 3 是最推荐的 RAID 级别。RAID 1 和 RAID 5 是流行的标准，但不建议用于会话录制 (Session Recording)。RAID 10 确实提供了一些性能优势，但对于额外的增益来说过于昂贵。
确定磁盘驱动器的类型和规格。IDE/ATA 驱动器以及外部 USB 或 Firewire 驱动器不适合在会话录制 (Session Recording) 中使用。主要选择是 SATA 和 SCSI。与 SCSI 驱动器相比，SATA 驱动器以更低的每 MB 成本提供相当高的传输速率。然而，SCSI 驱动器提供更好的性能，并且在服务器部署中更常见。服务器 RAID 解决方案大多支持 SCSI 驱动器，但现在也有一些 SATA RAID 产品可用。在评估磁盘驱动器产品的规格时，请考虑磁盘的转速和其他性能特征。
由于每天录制数千个会话会消耗大量磁盘空间，因此您必须在总体容量和性能之间做出选择。根据前面的示例，在 8 小时工作日内录制 5,000 个 Outlook 会话会消耗大约 100 GB 的存储空间。要存储 10 天的录制内容（即 50,000 个录制会话文件），您需要 1,000 GB (1 TB)。通过缩短存档或删除旧录制内容之前的保留期，可以缓解磁盘空间压力。如果可用 1 TB 磁盘空间，七天的保留期是合理的，可确保磁盘空间使用量保持在 700 GB 左右，并保留 300 GB 作为繁忙日期的缓冲区。在会话录制 (Session Recording) 中，ICLDB 实用程序支持文件的存档和删除。它具有最短两天的保留期。您可以安排一个后台任务在非高峰时段每天运行一次。有关 ICLDB 命令和存档的更多信息，请参阅 管理数据库记录。
使用本地驱动器和控制器的替代方案是使用基于块级磁盘访问的 SAN 存储解决方案。对于会话录制 (Session Recording) 服务器，磁盘阵列显示为本地驱动器。SAN 的设置成本更高，但由于磁盘阵列是共享的，SAN 确实具有简化和集中管理的优势。SAN 主要有两种类型：光纤通道 (Fibre Channel) 和 iSCSI。iSCSI 本质上是基于 TCP/IP 的 SCSI，自千兆以太网 (Gb Ethernet) 推出以来，其受欢迎程度已超过光纤通道。
数据库可伸缩性
发送到会话录制 (Session Recording) 数据库的数据量很小，因为数据库仅存储有关录制会话的元数据。录制会话文件本身写入单独的磁盘。通常，每个录制会话在数据库中仅需要大约 1 KB 的空间，除非使用会话录制事件 API (Session Recording Event API) 将可搜索事件插入到会话中。
Microsoft SQL Server 2019、2017、2016、2014、2012 和 2008 R2 的 Express 版本对数据库大小施加了 10 GB 的限制。以每个录制会话 1 KB 计算，数据库可以编目大约 4,000,000 个会话。其他版本的 Microsoft SQL Server 没有数据库大小限制，并且仅受可用磁盘空间的限制。随着数据库中会话数量的增加，数据库性能和搜索速度的下降可以忽略不计。
如果您不通过 会话录制事件 API (Session Recording Event API) 进行自定义，则每个录制会话会生成四笔数据库事务：录制开始时两笔，用户登录到正在录制的会话时一笔，以及录制结束时一笔。如果您使用会话录制事件 API (Session Recording Event API) 自定义会话，则每个录制的可搜索事件会生成一笔事务。由于即使最基本的数据库部署也能处理每秒数百笔事务，因此数据库的处理负载不太可能承受压力。其影响足够轻微，以至于会话录制 (Session Recording) 数据库可以与包括 Citrix Virtual Apps and Desktops 数据存储数据库在内的其他数据库在同一 SQL Server 上运行。
如果您的会话录制 (Session Recording) 部署需要在数据库中编目数百万个录制会话，请遵循 Microsoft 关于 SQL Server 可伸缩性的指导原则。