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 中，连接租赁允许建立新的连接和重新连接。 在以前的版本中，无法进行新连接和重新连接。
监控数据库
监控数据库包含有关该站点的历史信息。 导演使用此信息来显示历史信息。
其用法的特点是：
- 最大大小由配置的保留期控制，如下所示：
- 对于非白金客户，默认值为 7 天，最长期限为 7 天。
- 对于白金客户，默认值为 90 天，没有最长期限。
- 峰值大小可能需要一些时间才能达到，因为系统必须达到配置的保留期。
- 由于监控服务采用批量更新的性质，每秒的事务量很低。 很少看到每秒交易超过每秒 20 笔交易的大关。
- 一些后台交易是由监控处的定期合并调用引起的。
- 进行隔夜处理以删除配置的保留期之外的数据。
失败的影响
监控数据库的中断会阻止为站点收集数据，这意味着数据在 Director 中不可见。
配置日志数据库
配置日志数据库包含站点所有配置更改的历史日志。 此信息用于生成报告或在 Studio 中显示。
其用法的特点是：
- 最大规模很难预测，因为它取决于有多少配置活动。
- 来自 Director 的任何操作（例如会话重置）都会记录到此数据库中，因此管理员使用 Director 时可能会出现一些缓慢的增长。
- 未进行配置更改时，数据库上发生的事务最少。
- 更新期间的交易率很低，因为尽可能对更新进行批处理。
- 手动删除数据。 配置日志数据库中的数据不受任何保留政策的约束，除非管理员手动删除。
失败的影响
配置日志数据库中断的影响取决于站点配置，如下所示：
- 如果在配置日志数据库不可用时站点不允许进行更改，则无法重新配置 XenDesktop 部署。
- 如果站点允许在配置日志数据库不可用时进行更改，则可能会对 XenDesktop 部署进行未跟踪的配置更改。
临时数据库
临时数据库是由 SQL Server 提供的系统范围的数据库。 它用作已提交读取快照隔离的版本存储。 XenDesktop 7 使用此 SQL Server 功能来减少 XenDesktop 数据库中的锁争用。
版本存储的大小取决于活跃交易的数量。 但是，总的来说，它不超过几MB。
TempDB的性能确实会影响XenDesktop代理的性能，因为任何生成新数据的交易都需要TempDB空间。 但是，XenDesktop 的交易往往是短暂的，这有助于保持较小的版本存储规模。
当查询生成大型中间结果集时，也会使用临时数据库。
有关调整和配置 TempDB 的指导可在微软的产品文档中找到：
争论的主要领域集中在要使用的文件数量上。 较早版本的 SQL 服务器，例如 SQL Server 2000，比新版本需要更多的文件。 有关要使用的文件数量的更多信息，请参阅：
已提交读取的快照隔离
Citrix 建议所有 XenDesktop 7 数据库都使用已提交读取的快照隔离。 有关更多信息，请参阅 如何在 XenDesktop中启用已提交读取的快照。
调整数据库大小
数据库大小取决于许多关键因素，包括一个工作日中创建的会话和连接的数量。
会话是指在一段时间内运行的任何桌面或应用程序，可以断开连接并重新连接。
连接是指用户随时连接到会话。 断开连接会关闭连接，但不会关闭会话。 当用户重新连接时，这会创建与现有会话的新连接。
站点数据库
站点数据库的最大大小基于 VDA 和活动会话的数量，如下所示：
| 用户 | 应用程序 | 类型 | 预期峰值大小 7.5 (MB) | 预期峰值大小 7.6 (MB) |
|---|---|---|---|---|
| 1,000 | 50 | HSD | 30 | 31 |
| 10,000 | 100 | HSD | 60 | 198 |
| 100,000 | 200 | HSD | 330 | 752 |
| 1,000 | 不适用 | VDI | 30 | 30 |
| 10,000 | 不适用 | VDI | 115 | 121 |
| 40,000 | 不适用 | VDI | 390 | 426 |
每个已发布的应用程序都会向数据库添加 110 KB 以存储每个唯一的图标。
注意：
7.6 版本大小的增加是由于连接租约作为控制器之间复制的一部分存储在数据库中。
监控数据库
在这三个数据库中，随着时间的推移，监测数据库预计将增长到最大的。
它的大小取决于许多因素，包括：
- 用户数量
- 会话数
- 连接数
- 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) |
|---|---|---|---|---|---|
| 1,000 | HSD | 151 | 70 | 230 | 900 |
| 10,000 | HSD | 2,830 | 600 | 1,950 | 7,700 |
| 100,000 | HSD | 1,500 | 5,900 | 19,000 | 76,000 |
| 1,000 | VDI | 15 | 55 | 170 | 670 |
| 10,000 | VDI | 120 | 440 | 1,400 | 5,500 |
| 40,000 | VDI | 464 | 1,700 | 5,400 | 21,500 |
每位用户使用 2 个连接和 1 个会话进行估计，每周工作时间为 5 天
| 用户 | 类型 | 1 周 (MB) | 1 个月 (MB) | 3 个月 (MB) | 1 年 (MB) |
|---|---|---|---|---|---|
| 1,000 | HSD | 30 | 100 | 330 | 1,300 |
| 10,000 | HSD | 240 | 925 | 3,000 | 12,000 |
| 100,000 | HSD | 2,400 | 9,200 | 30,000 | 119,000 |
| 1,000 | VDI | 25 | 85 | 280 | 1,100 |
| 10,000 | VDI | 200 | 750 | 2500 | 9,800 |
| 40,000 | VDI | 800 | 3,000 | 9,700 | 38,600 |
请注意，由于记录负载平衡信息，HSD 会随着时间的推移生成更多数据，但最初的大小与 VDI 桌面相似。
XenDesktop 7.6 监控数据库大小
与 7.5 相比的主要变化是：
- 修补程序信息
以下数据基于每位工作人员 3 个修补程序（VDI 或 HSD） - 应用程序使用历史记录
这主要与 HSD 系统有关。
估计每位用户 1 次连接和 1 次会话，每周工作时间为 5 天
| 用户 | 类型 | 1 周 (MB) | 1 个月 (MB) | 3 个月 (MB) | 1 年 (MB) |
|---|---|---|---|---|---|
| 1,000 | HSD | 151 | 605 | 1,966 | 7,865 |
| 10,000 | HSD | 2,830 | 11,301 | 36,712 | 146,834 |
| 100,000 | HSD | 7,194 | 28,585 | 92,758 | 370,841 |
| 1,000 | VDI | 13 | 49 | 157 | 622 |
| 10,000 | VDI | 117 | 409 | 1,287 | 5,090 |
| 40,000 | VDI | 460 | 1,610 | 5,058 | 19,999 |
每位用户使用 2 个连接和 1 个会话进行估计，每周工作时间为 5 天
| 用户 | 类型 | 1 周 (MB) | 1 个月 (MB) | 3 个月 (MB) | 1 年 (MB) |
|---|---|---|---|---|---|
| 1,000 | HSD | 159 | 635 | 2,063 | 8,251 |
| 10,000 | HSD | 2,904 | 11,599 | 37,684 | 150,718 |
| 100,000 | HSD | 7,940 | 31,572 | 102,465 | 409,672 |
| 1,000 | VDI | 21 | 79 | 253 | 1,008 |
| 10,000 | VDI | 191 | 708 | 2,258 | 8,974 |
| 40,000 | VDI | 759 | 2,805 | 8,941 | 35,532 |
配置日志数据库
为配置日志数据库的规模提供指导要困难得多，因为根据 Director 的日常活动和配置的站点的大小，配置日志数据库的规模会有很大差异。
对会话或用户有影响的活动会被记录下来，包括会话注销和重置等。 被动活动，例如列出用户的会话，不是。
用于部署桌面的机制也会影响所记录数据的大小。
在不使用 MCS 的 HSD 环境中，数据库大小往往介于 30 MB 到 40 MB 之间。
对于 MCS 环境，由于记录了所有虚拟机构建数据，数据库大小很容易超过 200 MB。
在 7.6 版本中，未对配置日志数据库进行任何重大更改。
登录 10 万个 HSD 会话期间的数据库活动
在模拟 100k HSD 会话登录的可扩展性测试中，事务日志的增长是在两种登录速率下测量的，如下所示：
- 10 万用户在 1 小时内登录
- 10 万用户在 2 小时内登录
选择这些费率是为了提供示例数据点。
该环境包括：
- 2 个交付控制器
- 43 名 HSD VDA 工作人员
- 3 个 SQL 服务器，配置了数据库，保存在一个 Always On 可用性组中
本文档末尾提供了服务器配置的详细信息。
交易日志增长
使用性能监控器计数器 SQLServer: Databases — 日志文件已用大小 (KB) 监控所有数据库的事务日志增长。
站点数据库
当系统处于空闲状态时，事务日志每小时增长 3.5 MB。 这是 VDA 和经纪人服务心跳的组合。
| 测试 | 总登录增长 (MB) | 注销总增长 (MB) |
|---|---|---|
| 1 小时内获得 100k | 1,900 | 1,150 |
| 2 小时内获得 100k | 1,900 | 1,150 |
日志增长在所测量的时间段内呈线性增长。 该数据表明，每次用户登录，事务日志会增加 20 KB。 每注销一个用户，事务日志就会增加 12 KB。
因此，每个用户登录/注销周期每天的增长量为 32 KB。
监控数据库
当系统处于空闲状态时，事务日志每小时增长 30.5 MB。 这是合并存储过程和 HSD VDA 负载索引更新的组合。
| 测试 | 总登录增长 (MB) | 注销总增长 (MB) |
|---|---|---|
| 1 小时内超过 100,000 | 670 | 190 |
| 2 小时内超过 100,000 | 650 | 220 |
日志增长在所测量的时间段内呈线性增长。 该数据表明，每位用户登录事务日志都会增加 7 KB。 每注销一个用户，事务日志就会增加 2 KB。
因此，每个用户登录/注销周期每天的增长量为 9 KB。
每秒交易量
使用以下性能监视器计数器监控所有数据库的事务日志增长：
- SQLServer: 数据库 — 事务/秒
- SQLServer: 数据库 — 写入事务/秒
站点数据库
当系统处于空闲状态时，每秒有 5 个事务，其中 1 个写入事务/秒保持 VDA 和 Broker 心跳信号。
注意： 这些数字是根据给定时间段得出的估计值。 确切的负载因每秒并发启动次数而异。
| 测试 | 每秒登录交易量 | 登录每秒写入交易量 | 每秒注销交易量 | 注销每秒写入事务数 |
|---|---|---|---|---|
| 1 小时内超过 100,000 | 870 | 310 | 250 | 100 |
| 2 小时内超过 100,000 | 475 | 170 | 140 | 60 |
监控数据库
当系统空闲时，合并存储过程每分钟运行一次，并生成事务。 但是，交易水平很小。 通常，每个合并存储过程有 2—3 个事务和 1 个写入事务，并运行 3 个合并存储过程。 在活动期间，随着更多工作的开展，开销也会增加。
注意： 这些数字是根据给定时间段得出的估计值。
| 测试 | 每秒登录交易量 | 登录每秒写入交易量 | 每秒注销交易量 | 注销每秒写入事务数 |
|---|---|---|---|---|
| 1 小时内超过 100,000 | 4 | 2 | 4 | 2 |
| 2 小时内超过 100,000 | 4 | 2 | 3.5 | 2 |
CPU 使用率
用于此测试的所有 SQL 服务器均为启用了超线程的双十六核服务器。 本文档末尾提供了确切的硬件规格。
众所周知，这些服务器的容量过大，无法承受正在运行的负载。 这使我们能够确定硬件的限制和最大限度。 预计SQL CPU负载实际上可以由具有单个四核的SQL Server而不是双六核系统来处理。
在测试期间，使用性能监视器计数器监控系统 CPU 处理器–% 处理器时间–\ _总计。
主副本
而空闲时CPU的运行量为可用CPU的0-2％。 整合存储过程导致系统 CPU 在大约 1 秒内每分钟出现峰值，达到 8-10%。 预计这将根据正在处理的数据量进行扩展。
在 1 小时内有 100,000 名用户登录期间，CPU 跃升至 7%，随着环境中存在的会话和用户越来越多，CPU 呈线性增长至 11%。 请注意，合并存储过程的峰值增加了总CPU的7％，导致峰值达到CPU的18％。
注销期间，CPU 以 3.5% 的速度运行，其余 7% 的 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)
- SQLServer: 交易–版本生成速率 (KB/s)
在超过 1 小时的 100,000 次登录中，版本存储区的大小保持在 10 MB 到 30 MB 之间，随着版本的创建和清理，出现了锯齿般的效果。 注销期间，范围为 10 MB 到 21 MB。 空闲时，版本存储区的大小介于 1 MB 到 4 MB 之间。
登录期间版本生成速率在 250—500 KB 范围内；注销期间在 150—400 KB/s 之间，空闲时在 0—250 KB/s 之间。
版本清理每分钟运行一次，登录期间达到 2,500 KB/s，注销期间达到 1,750 KB/s，空闲时达到 400KB/s。
磁盘 I/O
在登录测试期间，使用以下性能计数器测量了磁盘 I/O：
- PhysicalDisk — 磁盘读取字节数/秒
- PhysicalDisk — 磁盘写入字节数/秒
- PhysicalDisk — 磁盘读取/秒
- 物理磁盘 — 磁盘写入次数/秒
发现读取 I/O 非常少，因为 SQL 服务器能够将所有数据保存在内存中，从而导致系统上的读取活动很少。
由于数据库和存储系统的布局不同，卷被拆分了，一个卷容纳所有数据文件，另一个卷容纳所有事务日志文件。
数据显示了一种很难放入表格中的模式。 通常，事务日志在 1 小时测试中的写入字节/秒为 800 KB/s，2 小时测试的写入字节/秒为 400 KB/s。 每分钟一次，当合并存储过程运行时，事务日志显示峰值达到 30 MB/s。
对合并存储过程的分析表明，有时统计数据会使查询计划变得不理想，临时表会溢出到 TempDB 中。 这会触发对 TempDB 事务日志的写入。
这种数据传输转化为 1 小时测试的每秒 300 次写入输入/输出操作数 (IOPS) 的稳定状态，2 小时测试的写入 IOPS 为 200。 合并存储过程的峰值在运行时又增加了 2—300 次写入 IOPS。 请注意，在大型环境中，合并存储过程的运行时间不到一秒钟。
检查每个数据库时，数据将从内存表同步到数据卷上的数据文件。
有关 SQL 检查点的更多信息，请参阅 http://technet.microsoft.com/enus/。
这些检查点的活动时间很短，通常小于 1 秒。
在登录期间，检查点消耗 6—7 MB/s 和 500 次写入 IOPS。 注销期间，检查点消耗 7 MB/s，介于 200—700 IOPS 之间。 这些数字会有所不同，因为站点数据库和监控数据库要检查点的数据量不同。
数据库维护
在大规模部署中，数据库维护很重要。 如果数据库维护不当，则数据库中断可能是由于数据库空间不足而发生的，例如，如果事务日志设置为自动增长并填满磁盘，或者事务日志大小固定且已满。
事务日志维护
使用 SQL Server 高可用性功能（例如 “始终开启的可用性组” 或 “数据库镜像”）时，XenDesktop 数据库将以完整事务日志记录模式运行。
通过在完整事务日志记录模式下运行，事务日志会继续增长，直到进行数据库或事务日志备份为止。
如果不监控事务日志文件，这可能会导致问题，因为默认情况下，SQL Server 会将日志文件配置为自动增长。 这会导致 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: 数据库-已用日志百分比-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 建议客户设置每晚和每周运行一次的维护计划，以维护索引。 维护计划可能只是在一周的一夜之间重新组织索引，在周末重建索引。
此建议可避免在日常操作期间重建任何大型索引对性能产生任何影响，尤其是对于大型监控数据库。
微软建议，如果索引的分散度大于30％，则对其进行重组，如果索引分散度低于30％，则进行重组。 有关更多信息，请参阅 微软文档。
重新组织索引后，还应更新统计信息。 随着数据库的增长，这一点尤其重要；否则某些统计数据可能会很差，SQL 可能会生成不太理想的 SQL 查询计划。
就节省的空间而言，下面的微软脚本是针对1.2GB的监控数据库运行的。 它改善了页面填充并释放了 300 MB 的空间。
第三方脚本
微软
微软建议使用以下脚本更新其 WSUS SQL 数据库的索引：
通过更改 “使用 SUSDB”，此脚本还可以针对 XenDesktop 数据库运行。 该脚本遵循微软的最佳实践，即重建分散程度超过 30% 的索引，并对低于 30% 的索引进行重组。 然后，它会更新数据库的统计信息。
奥拉·哈伦格伦
更多高级脚本也可从以下网址获得：
这些脚本在 SQL Server 社区中广受好评。 具体而言，索引脚本可从以下网址获得：
http://ola.hallengren.com/sql-server-index-and-statistics-maintenance.html
这些脚本可用于更精细地控制级别以重新组织或重建索引。
测试服务器配置
SQL 服务器配置
SQL 可用性组由 3 台指定相同的戴尔 R720XD 服务器组成。
系统规格：
- 2 个六核 Intel Xeon CPU E5-2630，运行频率为 2.30 GHz，启用了超线程
- 64 GB 等内存
- PERC H710P Mini 配备 1 GB 电池后备缓存
- 26 个 300 GB 10k RPM SAS 驱动器
这些磁盘被拆分为以下卷：
- 系统音量
- 包含操作系统和页面文件
- 2 个磁盘作为 RAID 1 镜像
- 总容量 278 GB
- 数据库容量
- 包含 SQL Server 实例和数据库数据文件
- 16 个磁盘作为 RAID 10 镜像条带
- 总容量 2,231 GB
- 日志量
- 包含数据库日志文件
- 8 个磁盘作为 RAID 10 镜像条带
- 总容量 1,115 GB
- 软件：
- Windows Server 2012 R2 标准版，测试时有最新的 Windows 更新（2014 年 8 月）
- 带有累积更新 1 的 SQL Server 企业版 2012 SP2
- 配置变更
- SQL Server 配置为最大使用 61,440 MB
- 所有 SQL 实例均启用了数据库封闭功能
- SQL Server 代理服务已配置为自动启动
- 可用性组设置：
- 所有服务器都放置在 Windows 故障转移群集中
- 集群内配置了 “始终开启” 可用性组
- 辅助副本被配置为同步提交，要求在事务完成之前在两个副本上提交事务
- 已为可用性组配置并启用了只读副本路由
交付控制器和 HSD 测试服务器
交付控制器和 HSD 测试服务器在相同的硬件配置上运行，使用 HP bl460c G1 刀片式服务器。 2 台服务器用于交付控制器，43 台服务器提供了模拟 HSD 工作负载。
注意： 虽然这些服务器相对较旧，但 HSD 服务器上的工作负载却很低，因为会话模拟主要集中在交付控制器上，而不是 HSD 服务器上。
系统规格：
- 2 个运行频率为 1.86 GHz 的四核 Intel Xeon L5320，不支持超线程
- 16 GB ECC 内存
- HP Smart Array E200I Raid 卡（无电池备用缓存）
- 一个 36 GB 或 72 GB 的 SAS 硬盘
软件：
- Windows Server 2012 R2 标准版，测试时有最新的 Windows 更新（2014 年 8 月）
- Citrix XenDeskto