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/en-us/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 的大小增加是由于连接租约作为 Controller 之间复制的一部分存储在数据库中。

监视数据库

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

它的大小取决于许多因素，包括以下因素：

• 用户数
• 会话数
• 连接数
• VDI 或 HSD 工作人员
• 已配置保留期

以下是多个数据点处的数据库大小的估计值。此数据是根据规模测试 XenDesktop 时看到的数据得出的估计值。这些估计被认为是现实的。

但是，维护数据库的客户可能会发现他们的数据库比估计的要小。

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

最长保留期

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

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

可以使用设置 Set-MonitorConfiguration cmdlet 调整保留期。

如果数据早于配置的保留期，则会将其从数据库中删除。

XenDesktop 7.5 监视数据库大小

估计每位用户 1 次连接和 1 次会话，每周工作时间为 5 天

估计每位用户 2 次连接和 1 次会话，每周工作时间为 5 天

请注意，由于记录负载平衡信息，HSD 会随着时间的推移生成更多的数据，但最初的大小与 VDI 桌面类似。

XenDesktop 7.6 监视数据库大小

7.5 的主要变化是：

• 修补程序信息
  以下数据基于每个工作程序（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 会话登录）期间，事务日志增长在两个登录速率下测量，如下所示：

• 超过 1 小时的 10 万用户登录
• 超过 2 小时的 10 万用户登录

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

该环境由以下部分组成：

• 2 个 Delivery Controller
• 43 个 HSD VDA 工作人员
• 3 个 SQL Server，配置了数据库，保存在一个始终处于可用性组中

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

事务日志增长

使用性能监视器计数器 SqlServer:Databases — 日志文件使用大小 (KB) 来监视所有数据库的事务日志增长。

站点数据库

当系统处于空闲状态时，事务日志每小时增长 3.5 MB。这是 VDA 和 Broker Service 检测信号的组合。

在所测量的时间段内，对数的增长是线性的。此数据表明，每次用户登录，事务日志将增加 20 KB。每次用户注销，事务日志将增加 12 KB。

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

监视数据库

当系统处于空闲状态时，事务日志每小时增长 30.5 MB。这是合并存储过程和 HSD VDA 负载指数更新的组合。

在测量的时间段内，对数的增长是线性的。此数据表明，每个用户登录的事务日志会增加 7 KB。每次用户注销，事务日志将增加 2 KB。

因此，每用户登录/注销周期每天增长 9 KB。

每秒事务数

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

• SqlServer:Databases – 事务/秒
• SqlServer:Databases - 写入事务/秒

站点数据库

当系统处于空闲状态时，每秒有 5 个事务，其中 1 个写入事务/秒维持 VDA 和 Broker 检测信号。

注意： 这些数字是从给定时间段得出的估计数。确切的负载取决于每秒并发启动的次数。

监视数据库

当系统处于空闲状态时，合并存储过程每分钟运行一次，然后生成事务。但是，交易水平很小。通常，每个合并存储过程有 2 到 3 个事务和 1 个写入事务，并运行 3 个合并存储过程。在活动期间，开销会随着工作量的增加而增加。

注意： 这些数字是从给定时间段得出的估计数。

CPU 使用率

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

已知服务器的尺寸过大，无法承受正在运行的负载。这使我们能够确定硬件的限制和最大值。预计 SQL CPU 负载实际上可能由具有单个四核而不是双十六核系统的 SQL Server 来处理。

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

主副本

空闲时 CPU 的运行速度为可用 CPU 的 0-2%。整合存储过程每分钟会导致大约 1s 到 8-10% 的系统 CPU 出现峰值。预计将根据正在处理的数据量进行扩展。

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

在注销期间，CPU 运行率为 3.5%，其中 7% 的 CPU 用于整合存储过程。总体而言，这表明维持登录和注销率需要不到 20% 的双六进制核心。

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

鉴于工作负载，相信这是一个沉重的压力测试，并且单个四核 SQL Server 将足够用于 XenDesktop 部署。

辅助副本

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

根据高可用性硬件与主副本匹配的建议，类似指定的服务器可以非常轻松地处理此负载。

临时数据库用法

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

TempDB 大小

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

它还保持在 TempDB 数据库文件数量的一般指导范围内，在可用的 CPU 数量的一半之间，但不超过 8，不知道是否有实际争用。

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

版本存储

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

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

• SQLServer:Transactions — 版本存储大小 (KB)
• SQLServer:事务 - 版本清理速率（KB/秒）
• SQLServer:事务 - 版本生成速率（KB/秒）

在超过 1 小时的 100000 次登录期间，版本存储大小保持在 10 MB 到 30 MB 的范围内，在创建并清理版本时具有锯齿效果。在注销期间，范围为 10 MB 到 21 MB。空闲时，版本存储大小介于 1 MB 到 4 MB 之间。

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

版本清理每分钟运行一次，登录时达到 2500 KB/秒，注销时达到 1750 KB/秒，空闲期间达到 400 KB/秒。

磁盘 I/O

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

