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

免责声明

本文档包含指向由Citrix以外各方控制的网站的链接。思杰不对这些第三方网站的内容或使用负责，也不认可或承担任何责任。思杰向您提供这些链接只是为了方便，包含任何链接并不意味着思杰对链接网站的认可。您有责任采取预防措施，以确保您选择的任何产品都不含病毒或其他具有破坏性的物品。

概述

典型的XenDesktop 7部署包括以下三个数据库:

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

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

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

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

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

注意:所有提供的数字都是估计值。部署之间的差异是可以预料的。

HSD (Hosted Shared Desktop)和VDI (Virtual Desktop Infrastructure)的大小差异也在本文档中有所说明。混合环境需要将两种桌面类型的估计值结合起来，以生成总体数据库大小的估计值。

XenDesktop 7.6的文档更改

本文档已扩展到7.6 XenDesktop。这是为了允许对7.6中添加的功能的大小变化进行更新。影响数据库大小的三个新特性是:

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

关于表大小的信息更新如下。在7.6和7.5版本中，每秒事务数和事务日志的增长是相似的，因此没有对这些部分进行更新。

高层考虑

网站数据库

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

它的用法有以下特点:

• 当用户登录生成要跟踪的会话和连接信息时，在高峰时间达到最大大小。
• 当没有活动会话并且vda全部关闭和未注册时，达到最小大小。
• 峰值大小在48小时后达到，因为数据库存储的持久信息非常少。这是由于在Site数据库中维护了一个小的连接日志，持续了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版本中增加的大小是由于连接租约作为控制器之间复制的一部分存储在数据库中。

监控数据库

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

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

• 用户数量
• 会话数
• 连接数
• VDI或HSD工作者
• 配置的保留期

以下是若干数据点对数据库大小的估计。此数据是基于对XenDesktop进行规模测试时看到的数据的估计。这些估计被认为是现实的。

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

HSD用户按每台HSD服务器100个用户计算。

最长保留期限

最大数据保留量由license控制，具体如下:

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

保留期限可以通过使用Set-MonitorConfigurationcmdlet。

当数据超过配置的保留期后，它将从数据库中删除。

XenDesktop 7.5监控数据库大小

每周工作5天，每个用户估计有1个连接和1个会话

估计每周工作5天，每个用户有2个连接和1个会话

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

XenDesktop 7.6监控数据库大小

7.5版本的主要变化如下:

• 热修复补丁信息
  下面的数据基于每个Worker (VDI或HSD)的3个hotfix
• 应用程序使用历史
  这主要与HSD系统相关。

每周工作5天，每个用户估计有1个连接和1个会话

估计每周工作5天，每个用户有2个连接和1个会话

配置日志数据库

为配置日志数据库的大小提供指导要困难得多，因为它根据Director的日常活动和已配置站点的大小而有很大的不同。

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

用于部署桌面的机制也会影响记录数据的大小。

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

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

在7.6版本中，没有对配置日志数据库进行重大更改。

登录100k HSD会话期间的数据库活动

在可伸缩性测试期间，模拟100k HSD会话登录，在两种登录速率下测量事务日志增长，如下所示:

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

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

环境包括:

• 2发货控制器
• 43名HSD VDA工作人员
• 3个SQL server，配置了数据库，在一个Always On Availability Group中

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

事务日志增长

使用性能监视器计数器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。每次用户注销，事务日志增长2kb。

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

每秒事务数

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

• SqlServer:数据库-事务/秒
• SqlServer:数据库-写事务/秒

网站数据库

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

注意:这些数字是根据所给出的时间段作出的估计。确切的负载取决于每秒并发启动的数量。

监控数据库

当系统空闲时，整合存储过程每分钟运行一次，并生成事务。然而，交易的水平很小。一般来说，每个整合存储过程有2-3个事务和1个写事务，并且运行3个整合存储过程。在活动期间，开销随着工作的增加而增加。

注意:这些数字是根据所给出的时间段作出的估计。

CPU使用率

用于此测试的所有SQL服务器都是启用了超线程的双六核服务器。具体的硬件规格在本文档的最后给出。

众所周知，对于正在运行的负载，服务器的大小过大。这使我们能够确定硬件上的限制和最大值。预计SQL CPU负载实际上可以由具有单个四核的SQL Server处理，而不是双十六进制系统。

在测试期间，使用性能监视器计数器Processor - % Processor Time - _Total监视系统CPU。

主副本

而空闲CPU以0-2%的可用CPU运行。整合存储过程每分钟产生一次峰值，占系统CPU的15%到8% -10%。这将根据所处理的数据量进行扩展。

在1小时内10万用户登录期间，CPU跃升至7%，并随着环境中出现更多会话和用户而线性增长至11%。注意，整合存储过程峰值增加了总CPU的7%，导致峰值达到了CPU的18%。

在下线期间，CPU的运行速度为3.5%，有7%的额外CPU用于整合存储过程。总的来说，这表明需要低于20%的双六进制核来维持登录和注销率。

