可伸缩性注意事项

会话录制是一个高度可伸缩的系统，可处理数千或数万个会话。安装和运行会话录制所需的额外资源很少，仅略高于运行 Citrix Virtual Apps and Desktops 所需的资源。但是，如果您计划使用会话录制来录制大量会话，或者您计划录制的会话可能导致大型会话文件（例如，图形密集型应用程序），请在规划会话录制部署时考虑系统的性能。

本文介绍了会话录制如何实现高可伸缩性，以及如何以最低的成本最大限度地利用您的录制系统。

会话录制为何具有良好的可伸缩性

与竞争产品相比，会话录制具有良好可伸缩性的主要原因有两个：

• 文件大小小

  使用会话录制制作的录制会话文件高度紧凑。它比使用屏幕抓取解决方案制作的等效视频录制小了几个数量级。传输和存储每个会话录制文件所需的网络带宽、磁盘空间和磁盘 IOPS 通常至少比等效视频文件少 10 倍。

  录制会话文件的小尺寸意味着视频帧的渲染更快、更流畅。录制也是无损的，并且没有大多数紧凑型视频格式中常见的像素化。录制中的文本在播放期间易于阅读，就像在原始会话中一样。为了保持较小的文件大小，会话录制不会在文件中录制关键帧。会话录制可以在录制正在运行视频的会话时丢弃 H.264 包，从而减小录制文件的大小。要使用此功能，请将会话录制代理上的 HKEY_LOCAL_MACHINE\SOFTWARE\Citrix\SmartAuditor\Agent\DropH264Enabled 设置为 1，并将使用视频编解码器进行压缩的值设置为对于活动更改区域。

  

• 生成文件所需的处理量低

  录制会话文件包含会话的 ICA® 协议数据，这些数据几乎以其本机格式提取。该文件捕获用于与 Citrix Workspace™ app 通信的 ICA 协议数据流。无需运行昂贵的转码或编码软件组件来实时更改数据格式。低处理量对于 VDA 可伸缩性也很重要，并确保在从同一 VDA 录制许多会话时保持最终用户体验。

  此外，仅录制可以回放的 ICA 虚拟通道，这会带来进一步的优化。例如，不录制打印机和客户端驱动器映射通道，因为它们会生成大量数据，但在视频播放中没有任何好处。

估算数据输入和处理速率

会话录制服务器是录制会话文件的中央收集点。每台运行启用会话录制的多会话操作系统 VDA 的计算机都会将会话录制数据发送到会话录制服务器。会话录制可以处理大量数据，并能容忍突发和故障，但单个服务器可以处理的数据量存在物理限制。

请考虑您向每个会话录制服务器发送多少数据，以及服务器处理和存储这些数据的速度有多快。您的系统存储传入数据的速率必须高于数据输入速率。

要估算数据输入速率，请将录制的会话数乘以每个录制会话的平均大小，然后除以录制会话的时间。例如，您可能在 8 小时工作日内录制 5,000 个 Microsoft Outlook 会话，每个会话 20 MB。在这种情况下，数据输入速率约为 3.5 Mbps。（5,000 个会话乘以 20 MB 除以 8 小时，再除以每小时 3,600 秒。）连接到 100 Mbps LAN 并具有足够磁盘空间来存储录制数据的典型会话录制服务器，可以根据磁盘和网络 IOPS 施加的物理限制，以大约 5.0 Mbps 的速度处理数据。此速率是处理速率。在此示例中，处理速率 (5.0 Mbps) 高于输入速率 (3.5 Mbps)，因此录制 5,000 个 Outlook 会话是可行的。

每个会话的数据量因录制内容的不同而差异很大，而屏幕分辨率、颜色深度和图形模式等其他因素也会产生影响。运行 CAD 软件包且图形活动持续较高的会话，其生成的录制文件可能比最终用户在 Microsoft 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 运行。不要在一个会话录制服务器上录制产生 3.5 Mbps 的 5,000 个 Outlook 会话，而是减少到只产生约 2.5 Mbps 的 3,500 个会话。

积压和实时播放

实时回放是指审阅者在会话仍处于活动状态时打开会话录制进行回放。在实时回放期间，负责该会话的会话录制代理会切换到该会话的流模式，录制数据会立即发送到存储管理器，而无需内部缓冲。由于录制文件不断更新，播放器可以持续获取实时会话的最新数据。但是，从代理发送到存储管理器的数据是通过 MSMQ 进行的，因此前面描述的排队规则适用。在这种情况下可能会出现问题。当 MSMQ 积压时，可用于实时回放的新录制数据会像所有其他数据消息一样排队。审阅者仍然可以播放文件，但查看最新的实时录制数据会延迟。如果实时回放对审阅者来说是一项重要功能，请通过在部署中设计备用容量和容错能力来确保低积压概率。

Citrix 虚拟应用™ 和 桌面 可扩展性

会话录制绝不会降低会话性能，也绝不会因录制数据积压而停止会话。在会话录制系统的设计中，保持最终用户体验和单服务器可扩展性至关重要。如果录制系统出现不可逆转的过载，则会丢弃录制的会话数据。Citrix 进行的广泛可扩展性测试表明，录制 ICA 会话对 Citrix Virtual Apps 和 Desktops 服务器的性能和可扩展性的影响很小。影响的大小取决于平台、可用内存以及正在录制的会话的图形性质。在以下配置下，您可以预期单服务器可扩展性影响在 1% 到 5% 之间。换句话说，如果一台服务器在未安装会话录制的情况下可以托管 100 个用户，那么安装后它可以托管 95-99 个用户：

