XenApp 和 XenDesktop 7.6 版本到当前版本的数据库大小调整指南

免责声明

本文档包含指向非 Citrix 控制的网站的链接。Citrix 不对这些第三方网站的内容或使用负责，也不认可或接受任何责任。Citrix 提供这些链接仅为方便您，包含任何链接并不意味着 Citrix 认可所链接的网站。您有责任采取预防措施，确保您选择使用的任何内容不含病毒或其他破坏性项目。

概述

典型的 XenDesktop® 7 部署包含三个数据库，如下所示：

• 站点配置数据库 存储 XenDesktop 部署的当前配置和状态
• 监控数据库 存储用于在 Director 中显示的历史数据
• 配置日志数据库 跟踪对 XenDesktop 部署所做的配置更改

默认情况下，配置日志和监控数据库（辅助数据库）与站点配置数据库位于同一服务器上。最初，所有三个数据库都具有相同的名称。Citrix 建议您在创建站点后更改辅助数据库的位置。

典型的部署还会使用 SQL Server 提供的临时数据库 TempDB。

每个数据库都有不同的用途，并以不同的速率增长。

本文档提供了有关每个数据库的信息，并强调了在调整数据库大小以支持 XenDesktop 7 时需要考虑的主要因素。

注意： 提供的所有数字均为估算值。不同部署之间存在差异是正常的。

本文档还指出了托管共享桌面 (HSD) 和虚拟桌面基础架构 (VDI) 之间在大小调整方面的差异。混合环境需要结合这两种桌面类型的估算值，以生成整体数据库大小的估算值。

XenDesktop 7.6 的文档更新说明

本文档已扩展至涵盖 7.6 XenDesktop。这是为了允许更新 7.6 中新增功能的规模调整更改。影响数据库规模调整的三个新功能是：

• 连接租用 – 压缩的租用文件存储在站点数据库中
• 应用程序使用情况监控 – 环境中使用的所有应用程序的详细信息都存储在监控数据库中
• 热修复程序清单监控 – 应用于环境中控制器、VDA 和 VDA 映像的 Citrix 热修复程序的详细信息

下文已更新表大小调整信息。每秒事务数和事务日志增长在 7.6 中与 7.5 相似，因此未对这些部分进行更新。

高层级注意事项

站点数据库

站点数据库中包含了系统运行所需的配置信息。

其使用特点如下：

• 在高峰时段达到最大大小，因为用户登录会生成需要跟踪的会话和连接信息。
• 当没有活动会话且所有 VDA 都已关闭并注销时，达到最小大小。
• 在 48 小时后达到峰值大小，因为数据库存储的持久信息很少。 这是因为站点数据库中会维护一个 48 小时的小型连接日志。
• 数据库的基线大小随着站点的配置信息增长而增长。 也就是说，更多的辅助角色和用户会占用更多的数据库空间。
• 登录期间会发生高水平的每秒事务数，因为每个用户登录都需要执行多个单独的事务，并且会根据并发启动速率进行扩展。
• VDA 心跳事务的低级别背景噪声。每个 VDA 每 5 分钟提供一次心跳，此更新会触发数据库上的事务。

故障的影响

站点数据库中断会导致系统无法管理和监控。现有连接将保持。在 XenDesktop 7.6 中，连接租用允许建立新连接和重新连接。在早期版本中，无法建立新连接和重新连接。

监控数据库

监控数据库包含有关站点的历史信息。Director 使用此信息来显示历史信息。

其使用特点如下：

• 最大大小由配置的保留期控制，如下所示：
  • 对于非白金客户，默认值为 7 天，最长保留期为 7 天。
  • 对于白金客户，默认值为 90 天，没有最长保留期。
• 达到峰值大小可能需要一些时间，因为系统必须达到配置的保留期。
• 由于监控服务更新的批处理特性，每秒事务处理量处于较低水平。每秒事务处理量很少会超过 20 笔的上限。
• 由监控服务定期进行的整合调用导致的一些后台事务。
• 系统会在夜间执行处理，以删除超出配置保留期的数据。