注意:Windows Server 2012 Scheduler倾向于只在需要时使用超线程，也就是说，在系统达到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:Transactions -版本存储大小(KB)
• SQLServer:Transactions -版本清理速率(KB/s)
• SQLServer:Transactions -版本生成速率(KB/s)

在超过1小时的100,000次登录期间，版本存储大小保持在10 MB到30 MB的范围内，随着版本的创建和清理，出现锯齿效应。在下线期间，范围为10mb ~ 21mb。空闲时，版本存储大小范围为1mb ~ 4mb。

登录时版本生成率在250-500 KB范围内;下线时150 - 400kb /s，空闲时0 - 250kb /s。

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

磁盘I / O

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

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

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

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

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

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

在1小时的测试中，该数据传输的稳定状态为300 IOPS (write Input/Output Operations Per Second)，在2小时的测试中为200 IOPS。整合存储过程的峰值在运行时又增加了2-300个写IOPS。请注意，在大型环境中，整合存储过程的运行时间不到1秒。

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

有关SQL检查点的详细信息，请参见http://technet.microsoft.com/enus/。

这些检查点的活动周期非常短，通常少于15个。

在登录期间，检查点消耗6 - 7mb /s和500写IOPS。在注销期间，检查点消耗7mb /s，范围在200 - 700iops之间。由于Site和Monitoring数据库具有不同的检查点数据量，因此这些数字有所不同。

数据库维护

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

事务日志维护

当使用SQL Server高可用性特性(例如，Always On Availability Groups或Database Mirroring)时，XenDesktop数据库以完整事务日志模式运行。

通过在完全事务日志模式下运行，事务日志将继续增长，直到采取数据库或事务日志备份。

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

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

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

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

在规模测试中，使用了固定大小的4 GB日志，并设置了一个警报，当日志文件的容量达到80%时，将日志备份到另一个文件。这样可以防止日志增长并消耗所有磁盘空间，还可以防止将磁盘空间归零并使数据库停止运行。

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

备份日志[citrixxendesktopsitedb]到磁盘= N' d:\LogBackup\CitrixXenDesktopSiteDB.bak' WITH NOFORMAT, NOINIT, COMPRESSION, NAME = N' site - transaction LOG BACKUP '， SKIP, NOREWIND, NOUNLOAD

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

SQLServer:Databases -日志使用百分比- CitrixXenDesktopSiteDB . sql

对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建议客户设置维护计划，每晚和每周运行一次，以维护索引。维护计划可能只是在工作日夜间重新组织索引，并在周末重新构建索引。

此建议避免了在日常操作中重新构建任何大型索引对性能的影响，特别是对于大型监视数据库。

微软建议，如果索引碎片的比例超过30%，就重建索引;如果索引碎片的比例小于30%，就重新组织索引。有关更多信息，请参见微软文档。

在重新组织索引之后，统计数据也应该更新。随着数据库的增长，这一点尤为重要;否则，一些统计数据可能很差，SQL可能会生成次优的SQL查询计划。

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

第三方脚本

微软

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可用性组由3台相同指定的Dell R720XD服务器组成。

系统规范:

• 2个十六进核Intel Xeon CPU E5-2630，运行在2.30 GHz，启用超线程
• 64gb ecc内存
• PERC H710P Mini配有1gb电池后备缓存
• 26个300gb 10k RPM的SAS硬盘

磁盘被划分为以下卷:

• 系统的体积
  • 包含操作系统和页面文件
  • 2个硬盘作为RAID 1镜像
  • 总容量278gb
• 数据库容量
  • 包含SQL Server实例和数据库数据文件
  • 16盘作为镜像分条的RAID 10
  • 总容量2231 GB
• 日志卷
  • 包含数据库日志文件
  • 8个硬盘作为镜像条带的RAID 10
  • 总容量1115 GB
• 软件:
  • Windows Server 2012 R2标准版，在测试时使用当前Windows更新(2014年8月)
  • SQL Server Enterprise 2012 SP2 with Cumulative Update
• 配置更改
  • SQL Server配置为最大使用61,440 MB
  • 在所有SQL实例上启用了数据库包含
  • SQL Server代理服务已配置为自动启动
• 可用性组设置:
  • 所有服务器都放置在Windows故障转移群集中
  • 在集群中配置了Always On Availability组
  • 次要副本被配置为同步提交，这要求事务在事务完成之前在两个副本上提交
  • 为可用性组配置并启用了只读复制路由

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

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

注意:虽然这些服务器相对较旧，但HSD服务器上的工作负载较低，因为会话模拟主要侧重于将负载放置在交付控制器上，而不是HSD服务器上。

系统规范:

• 2个四核英特尔至强L5320运行在1.86 GHz，不支持超线程
• 16gb ecc内存
• HP Smart Array E200I Raid卡(无电池缓存)
• 36gb或72gb SAS硬盘

软件:

• Windows Server 2012 R2标准版，在测试时使用当前Windows更新(2014年8月)
• Citrix XenDesktop 7.6