可扩展性注意事项
Session Recording 是一个高度可扩展的系统，可处理数千或数万个会话。安装和运行 Session Recording 除了运行 Citrix Virtual Apps and Desktops™ 或 Citrix DaaS（以前称为 Citrix Virtual Apps and Desktops 服务）所需的资源之外，几乎不需要额外的资源。但是，如果您计划录制大量会话，或者您计划录制的会话可能导致大型会话文件（例如，图形密集型应用程序），我们仍然建议您考虑系统的性能。
本文介绍了 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™ 应用程序通信的 ICA 协议数据流。无需运行昂贵的转码或编码软件组件来实时更改数据格式。低处理量对于 VDA 可扩展性也很重要。它确保从同一 VDA 录制多个会话时，最终用户体验得以保持。
此外，仅录制可回放的 ICA 虚拟通道，从而实现进一步优化。例如，打印机和客户端驱动器映射通道不会被录制。这些通道可以生成大量数据，但对视频播放没有任何好处。
估算数据输入和处理速率
Session Recording 服务器是录制会话文件的中央收集点。每台运行启用了 Session Recording 的多会话操作系统 VDA 的计算机都会将录制的会话数据发送到 Session Recording 服务器。Session Recording 可以处理大量数据，并能容忍突发和故障。但单个服务器可以处理的数据量存在物理限制。
考虑您向每个 Session Recording 服务器发送的数据量。估算服务器处理和存储数据的速度。系统存储传入数据的速率必须高于数据输入速率。
要估算您的数据输入速率，请执行以下计算：
- 将录制的会话数量与平均会话大小相乘。
- 将计算出的乘积除以您正在录制会话的持续时间。
例如，您可能在 8 小时工作日内录制 5,000 个 Microsoft Outlook 会话，每个会话 20 MB。在这种情况下，数据输入速率约为 3.5 Mbps。（5,000 个会话乘以 20 MB，除以 8 小时，再除以每小时 3,600 秒。）连接到 100 Mbps LAN 并具有足够磁盘空间来存储录制数据的典型 Session Recording 服务器可以以大约 5.0 Mbps 的速率处理数据。此速率是基于磁盘和网络 IOPS 施加的物理限制的处理速率。在此示例中，处理速率（5.0 Mbps）高于输入速率（3.5 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 方面开销很大。因此，请为每个会话录制服务器设计充足的备用容量。如后面部分所述，添加更多服务器或改进现有服务器的规格始终可以为您带来额外的容量。一般经验法则是将会话录制服务器的最大运行容量设置为其总容量的 50%。在前面的示例中，如果服务器可以处理 5.0 Mbps，则目标是系统仅以 2.5 Mbps 运行。不要在一个会话录制服务器上录制生成 3.5 Mbps 的 5,000 个 Outlook 会话，而是减少到仅生成约 2.5 Mbps 的 3,500 个会话。
积压和实时播放
实时播放是指审阅者在会话仍处于活动状态时打开会话录制进行播放。在实时播放期间，负责的会话录制代理会切换到该会话的流模式。录制数据会立即发送到存储管理器，而无需内部缓冲。由于录制文件会不断更新，因此播放器可以继续获取来自实时会话的最新数据。但是，从代理发送到存储管理器的数据是通过 MSMQ 进行的，因此前面描述的排队规则适用。在这种情况下可能会出现问题。当 MSMQ 积压时，可用于实时播放的新录制数据会像所有其他数据消息一样排队。审阅者仍然可以播放文件，但查看最新的实时录制数据会延迟。如果实时播放对审阅者来说是一项重要功能，请确保积压的可能性较低。您可以在部署中设计备用容量和容错功能。
系统可伸缩性
会话录制绝不会降低会话性能，也绝不会因录制数据积压而停止会话。在会话录制系统的设计中，维护最终用户体验和单服务器可伸缩性至关重要。如果录制系统出现不可逆转的过载，则录制会话数据将被丢弃。录制 ICA 会话对 VDA 的性能和可伸缩性影响很小。影响大小取决于平台、可用内存以及正在录制会话的图形特性。通过以下配置，您可以预期单服务器可伸缩性影响在 1% 到 5% 之间。换句话说，如果一台服务器在未安装会话录制的情况下可以托管 100 个用户，则安装后可以托管 95-99 个用户：
- 运行多会话操作系统 VDA 的 64 位服务器，配备 8 GB RAM
- 所有会话都运行 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 不太可能成为瓶颈。 |
会话录制服务器硬件
您可以通过仔细选择会话录制服务器硬件来增加部署容量。您有两种选择：纵向扩展（通过增加每台服务器的容量）或横向扩展（通过添加更多服务器）。无论选择哪种方式，您的目标都是以最低成本提高可伸缩性。
纵向扩展
在检查单个会话录制服务器时，请考虑以下最佳实践，以确保在可用预算内实现最佳性能。系统依赖于 IOPS，以确保录制数据从网络到磁盘的高吞吐量。因此，投资适当的网络和磁盘硬件非常重要。对于高性能会话录制服务器，建议使用双 CPU 或双核 CPU，但更高规格的配置收益甚微。建议使用 64 位处理器架构，但 x86 处理器类型也适用。建议使用 4 GB RAM，但增加更多 RAM 的收益同样甚微。
横向扩展
即使采用最佳的纵向扩展实践，当录制大量会话时，单个会话录制服务器的性能和可伸缩性也存在局限性。可能需要添加额外的服务器来满足负载。您可以在不同的计算机上安装更多会话录制服务器，使这些服务器作为负载平衡池工作。在此类部署中，会话录制服务器共享存储和数据库。为了分配负载，将会话录制代理指向负责工作负载分配的负载均衡器。
网络容量
100 Mbps 网络链路适用于连接会话录制服务器。千兆以太网连接可能会提高性能，但其性能不会比 100 Mbps 链路高 10 倍。实际上，吞吐量的增益会更小。
确保会话录制使用的网络交换机不与可能争夺可用网络带宽的第三方应用程序共享。理想情况下，网络交换机应专用于会话录制服务器。如果网络拥塞被证明是瓶颈，则网络升级是提高系统可伸缩性的一种相对经济的方式。
存储
对磁盘和存储硬件的投资是服务器可伸缩性中最重要的单一因素。数据写入磁盘的速度越快，整个系统的性能就越高。在选择存储解决方案时，请更多地关注写入性能而非读取性能。
将数据存储在 RAID 或 SAN 上。
注意：
将数据存储在基于文件协议（例如 SMB 和 NFS）的 NAS 上，可能会带来性能和安全隐患。请使用最新版本的协议以避免安全隐患，并执行规模测试以确保适当的性能。
对于本地驱动器设置，请选择带有内置缓存内存的磁盘控制器。缓存允许控制器在回写期间使用电梯排序。它最大限度地减少了磁盘磁头移动，并确保写入操作在不等待物理磁盘操作完成的情况下完成。它可以在最小的额外成本下显著提高写入性能。然而，缓存确实会带来断电后数据丢失的问题。为确保数据和文件系统的完整性，请考虑为缓存磁盘控制器配备电池备份设备。
考虑使用合适的 RAID 存储解决方案。根据性能和冗余要求，有多种 RAID 级别可用。下表详细说明了每种 RAID 级别以及每种标准对会话录制的适用性。
| RAID 级别 | 类型 | 最少磁盘数 | 描述 |
|---|---|---|---|
| RAID 0 | 无奇偶校验的条带集 | 2 | 提供高性能但无冗余。任何磁盘的丢失都会破坏阵列。RAID 0 是一种低成本解决方案，用于存储录制会话文件，其中数据丢失的影响较低。通过添加更多磁盘可轻松扩展性能。 |
| RAID 1 | 无奇偶校验的镜像集 | 2 | 相较于单个磁盘没有性能提升，使其成为相对昂贵的解决方案。仅在需要高冗余级别时才使用此解决方案。 |
| RAID 3 | 带有专用奇偶校验的条带集 | 3 | 提供高写入性能，冗余特性类似于 RAID 5。RAID 3 推荐用于视频制作和直播应用程序。由于会话录制属于此类应用程序，因此强烈推荐 RAID 3，但它并不常见。 |
| RAID 5 | 带有分布式奇偶校验的条带集 | 3 | 提供高读取性能和冗余，但代价是写入性能较慢。RAID 5 是最常见的通用用途。但由于写入性能较慢，不建议将 RAID 5 用于会话录制。RAID 3 可以以相似的成本部署，但具有更好的写入性能。 |
| RAID 10 | 镜像集和条带集 | 4 | 提供 RAID 0 的性能特性和 RAID 1 的冗余优势。这是一种昂贵的解决方案，不建议用于会话录制。 |
RAID 0 和 RAID 3 是最推荐的 RAID 级别。RAID 1 和 RAID 5 是流行的标准，但不建议用于会话录制。RAID 10 确实提供了一些性能优势，但对于额外的收益来说过于昂贵。
确定磁盘驱动器的类型和规格。IDE/ATA 驱动器以及外部 USB 或 Firewire 驱动器不适用于 Session Recording。主要选择是 SATA 和 SCSI。SATA 驱动器与 SCSI 驱动器相比，以更低的每 MB 成本提供相当高的传输速率。然而，SCSI 驱动器提供更好的性能，并且在服务器部署中更常见。服务器 RAID 解决方案大多支持 SCSI 驱动器，但现在也有一些 SATA RAID 产品可用。在评估磁盘驱动器产品的规格时，请考虑磁盘的转速和其他性能特征。
Because the recording of thousands of sessions per day can consume significant amounts of disk space, you must choose between overall capacity and performance. From the earlier example, recording 5,000 Outlook sessions over an 8-hour work day consumes about 100 GB of storage space. To store 10 days’ worth of recordings (that is, 50,000 recorded session files), you need 1,000 GB (1 TB). This pressure on disk space can be eased by shortening the retention period before archiving or deleting old recordings. If 1 TB of disk space is available, a seven-day retention period is reasonable, ensuring disk space usage remains around 700 GB, with 300 GB remaining as a buffer for busy days. In Session Recording, the archiving and deleting of files is supported with the ICLDB utility. It has a minimum retention period of two days. You can schedule a background task to run once a day at some off-peak time. For more information about the ICLDB commands and archiving, see Manage your database records.
The alternative to using local drive and controllers is to use a SAN storage solution based on block-level disk access. To the Session Recording server, the disk array appears as a local drive. SANs are more expensive to set up, but as the disk array is shared, SANs do have the advantage of simplified and centralized management. There are two main types of SAN: Fibre Channel and iSCSI. iSCSI is essentially SCSI over TCP/IP and is gaining popularity over Fibre Channel since the introduction of Gb Ethernet.
数据库可扩展性
The volume of data sent to the Session Recording database is small because the database stores only metadata about the recorded sessions. The files of the recorded sessions themselves are written to a separate disk. Typically, each recorded session requires only about 1 KB of space in the database, unless the Session Recording Event API is used to insert searchable events to the session.
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 上运行。
If your Session Recording deployment requires many millions of recorded sessions to be cataloged in the database, follow Microsoft guidelines for SQL Server scalability.