故障的影响

监控数据库中断会阻止为站点收集数据，这意味着数据在 Director 中不可见。

配置日志记录数据库

配置日志数据库包含站点所有配置更改的历史日志。此信息用于生成报告或在 Studio 中显示。

其使用特点如下：

• 最大大小难以预测，因为它取决于配置活动的多少。
• Director 中的任何操作（例如会话重置）都会记录到此数据库中，因此随着管理员使用 Director，数据库可能会缓慢增长。
• 当未进行配置更改时，数据库上发生的事务活动量极小。
• 更新期间事务速率较低，因为更新在可能的情况下会进行批处理。
• 数据的手动删除。配置日志数据库中的数据不受任何保留策略的约束，除非管理员手动删除，否则不会被删除。

故障所造成的影响

配置日志数据库发生中断所带来的影响，将根据站点配置的不同而有所差异，具体如下所示：

• 如果配置日志数据库不可用时站点不允许更改，则无法重新配置 XenDesktop 部署。
• 如果配置日志数据库不可用时站点允许更改，则可能会对 XenDesktop 部署进行未跟踪的配置更改。

临时数据库

临时数据库是 SQL Server 提供的系统范围数据库。它用作读已提交快照隔离的版本存储。XenDesktop 7 使用此 SQL Server 功能来减少 XenDesktop 数据库中的锁争用。

版本存储的大小取决于活动事务的数量。然而，通常情况下，它不会超过几 MB。

TempDB 的性能确实会影响 XenDesktop 代理的性能，因为任何生成新数据的事务都需要 TempDB 空间。然而，XenDesktop 倾向于具有短期事务，这有助于保持版本存储大小较小。

当查询生成大型中间结果集时，也会使用临时数据库。

有关 TempDB 大小调整和配置的指南，请参阅 Microsoft 的产品文档：

https://docs.microsoft.com/zh-cn/sql/relational-databases/databases/tempdb-database?view=sql-server-ver15

主要争议点在于要使用的文件数量。较旧的 SQL Server 版本（例如 SQL Server 2000）比新版本需要更多的文件。有关要使用的文件数量的更多信息，请参阅：

http://www.sqlskills.com/blogs/paul/a-sql-server-dba-myth-a-day-1230-tempdb-should-alwayshave-one-data-file-per-processor-core/

数据库读已提交快照隔离

Citrix 建议所有 XenDesktop 7 数据库都使用已提交读快照隔离。有关更多信息，请参阅 如何在 XenDesktop 中启用已提交读快照。

数据库大小调整

数据库大小取决于许多关键因素，包括工作日期间创建的会话和连接数。

会话是指在一段时间内运行的任何桌面或应用程序，它可以断开连接并重新连接。

连接是指用户连接到会话的任何时间。断开连接会关闭连接，但不会关闭会话。当用户重新连接时，这会创建一个到现有会话的新连接。

站点数据库

站点数据库的最大大小基于 VDA 数量和活动会话数，如下所示：

每个已发布的应用程序会向数据库增加 110 KB，用于存储每个唯一的图标。

注意：

7.6 版本增加的大小是由于连接租约作为控制器之间复制的一部分存储在数据库中。

监控数据库

在这三个数据库中，监控数据库预计会随着时间的推移增长到最大。

其大小取决于许多因素，包括以下内容：

• 用户数量
• 会话的数量
• 数据库连接的数量
• VDI 或 HSD 工作程序
• 已配置的保留期

下面是数据库在多个数据点上的大小估算。此数据是根据对 XenDesktop 进行规模测试时观察到的数据估算得出的。这些估算被认为是切合实际的。

然而，维护其数据库的客户可能会发现其数据库比估计值更小。

HSD 用户基于每个 HSD 服务器 100 个用户。

数据最长保留期限

保留数据的最大量由许可证控制，具体如下：

• 非白金客户最多可保留 1 周（7 天）的数据。
• 白金客户可以保留无限量数据；默认值为 3 个月（90 天）。

保留期可以通过执行 Set-MonitorConfiguration 命令来进行调整。

