可伸缩性注意事项

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

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

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

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

• 文件大小小

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

  录制会话文件的小尺寸意味着视频帧的渲染更快、更流畅。录制内容也完全无损，并且没有大多数紧凑视频格式中常见的像素化。录制中的文本在播放时易于阅读，就像在原始会话中一样。为了保持文件大小小，会话录制不会在文件中录制关键帧。

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

  录制的会话文件包含会话的 ICA® 协议数据，这些数据几乎以其本机格式提取。这意味着文件捕获了用于与 Citrix Workspace™ 应用程序通信的 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 积压时，可用于实时播放的新录制数据会像所有其他数据消息一样排队。审阅者仍然可以播放文件，但查看最新的实时录制数据会延迟。如果实时播放对审阅者来说是一项重要功能，请通过在部署中设计备用容量和容错来确保积压的可能性较低。

关于 XenApp® 和 XenDesktop 系统的可扩展性分析

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

• 具有 8 GB RAM 的 64 位服务器，运行多会话操作系统 VDA
• 所有运行 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、CIFS 或 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 主要有两种类型：光纤通道 (Fibre Channel) 和 iSCSI。iSCSI 本质上是基于 TCP/IP 的 SCSI，自千兆以太网引入以来，其受欢迎程度已超过光纤通道。

数据库可伸缩性

会话录制数据库需要 Microsoft SQL Server 2016、Microsoft SQL Server 2014、Microsoft SQL Server 2012 或 Microsoft SQL Server 2008 R2。发送到数据库的数据量很小，因为数据库只存储有关录制会话的元数据。录制会话文件本身写入单独的磁盘。通常，每个录制会话在数据库中仅占用约 1 KB 的空间，除非使用会话录制事件 API 将可搜索事件插入到会话中。

Microsoft SQL Server 2016、Microsoft SQL Server 2014、Microsoft SQL Server 2012 和 Microsoft SQL Server 2008 R2 的 Express 版本对数据库大小施加了 10 GB 的限制。以每个录制会话 1 KB 计算，数据库可以编目大约 4,000,000 个会话。Microsoft SQL Server 的其他版本没有数据库大小限制，仅受可用磁盘空间的限制。随着数据库中会话数量的增加，数据库性能和搜索速度的下降可以忽略不计。

如果您不通过会话录制事件 API 进行自定义，则每个录制会话会生成四个数据库事务：录制开始时两个，用户登录到正在录制的会话时一个，以及录制结束时一个。如果您使用会话录制事件 API 自定义会话，则每个记录的可搜索事件都会生成一个事务。由于即使是最基本的数据库部署也能每秒处理数百个事务，因此数据库上的处理负载不太可能承受压力。影响足够小，会话录制数据库可以与包括 XenApp 或 XenDesktop 数据存储数据库在内的其他数据库在同一 SQL Server 上运行。

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