高级概念

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 和活动会话的数量,如下所示:

用户 应用程序 类型 预期峰值大小 7.5 (MB) 预期峰值大小 7.6 (MB)
1000 50 HSD 30 31
10000 100 HSD 60 198
100000 200 HSD 330 752
1000 不适用 VDI 30 30
10000 不适用 VDI 115 121
40000 不适用 VDI 390 426

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

注意:

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

监视数据库

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

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

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

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

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

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

最长保留期

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

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

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

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

XenDesktop 7.5 监视数据库大小

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

用户 类型 1 周 (MB) 1 个月 (MB) 3 个月 (MB) 1 年 (MB)
1000 HSD 151 70 230 900
10000 HSD 2,830 600 1950 7700
100000 HSD 1500 5900 19000 76000
1000 VDI 15 55 170 670
10000 VDI 120 440 1400 5500
40000 VDI 464 1700 5400 21500

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

用户 类型 1 周 (MB) 1 个月 (MB) 3 个月 (MB) 1 年 (MB)
1000 HSD 30 100 330 1300
10000 HSD 240 925 3000 12000
100000 HSD 2400 9200 30000 119000
1000 VDI 25 85 280 1100
10000 VDI 200 750 2500 9800
40000 VDI 800 3000 9700 38600

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

XenDesktop 7.6 监视数据库大小

7.5 的主要变化是:

  • 修补程序信息
    以下数据基于每个工作程序(VDI 或 HSD)3 个修补程序
  • 应用程序使用历史记录
    这主要与 HSD 系统有关。

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

用户 类型 1 周 (MB) 1 个月 (MB) 3 个月 (MB) 1 年 (MB)
1000 HSD 151 605 1,966 7,865
10000 HSD 2,830 11,301 36,712 146,834
100000 HSD 7,194 28,585 92,758 370,841
1000 VDI 13 49 157 622
10000 VDI 117 409 1,287 5,090
40000 VDI 460 1,610 5,058 19,999

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

用户 类型 1 周 (MB) 1 个月 (MB) 3 个月 (MB) 1 年 (MB)
1000 HSD 159 635 2,063 8,251
10000 HSD 2,904 11,599 37,684 150,718
100000 HSD 7,940 31,572 102,465 409,672
1000 VDI 21 79 253 1,008
10000 VDI 191 708 2,258 8,974
40000 VDI 759 2,805 8,941 35,532

配置日志记录数据库

为配置日志记录数据库的大小提供指导要困难得多,因为根据 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 检测信号的组合。

测试 登录总增长率 (MB) 注销总增长率 (MB)
1 小时内超过 100k 1,900 1,150
超过 2 小时 10 万 1,900 1,150

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

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

监视数据库

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

测试 登录总增长率 (MB) 注销总增长率 (MB)
超过 1 小时 10 万 670 190
2 小时内有 100,000 650 220

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

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

每秒事务数

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

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

站点数据库

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

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

测试 每秒登录事务数 每秒登录写入事务数 每秒注销事务数 每秒注销写入事务数
超过 1 小时 10 万 870 310 250 100
2 小时内有 100,000 475 170 140 60

监视数据库

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

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

测试 每秒登录事务数 每秒登录写入事务数 每秒注销事务数 每秒注销写入事务数
超过 1 小时 10 万 4 2 4 2
2 小时内有 100,000 4 2 3.5 2

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
XenApp 和 XenDesktop 7.6 版至当前版本的数据库大小调整指南