一旦数据超过配置的保留期，它就会从数据库中删除。

XenDesktop 7.5 监控数据库大小调整

每个用户 1 个连接和 1 个会话，每周工作 5 天的估算值

基于每用户2个连接和1个会话，以及5天工作周的估算

请注意，HSD 随着时间的推移会因为记录负载均衡信息而生成更多数据，但最初它们的大小与 VDI 桌面相似。

XenDesktop 7.6 监控数据库容量规划

与 7.5 相比，主要变化是：

• 热修复信息 以下数据基于每个 Worker（VDI 或 HSD）3 个热修复
• 应用程序使用历史记录 这主要与 HSD 系统相关。

基于每个用户 1 个连接和 1 个会话，每周工作 5 天的估算值

基于每个用户2个连接和1个会话，以及5天工作周的估算

配置日志记录数据库

为配置日志数据库提供大小调整指南要困难得多，因为它会根据日常 Director 活动和配置的站点大小而显著变化。

对会话或用户有影响的活动会被记录下来，例如会话注销和重置。被动活动（例如列出用户的会话）则不会被记录。

用于部署桌面系统的机制，同样会影响到所记录数据的存储容量。

在不使用 MCS 的 HSD 环境中，数据库大小通常在 30 MB 到 40 MB 之间。

对于 MCS 环境，由于记录了所有 VM 构建数据，数据库大小很容易超过 200 MB。

7.6 版本未对配置日志数据库进行重大更改。

10 万个 HSD 会话登录期间的数据库活动

在可伸缩性测试中，模拟 10 万个 HSD 会话登录，在两种登录速率下测量了事务日志增长情况，如下所示：

• 10万用户在1小时内登录
• 10万用户在2小时内登录

选择这些速率是为了提供示例数据点。

该环境由以下部分组成：

• 2 个交付控制器
• 43 个 HSD VDA 工作程序
• 3 台 SQL 服务器，配置了数据库，并包含在一个 Always On 可用性组中

服务器配置的详细信息在本文档末尾提供。

事务日志增长

所有数据库的事务日志增长均使用性能监视器计数器 SqlServer:Databases – Log File(s) Used Size (KB) 进行监控。

站点数据库

当系统空闲时，事务日志每小时增长 3.5 MB。这是 VDA 和 Broker Service 心跳的组合。

在测量的时间段内，日志增长呈线性。这些数据表明，每个用户登录时，事务日志会增长20 KB。每个用户注销时，事务日志会增长12 KB。

因此，每个用户登录/注销周期每天的增长量为32 KB。

监控数据库

当系统空闲时，事务日志每小时增长30.5 MB。这是整合存储过程和HSD VDA负载索引更新的组合。

日志增长在测量期间呈线性。此数据表明，每个用户登录时，事务日志会增长 7 KB。每个用户注销时，事务日志会增长 2 KB。

因此，每个用户登录/注销周期的每日增长量为 9 KB。

每秒事务处理量

所有数据库的事务日志增长使用以下性能监视器计数器进行监视：

• SQL Server 数据库 – 每秒事务数
• SQL Server 数据库 – 每秒写入事务数

站点数据库

当系统空闲时，有 5 个事务/秒，其中 1 个写入事务/秒用于维护 VDA 和 Broker 心跳。

注意： 这些数字是根据给定时间段估算的。实际负载会因每秒并发启动次数而异。

监控数据库

当系统空闲时，整合存储过程每分钟运行一次，并生成事务。然而，事务级别很小。通常，每个整合存储过程有 2-3 个事务和 1 个写入事务，并且运行 3 个整合存储过程。在活动期间，随着更多工作的执行，开销会增加。

注意： 这些数字是根据给定时间段估算的。

CPU 使用率

用于此测试的所有 SQL 服务器都是启用了超线程的双六核服务器。详细的硬件规格在本文档末尾提供。

已知这些服务器对于运行的负载而言是过大的。这使我们能够识别硬件的限制和最大值。预计 SQL CPU 负载实际上可以由单四核 SQL Server 处理，而不是双六核系统。