• 运行多会话操作系统 VDA 的 64 位服务器，配备 8 GB RAM
• 所有会话都运行 Office 生产力应用程序，例如 Outlook 和 Excel
• 应用程序的使用是活跃且持续的
• 所有会话都按照会话录制策略的配置进行录制

如果录制的会话较少，或者会话活动不那么持续且更零星，则影响会更小。在许多情况下，可扩展性影响可以忽略不计，并且每个服务器的用户密度保持不变。如前所述，影响较小是由于安装在每个 VDA 上的会话录制组件的处理要求简单。录制的数据从 ICA 会话堆栈中提取，并通过 MSMQ 原样发送到会话录制服务器。没有昂贵的数据编码。

即使没有录制会话，使用会话录制也会产生少量开销。尽管影响很小，但如果您确定没有从特定服务器录制会话，则可以在该服务器上禁用录制。移除会话录制是一种方法。一种侵入性较小的方法是，在会话录制代理属性的“会话录制”选项卡上清除“为此 VDA 计算机启用会话录制”复选框。如果将来需要会话录制，请重新选择此复选框。

测量吞吐量

有多种方法可以测量从发送 VDA 到接收会话录制服务器的录制会话数据的吞吐量。最简单有效的方法之一是观察录制文件的大小以及会话录制服务器上磁盘空间消耗的速度。写入磁盘的数据量密切反映了生成的网络流量。Windows 性能监视器工具 (perfmon.exe) 具有一系列标准系统计数器，除了会话录制提供的一些计数器外，还可以观察这些计数器。计数器可用于测量吞吐量，并识别瓶颈和系统问题。下表概述了一些最有用的性能计数器。

会话录制服务器硬件

您可以通过仔细选择用于会话录制服务器的硬件来增加部署的容量。您有两种选择：纵向扩展（通过增加每台服务器的容量）或横向扩展（通过添加更多服务器）。在做出任何一种选择时，您的目标都是以最低成本提高可扩展性。

纵向扩展

在检查单个会话录制服务器时，请考虑以下最佳实践，以确保在可用预算内实现最佳性能。系统依赖于 IOPS。这可确保录制数据从网络到磁盘的高吞吐量。因此，投资适当的网络和磁盘硬件非常重要。对于高性能会话录制服务器，建议使用双 CPU 或双核 CPU，但更高的规格几乎没有额外收益。建议使用 64 位处理器架构，但 x86 处理器类型也适用。建议使用 4 GB RAM，但同样，增加更多 RAM 几乎没有额外收益。

横向扩展

即使采用最佳的纵向扩展实践，单个会话录制服务器在录制大量会话时，其性能和可伸缩性也可能达到极限。此时可能需要添加额外的服务器来满足负载。您可以在不同的计算机上安装更多会话录制服务器，使这些会话录制服务器作为一个负载均衡池工作。在此类部署中，会话录制服务器共享存储和数据库。要分配负载，请将会话录制代理指向负责工作负载分配的负载均衡器。

网络容量

100 Mbps 网络链接适用于连接会话录制服务器。千兆以太网连接可能会提高性能，但性能不会比 100 Mbps 链接高出 10 倍。实际上，吞吐量的增益要小得多。

确保会话录制使用的网络交换机不与可能争夺可用网络带宽的第三方应用程序共享。理想情况下，网络交换机应专用于会话录制服务器。如果网络拥堵被证明是瓶颈，那么网络升级是提高系统可伸缩性的一种相对经济的方式。

存储

对磁盘和存储硬件的投资是服务器可伸缩性中最重要的单一因素。数据写入磁盘的速度越快，整个系统的性能就越高。在选择存储解决方案时，请更多地关注写入性能而非读取性能。

将数据存储在一组本地磁盘上，这些磁盘由本地磁盘控制器作为 RAID 控制，或作为 SAN 控制。

注意：

将数据存储在基于 SMB 和 NFS 等基于文件的协议的 NAS 上，可能会带来性能和安全隐患。请使用最新版本的协议以避免安全隐患，并执行规模测试以确保适当的性能。

对于本地驱动器设置，请选择带有内置缓存内存的磁盘控制器。缓存允许控制器在回写期间使用梯形排序，这最大限度地减少了磁盘磁头移动，并确保写入操作在不等待物理磁盘操作完成的情况下完成。这可以以最小的额外成本显著提高写入性能。然而，缓存确实会带来断电后数据丢失的问题。为确保数据和文件系统的完整性，请考虑为缓存磁盘控制器配备电池备份设备，以确保在断电时缓存得以维护，并在最终恢复供电时将数据写入磁盘。

考虑使用合适的 RAID 存储解决方案。根据性能和冗余要求，有许多 RAID 级别可用。下表详细说明了每个 RAID 级别以及每个标准对会话录制的适用性。

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 存储解决方案。对于会话录制服务器，磁盘阵列显示为本地驱动器。SAN 的设置成本更高，但由于磁盘阵列是共享的，SAN 确实具有简化和集中管理的优势。SAN 主要有两种类型：光纤通道和 iSCSI。iSCSI 本质上是基于 TCP/IP 的 SCSI，自千兆以太网引入以来，它在光纤通道上的普及度越来越高。

数据库可伸缩性

会话录制数据库需要 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。发送到数据库的数据量很小，因为数据库只存储有关录制会话的元数据。录制会话文件本身写入单独的磁盘。通常，每个录制会话在数据库中仅占用大约 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 上运行。

如果您的会话录制部署需要在数据库中编目数百万个录制会话，请遵循 Microsoft 关于 SQL Server 可伸缩性的指南。