• PhysicalDisk — 磁盘读取字节/秒
• PhysicalDisk — 磁盘写入字节/秒
• PhysicalDisk — 磁盘读数/秒
• PhysicalDisk — 磁盘写入/秒

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

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

数据显示了一种难以放入表格的模式。一般来说，事务日志的写入字节/秒为 1 小时测试 800 KB/秒，2 小时测试 400 KB/秒。每分钟一次，当合并存储过程运行时，事务日志显示峰值为 30 MB/秒。

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

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

对每个数据库执行检查点操作时，会将 In-Memory 表中的数据同步到数据卷上的数据文件。

有关 SQL 检查点操作的更多信息，请参阅 http://technet.microsoft.com/enus/。

这些检查站的活动时间非常短，通常小于 1 秒。

在登录过程中，检查点消耗了 6-7 MB/秒和 500 写入 IOPS。注销期间，检查点消耗了 7 MB/秒，介于 200—700 IOPS 之间。这些数字会有所不同，因为站点数据库和监视数据库要检查点的数据量不同。

数据库维护

大型部署中的数据库维护非常重要。如果未正确维护数据库，则可能会由于缺少数据库空间而导致数据库中断，例如，如果事务日志设置为自动增长并填满磁盘，或者事务日志大小固定且已满。

事务日志维护

使用 SQL Server 高可用性功能（例如“始终处于可用性组”或“数据库镜像”）时，XenDesktop 数据库以完全事务日志记录模式运行。

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

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

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

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

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

在规模测试中，使用了 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 - 使用的百分比日志 - CitrixXenDesktopSiteDB

对这 3 个数据库中的每个数据库重复此操作。

发现日志文件的备份对正在运行的 XenDesktop 环境的影响微乎其微，代理时间略有增加，但我们认为这并不重要。

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

有关配置警报的更多详细信息，请参阅： https://docs.microsoft.com/en-us/sql/ssms/agent/alerts?view=sql-server-ver15

索引维护

随着更多的数据输入到数据库中，一些索引开始变得不够完整，也就是说，每个 SQL 页中存储的记录也就减少了。一个 SQL 页的大小为 8 KB。这会导致数据库在内存和磁盘上的存储需求增加。通过维护索引，可以提高页的完整度，从而降低数据库的内存需求。

Citrix 建议客户的安装维护计划每晚和每周运行一次，以维护索引。维护计划可能只是在本周的夜间重组指数，并在周末重建指数。

此建议可避免在日常操作中重建任何大型索引造成的任何性能影响，尤其是对于大型监视数据库。

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

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

就节省的空间而言，下面的 Microsoft 脚本针对 1.2 GB 的监视数据库运行。它改进了页面填充并释放了 300 MB 的空间。

第三方脚本

Microsoft

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

http://gallery.technet.microsoft.com/scriptcenter/6f8cde49-5c52-4abd-9820-f1d270ddea61

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

Ola Hallengren

更高级的脚本也可以从以下网址获得：

http://ola.hallengren.com/

这些脚本在 SQL Server 社区中备受推崇。具体而言，索引脚本可从以下网址获得：

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

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

测试服务器配置

SQL Server 配置

SQL 可用性组由三台相同指定的 Dell R720XD 服务器组成。

系统规格：

• 2 个半核 Intel Xeon CPU E5-2630，运行频率为 2.30 GHz，并且启用了超线程
• 64 GB ECC RAM
• PERC H710P Mini 带 1 GB 电池后备缓存
• 26 300 GB 10k RPM SAS 驱动器

磁盘被拆分为以下卷：

• 系统音量
  • 包含操作系统和页面文件
  • 2 个磁盘作为 RAID 1 镜像
  • 总容量 278 GB
• 数据库卷
  • 包含 SQL Server 实例和数据库数据文件
  • 16 个磁盘作为 RAID 10 镜像条带
  • 总容量 2231 GB
• 日志卷
  • 包含数据库日志文件
  • 8 个磁盘作为 RAID 10 镜像条带
  • 总容量 1115 GB
• 软件：
  • Windows Server 2012 R2 Standard Edition，在测试时具有当前 Windows 更新（2014 年 8 月）
  • 具有累积更新 1 的 SQL Server Enterprise 2012 SP2
• 配置变更
  • SQL Server 配置为使用最多 61440 MB
  • 已在所有 SQL 实例上启用数据库遏制
  • SQL Server 代理服务已配置为自动启动
• 可用性组设置：
  • 所有服务器都放置在 Windows 故障转移群集中
  • 在群集中配置了“始终打开可用性”组
  • 辅助副本配置为“同步提交”，要求事务完成之前在两个副本上提交事务
  • 已为可用性组配置并启用只读副本路由

Delivery Controller 和 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 RAM
• HP 智能阵列 E200I Raid 卡（无电池支持缓存）
• 36 GB 或 72 GB SAS 硬盘

软件：

• Windows Server 2012 R2 Standard Edition，在测试时具有当前 Windows 更新（2014 年 8 月）
• Citrix XenDesktop 7.6