在测试期间，系统 CPU 使用性能监视器计数器 处理器 – % 处理器时间 – _总计 进行监控。

主数据库副本

空闲时，CPU 占用可用 CPU 的 0-2%。整合存储过程每分钟会引起持续约 1 秒的峰值，达到系统 CPU 的 8-10%。预计这会根据处理的数据量进行扩展。

在 1 小时内 100,000 用户登录期间，CPU 跃升至 7%，并随着环境中会话和用户数量的增加线性增长至 11%。请注意，整合存储过程的峰值使总 CPU 增加了 7%，导致峰值达到 CPU 的 18%。

注销期间，CPU 运行在 3.5%，整合存储过程额外占用 7% 的 CPU。总体而言，这表明维持登录和注销速率需要双六核 CPU 的 <20%。

注意： Windows Server 2012 调度程序倾向于仅在需要时才使用超线程，也就是说，在系统达到 50% 负载之前，它尽可能每个核心只运行一个线程，因此 24 个超线程上的 20% 负载相当于在 4.8 个核心上运行。

考虑到工作负载，这被认为是一项重度压力测试，并且单个四核 SQL 服务器足以满足 XenDesktop 部署的需求。

辅助数据库副本

发现辅助副本在登录期间占用 2% 的 CPU，在注销期间占用 1.5% 的 CPU。这是预料之中的，因为在大多数情况下，副本将主副本的数据存储在其磁盘上，并且只有同步副本参与事务，因为主副本在辅助副本确认之前不会提交事务。

根据 HA 硬件与主副本匹配的建议，此负载将由配置类似的服务器轻松处理。

临时数据库使用情况

TempDB 用于多种目的，包括版本存储、大型查询集空间以及其他临时表使用。

TempDB 大小调整

在此 SQL 配置中，TempDB 配置为拥有 8 个数据库文件，每个文件固定大小为 5 GB。这允许更好地并发使用 TempDB，但也提供了充足的空间，并且不会触发任何自动增长事件。根据捕获的数据，对于此部署而言，它的大小过大。然而，有充足的可用磁盘空间。

它也符合以下一般指导原则：TempDB 数据库文件的数量应为可用 CPU 数量的四分之一到一半之间，但在不确定是否存在实际争用的情况下，不应超过 8 个。

请注意，只使用一个 TempDB 日志文件，因为 SQL Server 不会从多个日志文件中受益。

版本存储

TempDB 包含一个版本存储，用于与 XenDesktop 数据库使用的读已提交快照隔离相关的行版本。

使用情况可以通过以下性能计数器进行衡量：

• SQLServer:事务 – 版本存储大小 (KB)
• SQLServer:事务 – 版本清理速率 (KB/s)
• SQL服务器:事务 – 版本生成速率 (KB/s)

在 1 小时内 100,000 次登录期间，版本存储大小保持在 10 MB 到 30 MB 之间，呈现锯齿状效应，即版本创建后又被清理。注销期间，范围为 10 MB 到 21 MB。空闲时，版本存储大小范围为 1 MB 到 4 MB。

登录期间的版本生成速率在 250–500 KB 范围内；注销期间为 150–400 KB/秒；空闲时为 0–250 KB/秒。

版本清理每分钟运行一次，登录期间达到 2,500 KB/秒，注销期间达到 1,750 KB/秒，空闲期间达到 400 KB/秒。

磁盘 I/O

在登录测试期间，磁盘 I/O 使用以下性能计数器进行测量：

• 物理磁盘 – 磁盘读取字节/秒
• 物理磁盘 – 磁盘写入字节/秒
• 物理磁盘 – 磁盘读取数/秒
• 物理磁盘 – 磁盘写入数/秒

读取 I/O 被发现是最小的，因为 SQL 服务器能够将所有数据保存在内存中，导致系统上的读取活动非常少。

由于数据库和存储系统的布局，卷被拆分，其中一个卷保存所有数据文件，另一个卷保存所有事务日志文件。

