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