可伸缩性注意事项
Session Recording 是一个高度可伸缩的系统，可处理数千或数万个会话。安装和运行 Session Recording 除了运行 Citrix Virtual Apps and Desktops™ 或 Citrix DaaS（以前称为 Citrix Virtual Apps and Desktops service）所需的资源外，几乎不需要额外的资源。但是，如果您计划录制大量会话，或者您计划录制的会话可能导致大型会话文件（例如，图形密集型应用程序），我们仍然建议您考虑系统的性能。
本文介绍了 Session Recording 如何实现高可伸缩性以及如何以最低成本充分利用您的录制系统。
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™ app 通信的 ICA 协议数据流。无需运行昂贵的转码或编码软件组件来实时更改数据格式。低处理量对于 VDA 可伸缩性也很重要。它确保当从同一 VDA 录制许多会话时，最终用户体验得以保持。
此外，仅录制那些可以回放的 ICA 虚拟通道，这会带来进一步的优化。例如，不录制打印机和客户端驱动器映射通道。这些通道可以生成大量数据，但对视频播放没有任何益处。
估算数据输入和处理速率
Session Recording 服务器是录制会话文件的中央收集点。每台运行启用了 Session Recording 的多会话 OS 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 并具有足够磁盘空间来存储录制数据的典型 Session Recording 服务器可以以大约 5.0 Mbps 的速率处理数据。此速率是基于磁盘和网络 IOPS 施加的物理限制的处理速率。在此示例中，处理速率 (5.0 Mbps) 低于输入速率 (28 Mbps)，因此无法录制 5,000 个 Outlook 会话。
每个会话的数据量因录制内容的不同而差异很大。其他因素，例如屏幕分辨率、颜色深度和图形模式，也会产生影响。运行 CAD 的会话可能比用户在 Outlook 中发送和接收电子邮件的会话生成更大的录制文件。因此，录制相同数量的 CAD 会话可能会产生高输入速率，并需要使用更多的 Session Recording 服务器。
突发和故障
上面的示例假设数据吞吐量简单且均匀，但没有解释系统如何处理短时间的高活动（称为突发）。当所有用户在早上同时登录时（称为“9 点高峰”），可能会发生突发。当他们同时在 Outlook 收件箱中收到相同的电子邮件时，也可能发生突发。Session Recording 服务器 5.0 Mbps 的处理速率在处理这种突发需求时是远远不够的。
在每个 VDA 上运行的 Session Recording 代理使用 Microsoft Message Queuing (MSMQ) 将录制数据发送到在中央 Session Recording 服务器上运行的 Storage Manager。数据以存储转发的方式发送，类似于电子邮件在发件人、邮件服务器和收件人之间传递的方式。如果 Session Recording 服务器或网络无法处理突发的高数据速率，则录制数据会暂时存储。如果网络拥堵，数据消息可能会暂时存储在 VDA 上的传出队列中。另一种情况是数据已通过网络，但 Storage Manager 正在忙于处理其他消息。在这种情况下，数据消息存储在 Session Recording 服务器的接收队列中。
MSMQ 还充当容错机制。如果 Session Recording 服务器出现故障或链接中断，录制数据会保留在每个 VDA 上的传出队列中。故障排除后，所有排队的数据将一起发送。MSMQ 还允许您在不中断会话录制和丢失数据的情况下，将服务器脱机进行升级或维护。
MSMQ 的主要限制是用于临时存储数据消息的磁盘空间是有限的。此限制决定了突发、故障或维护事件在数据最终丢失之前可以持续多长时间。即使数据丢失，整个系统也可以继续运行，但在这种情况下，单个录制文件会缺少数据块。缺少数据的文件仍然可以播放，但只能播放到数据首次丢失之前的点。请注意以下事项：
-
为每台服务器（尤其是 Session Recording 服务器）添加更多磁盘空间，并将其提供给 MSMQ，可以提高对突发和故障的容忍度。
-
务必为每个 Session Recording 代理将“消息生存期”设置配置到适当的级别（在 Session Recording 代理属性的“连接”选项卡上）。默认值为 7,200 秒（两小时）。这意味着每个录制的数据消息有两小时的时间到达 Storage Manager，否则 Storage Manager 将丢弃它并损坏录制文件。如果有更多可用磁盘空间（或要录制的会话更少），您可以选择增加此值。最大值为 365 天。
MSMQ 的另一个限制是，当数据积压时，队列中会产生额外的磁盘 IOPS 来读取和写入数据消息。通常，Storage Manager 直接从网络接收和处理数据，而数据消息从未写入磁盘。存储数据涉及对磁盘进行一次写入操作，该操作会将数据追加到录制会话文件。当数据积压时，磁盘 IOPS 会增加三倍：每条消息都必须写入磁盘、从磁盘读取并写入文件。由于 Storage Manager 严重受 IOPS 限制，Session Recording 服务器的处理速率会下降，直到消息积压被清除。为减轻此额外 IOPS 的影响，请采纳以下建议：
-
确保 MSMQ 存储消息的磁盘与录制文件存储文件夹不同。即使 IOPS 总线流量增加三倍，实际处理速率的下降也绝不会那么严重。
-
仅在非高峰时段计划中断。根据预算限制，遵循公认的方法来构建高可用性服务器。这些方法包括使用不间断电源 (UPS)、双网卡、冗余交换机以及热插拔内存和磁盘。
为备用容量而设计
录制会话数据的数据速率不太可能均匀，可能会出现突发和故障，并且清除消息积压在 IOPS 方面成本很高。因此，请为每个 Session Recording 服务器设计充足的备用容量。如后续章节所述，添加更多服务器或改进现有服务器的规格，总能为您带来额外的容量。一般经验法则是，每个 Session Recording 服务器的最大运行容量为其总容量的 50%。在前面的示例中，如果服务器可以处理 5.0 Mbps，则目标是让系统仅以 2.5 Mbps 运行。
积压和实时播放
实时播放是指审阅者在会话仍处于活动状态时打开会话录制进行播放。在实时播放期间，负责的 Session Recording 代理会切换到该会话的流模式。录制数据会立即发送到 Storage Manager，无需内部缓冲。由于录制文件不断更新，播放器可以继续获取来自实时会话的最新数据。但是，从代理发送到 Storage Manager 的数据是通过 MSMQ 进行的，因此前面描述的排队规则适用。在这种情况下可能会出现问题。当 MSMQ 积压时，可用于实时播放的新录制数据会像所有其他数据消息一样排队。审阅者仍然可以播放文件，但查看最新的实时录制数据会延迟。如果实时播放对审阅者来说是一项重要功能，请确保积压的可能性较低。您可以在部署中设计备用容量和容错功能。
系统可扩展性
Session Recording 绝不会降低会话性能，也绝不会因录制数据积压而停止会话。在 Session Recording 系统的设计中，保持最终用户体验和单服务器可扩展性至关重要。如果录制系统发生不可逆转的过载，则会丢弃录制的会话数据。录制 ICA 会话对 VDA 的性能和可扩展性影响很小。影响的大小取决于平台、可用内存以及所录制会话的图形特性。使用以下配置，您可以预期单服务器可扩展性影响在 1% 到 5% 之间。换句话说，如果一台服务器在未安装 Session Recording 的情况下可以托管 100 个用户，那么安装后它可以托管 95-99 个用户：
- 运行多会话操作系统 VDA 的 64 位服务器，配备 8 GB RAM
- 所有会话都运行 Office 生产力应用程序，例如 Outlook 和 Excel
- 应用程序的使用是活跃且持续的
- 所有会话均按照 Session Recording 策略的配置进行录制
如果录制的会话较少，或者会话活动持续时间较短且更零星，则影响会更小。通常，可扩展性影响可以忽略不计，并且每个服务器的用户密度保持不变。如前所述，影响较小是由于每个 VDA 上的 Session Recording 组件的处理要求简单。录制的数据从 ICA 会话堆栈中提取，并通过 MSMQ 原样发送到 Session Recording 服务器。数据没有昂贵的编码。
即使没有录制任何会话，使用 Session Recording 也会产生少量开销。如果您不打算从特定服务器录制任何会话，则可以在该服务器上禁用录制。删除 Session Recording 是一种方法。一种侵入性较小的方法是，在Session Recording Agent Properties（Session Recording 代理属性）的Session Recording（Session Recording）选项卡中，清除Enable session recording for this VDA machine（为此 VDA 计算机启用会话录制）复选框。如果将来需要会话录制，请重新选中此复选框。
测量吞吐量
您可以测量从发送 VDA 到接收 Session Recording 服务器的录制会话数据的吞吐量。一种简单有效的方法是观察录制文件的大小以及 Session Recording 服务器上磁盘空间消耗的速度。写入磁盘的数据量密切反映了生成的网络流量。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 代理计数器类似，但适用于 Session Recording 服务器。指示所有服务器当前正在录制的会话总数。 |
| Citrix Session Recording Storage Manager | Message bytes/sec |
所有录制会话的吞吐量。可用于确定 Storage Manager 处理数据的速率。如果 MSMQ 消息积压，Storage Manager 将全速运行。此值可用于指示 Storage Manager 的最大处理速率。 |
| LogicalDisk | Disk Write Bytes/sec |
可用于测量磁盘直写性能，这对于实现 Session Recording 服务器的高可扩展性非常重要。还可以观察单个驱动器的性能。 |
| MSMQ Queue | Bytes in Queue |
可用于确定 CitrixSmAudData 消息队列中积压的数据量。如果此值随时间增加，则从网络接收的录制数据速率大于 Storage Manager 处理数据的速率。此计数器可用于观察数据突发和故障的影响。 |
| MSMQ Queue | Message in Queue |
与“队列中的字节数”计数器类似，但测量的是消息数。 |
| Network Interface | Bytes Total/sec |
可用于测量链接的两端，以观察录制会话时生成了多少数据。在 Session Recording 服务器上测量时，此计数器指示接收传入数据的速率。与测量数据处理速率的 Citrix Session Recording Storage Manager 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 服务器共享存储和数据库。为了分配负载，请将 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 是流行的标准，但不建议用于会话录制。RAID 10 确实提供了一些性能优势，但对于额外的收益来说过于昂贵。
确定磁盘驱动器的类型和规格。IDE/ATA 驱动器以及外部 USB 或 Firewire 驱动器不适合用于会话录制。主要选择是 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 作为繁忙日期的缓冲区。在会话录制中，ICLDB 实用程序支持文件的存档和删除。它的最短保留期为两天。您可以安排一个后台任务，在非高峰时段每天运行一次。有关 ICLDB 命令和存档的更多信息，请参阅 管理数据库记录。
使用本地驱动器和控制器的一种替代方案是使用基于块级磁盘访问的 SAN 存储解决方案。对于 Session Recording 服务器，磁盘阵列显示为本地驱动器。SAN 的设置成本更高，但由于磁盘阵列是共享的，SAN 确实具有简化和集中管理的优势。SAN 主要有两种类型：Fibre Channel 和 iSCSI。iSCSI 本质上是基于 TCP/IP 的 SCSI，自千兆以太网引入以来，其受欢迎程度已超过 Fibre Channel。
数据库可伸缩性
发送到会话录制数据库的数据量很小，因为数据库仅存储有关录制会话的元数据。录制会话文件本身写入单独的磁盘。通常，每个录制会话在数据库中仅需要大约 1 KB 的空间，除非使用会话录制事件 API 将可搜索事件插入到会话中。
Microsoft SQL Server 2019、2017、2016、2014、2012 和 2008 R2 的 Express 版本对数据库大小施加了 10 GB 的限制。以每个录制会话 1 KB 计算，数据库可以编目大约 4,000,000 个会话。其他版本的 Microsoft SQL Server 没有数据库大小限制，仅受可用磁盘空间的限制。随着数据库中会话数量的增加，数据库性能和搜索速度的下降可以忽略不计。
如果您不通过 会话录制事件 API 进行自定义，每个录制会话会生成四次数据库事务：两次在录制开始时，一次在用户登录到正在录制的会话时，一次在录制结束时。如果您使用会话录制事件 API 自定义会话，则每个记录的可搜索事件都会生成一个事务。由于即使是最基本的数据库部署也能每秒处理数百个事务，因此数据库上的处理负载不太可能承受压力。影响足够小，以至于会话录制数据库可以与包括 Citrix Virtual Apps and Desktops 数据存储数据库在内的其他数据库在同一 SQL Server 上运行。
如果您的 Session Recording 部署需要在数据库中编目数百万个录制会话，请遵循 Microsoft 关于 SQL Server 可伸缩性的准则。