数据显示了一种难以用表格表示的模式。通常，事务日志在 1 小时测试中写入字节/秒为 800 KB/s，在 2 小时测试中为 400 KB/s。每分钟一次，当整合存储过程运行时，事务日志显示峰值达到 30 MB/s。

对整合存储过程的分析表明，有时统计信息会使查询计划不理想，并且临时表溢出到 TempDB 中。这会触发对 TempDB 事务日志的写入。

这种数据传输转化为 1 小时测试中 300 次写入每秒输入/输出操作 (IOPS) 的稳定状态，以及 2 小时测试中 200 次写入 IOPS。整合存储过程的峰值在运行时会额外增加 2-300 次写入 IOPS。请注意，在大型环境中，整合存储过程的运行时间不到一秒。

当每个数据库进行检查点时，数据会从内存中的表同步到数据卷上的数据文件。

For more information on SQL checkpointing, see http://technet.microsoft.com/enus/.

这些检查点是非常短的活动周期，通常小于 1 秒。

在登录期间，检查点消耗了 6-7 MB/s 和 500 次写入 IOPS。在注销期间，检查点消耗了 7 MB/s，范围在 200-700 IOPS 之间。这些数字之所以不同，是因为站点和监控数据库需要检查点的数据量不同。

数据库维护

大型部署中的数据库维护非常重要。如果数据库未得到妥善维护，可能会因数据库空间不足而导致数据库中断，例如，如果事务日志设置为自动增长并占满磁盘，或者事务日志是固定大小并已满。

事务日志的维护

当使用 SQL Server 高可用性功能时，例如 Always On 可用性组或数据库镜像，XenDesktop 数据库以完整事务日志记录模式运行。

以完整事务日志记录模式运行时，事务日志会持续增长，直到进行数据库或事务日志备份。

如果未监控事务日志文件，这可能会导致问题，因为 SQL Server 默认将日志文件配置为自动增长。这会导致 2 个问题：

1. 事务日志文件会占用大量磁盘空间。
2. 每次事务日志增长时，它都会暂停所有事务，直到日志空间被清零。

Citrix 建议定期备份日志文件。这可以通过计划作业或维护计划来完成。

或者，使用 SQL Server Agent 监控日志使用大小何时超过阈值并运行备份作业。

在规模测试中，使用了 4 GB 的固定大小日志，并设置了警报，当日志文件达到 80% 满时将其备份到另一个文件。这阻止了日志增长并占用所有磁盘空间，也阻止了它清零磁盘空间并导致数据库停滞。

一个示例作业将运行如下脚本：

BACKUP LOG [CitrixXenDesktop-SiteDB] TO DISK = N'D:\LogBackup\CitrixXenDesktopSiteDB.bak' WITH NOFORMAT, NOINIT, COMPRESSION, NAME = N'Site-Transaction Log Backup', SKIP, NOREWIND, NOUNLOAD

用于警报的 SQL 性能计数器是：

SQLServer:Databases - Percent Log Used - CitrixXenDesktopSiteDB

对所有 3 个数据库重复此操作。

日志文件的备份对正在运行的 XenDesktop 环境影响最小，代理时间略有增加，但我们认为这并不显著。

有关配置作业的更多详细信息，请参阅：https://docs.microsoft.com/zh-cn/sql/ssms/agent/create-a-job?view=sql-server-ver15

