我们已配置 SQL Server 基本可用性组 (BAG)，以运行在本地 Intel SSD 驱动器上运行的 SQL 数据库。我被要求将数据库移动到 SQL Server 故障转移群集实例 (FCI) 以提高 SQL Server 性能：在由软件定义存储提供支持的 HA 虚拟驱动器上运行数据库。根据我的经验，超融合 VSAN 应使读取操作增加一倍，因此 SQL IO 延迟（对于从数据库读取）应减少两倍。
因此对两个场景进行了基准测试：SQL BAG 和 SQL FCI。对于这两种情况，将 512 GB RAM 的最大服务器内存设置为 SQL Server，以排除缓存并从数据库表中执行公平读取操作。
Management Studio SQL 和 SQLQueryStress 用于测试目的。SQL 语句用于SELECT TOP (500000) ... FROM [SQL].[dbo].[table]读取前 500K 行。
SQLBAG查询结果如下：
Management Studio SQL：查询时间 = 15 秒
SQL查询压力：
线程数 = 1：查询时间 = 2 秒
线程数 = 2：查询时间 = 2 秒
线程数 = 4：查询时间 = 2 秒
线程数 = 8：查询时间 = 2 秒
线程数 = 10：查询时间 = 3 秒
线程数 = 12：查询时间 = 4 秒
SQL FCI 场景建立在运行 Windows Server 2016 的两个相同硬件节点的 Windows 故障转移群集上。存储使用基于 Intel SSD 驱动器的软件定义存储（超融合 VSAN）进行配置。因此，虚拟磁盘作为群集磁盘呈现给故障转移群集。为了测试群集磁盘，我使用了 diskspd
diskspd 结果如下：
4k 随机读取 – 76K IOPS (SSD)、153K IOPS（超融合 VSAN - 集群磁盘）
8k 随机读取 – 45K IOPS (SSD)、89K IOPS（超融合 VSAN - 集群磁盘）
正如我所料，超融合 VSAN 使存储性能翻了一番。接下来，配置 SQL FCI 以将数据库文件存储在该群集磁盘上。将数据库的另一个副本上传到服务器并执行相同的测试。
SQL FCI查询结果如下：
Management Studio SQL：查询时间 = 15 秒
SQL查询压力：
线程数 = 1：查询时间 = 9 秒
线程数 = 2：查询时间 = 8 秒
线程数 = 4：查询时间 = 9 秒
线程数 = 8：查询时间 = 8 秒
线程数 = 10：查询时间 = 10 秒
线程数 = 12：查询时间 = 12 秒
问题是：
为什么通过 Management Studio 进行基准测试的 SQL BAG 和 SQL FCI 的延迟相同？
什么可能会使 SQL FCI 数据库的延迟增加 3-4 倍？
答案1
FCI 已成历史，在新部署中请继续使用 AlwasysOn 可用性组 (AG)。这样速度更快（因为 SQL Server 知道要复制什么），并且至少基本 AG 包含在 SQL Server 标准版中。