若要了解有关配置警报的更多详细信息，请参阅 Microsoft 文档中的以下链接：(https://docs.microsoft.com/zh-cn/sql/ssms/agent/alerts?view=sql-server-ver15)

关于索引维护

随着更多数据输入到数据库中，一些索引开始变得不那么满，即每个 SQL 页面中存储的记录更少。一个 SQL 页面为 8 KB。这导致数据库增加其存储需求，包括内存和磁盘。通过维护索引，可以提高页面填充度，从而减少数据库的内存需求。

Citrix 建议客户设置维护计划，每晚和每周运行以维护索引。维护计划可以简单地是在工作日夜间重组索引，并在周末重建索引。

此建议可避免在日常操作中重建任何大型索引所带来的性能影响，特别是对于大型监控数据库而言。

Microsoft 建议，如果索引碎片超过 30%，则重建索引；如果低于 30%，则重组索引。有关更多信息，请参阅 Microsoft 文档。

重组索引后，还应更新统计信息。随着数据库的增长，这一点尤为重要；否则，某些统计信息可能不佳，SQL 可能会生成次优的 SQL 查询计划。

在节省空间方面，以下 Microsoft 脚本针对 1.2GB 监控数据库运行。它提高了页面填充度并释放了 300 MB 空间。

第三方脚本

微软

Microsoft 建议使用以下脚本更新其 WSUS SQL 数据库的索引：

https://learn.microsoft.com/zh-cn/troubleshoot/mem/configmgr/update-management/reindex-the-wsus-database

通过更改“USE SUSDB”，此脚本也可以针对 XenDesktop 数据库运行。此脚本遵循 Microsoft 的最佳实践，即重建碎片超过 30% 的索引，并重组碎片低于 30% 的索引。然后，它会更新数据库的统计信息。

奥拉·哈伦格伦

更高级的脚本也可从以下位置获取：

http://ola.hallengren.com/

这些脚本在 SQL Server 社区中备受推崇。特别是，可从以下位置获取的索引脚本：

http://ola.hallengren.com/sql-server-index-and-statistics-maintenance.html

这些脚本可用于更精细地控制重组或重建索引的级别。

测试服务器配置

SQL 服务器配置

SQL 可用性组由 3 台配置相同的 Dell R720XD 服务器组成。

系统配置详细说明：

• 2 个六核 Intel Xeon CPU E5-2630，运行频率为 2.30 GHz，启用超线程
• 64 GB ECC 随机存取存储器
• PERC H710P 迷你版，配备 1 GB 电池备份缓存
• 26 块 300 GB 10000 转/分钟 SAS 硬盘

这些磁盘被划分为以下几个卷：

• 系统存储卷
  • 包含操作系统和页面文件
  • 2 个磁盘作为 RAID 1 镜像
  • 总容量 278 GB
• 数据库卷
  • 包含 SQL Server 实例和数据库数据文件
  • 16 个磁盘作为 RAID 10 镜像条带
  • 总容量 2,231 GB
• 日志卷
  • 包含数据库日志文件
  • 8 个磁盘作为 RAID 10 镜像条带
  • 总容量 1,115 GB
• 软件：
  • Windows Server 2012 R2 标准版，包含测试时（2014 年 8 月）的最新 Windows 更新
  • SQL Server 企业版 2012 SP2 附带累积更新 1
• 配置方面的更改
  • SQL Server 配置为使用最大容量 61,440 MB
  • 所有 SQL 实例上均启用了数据库包含。
  • SQL Server Agent 服务被配置为自动启动
• 可用性组设置：
  • 所有服务器都放置在 Windows 故障转移群集中。
  • 在群集内配置了 Always On 可用性组。
  • 次要副本被配置为同步提交模式，这要求事务必须在两个副本上都成功提交后，整个事务操作才能最终完成。
  • 只读副本路由功能已针对该可用性组进行了配置和启用。

交付控制器™ 和 HSD 测试服务器

Delivery Controller 和 HSD 测试服务器在相同的硬件配置上运行，使用 HP BL460c G1 刀片服务器。其中 2 台服务器用于 Delivery Controller，43 台服务器提供模拟的 HSD 工作负载。

注意： 尽管这些服务器相对较旧，但 HSD 服务器上的工作负载较低，因为会话模拟主要侧重于对 Delivery Controller 而非 HSD 服务器施加负载。

系统配置说明：

• 2 个四核 Intel Xeon L5320，运行频率为 1.86 GHz，不支持超线程
• 16 GB ECC 随机存储器
• 惠普 Smart Array E200I RAID 阵列卡（无电池备份缓存）
• 一个 36 GB 或 72 GB 的 SAS 硬盘

软件：

• Windows Server 2012 R2 标准版，包含测试时（2014 年 8 月）的最新 Windows 更新
• 思杰 Xen桌面 7.6