使用 mClock 和 WPQ 调度器的 QoS 研究

2021年4月16日 sseshasa

简介 ¶

Ceph 对 mClock 的使用主要是实验性的，并且以探索性的心态进行。对于其他组织和个人来说，情况仍然如此，他们继续使用代码库或根据自己的需求对其进行修改。

DmClock 存在于其自身的仓库中。在 Ceph Pacific 版本发布之前，可以通过将 Ceph 选项 osd_op_queue 设置为“mclock_scheduler”来启用 mClock。可以使用 Ceph 选项设置其他参数，例如每个服务类型的reservation（预留）、weight（权重）和limit（限制）。例如，osd_mclock_scheduler_client_[res,wgt,lim] 就是这样一个选项。有关更多详细信息，请参阅 OSD 配置参考。即使设置了所有 mClock 选项，由于以下原因，也无法实现 mClock 的全部功能：

未知的 OSD 容量，以吞吐量（IOPS）衡量。
没有限制执行。换句话说，使用 mClock 的服务被允许超过其限制，这导致所需的 QoS 目标无法实现。
每个服务类型的份额没有在运行的碎片数量上进行分配。

为了解决上述问题，对 Ceph 代码库中的 mClock 调度器进行了改进。请参阅 mClock 配置参考。通过改进，mClock 的使用更加用户友好和直观。这是改进和优化 Ceph 中 mClock 使用方式的众多步骤之一。

概述 ¶

作为改进 mClock 调度器工作的一部分，进行了一项比较研究。该研究包括在两种调度器下并行运行客户端 ops 和后台恢复操作的测试。然后将结果汇总并进行比较。从测试结果中，比较了以下统计信息：

外部客户端
- 平均吞吐量（IOPS），
- 平均值和百分位数（95%、99%、99.5%）延迟，
后台恢复
- 平均恢复吞吐量，
- 每秒恢复的错误放置对象数量

测试环境 ¶

软件配置：CentOS 8.1.1911 Linux Kernel 4.18.0-193.6.3.el8_2.x86_64
CPU：2 x Intel® Xeon® CPU E5-2650 v3 @ 2.30GHz
nproc: 40
系统内存：64 GiB
Tuned-adm Profile：network-latency
CephVer：17.0.0-2125-g94f550a87f (94f550a87fcbda799afe9f85e40386e6d90b232e) quincy (dev)
存储:
- Intel® NVMe SSD DC P3700 Series (SSDPE2MD800G4) [4 x 800GB]
- Seagate Constellation 7200 RPM 64MB Cache SATA 6.0Gb/s HDD (ST91000640NS) [4 x 1TB]

测试方法 ¶

Ceph cbt 用于测试恢复场景。创建了一个新的恢复测试，以生成并行进行客户端 I/O 的后台恢复。为了进行比较，使用默认的Weighted Priority Queue (WPQ) 调度器执行该测试 3 次。这样做是为了建立一个可信的平均值，以便稍后与 mClock 调度器的结果进行比较。

之后，使用 mClock 调度器和不同的 mClock 配置文件（即high_client_ops、balanced 和 high_recovery_ops）执行相同的测试，并将结果汇总进行比较。对于每个配置文件，执行该测试 3 次，并在本研究中报告这些运行的平均值。

注意

使用和不使用 bluestore WAL 和 dB 的 HDD 测试均已执行。以下图表有助于展示调度器及其配置之间的比较。

建立基线客户端吞吐量（IOPS） ¶

在进行实际的恢复测试之前，通过遵循 mClock 配置参考文档中的“使用 CBT 进行基准测试步骤”部分中提到的步骤，建立了 SSD 和 HDD 的基线吞吐量。对于本研究，确定了每种设备类型的以下基线吞吐量：

设备类型	基线吞吐量（@4KiB 随机写入）
NVMe SSD	21500 IOPS (84 MiB/s)
HDD（带有 bluestore WAL 和 dB）	340 IOPS (1.33 MiB/s)
HDD（没有 bluestore WAL 和 dB）	315 IOPS (1.23 MiB/s)

表 1：不同设备类型在 4KiB 随机写入时的基线吞吐量

注意

通过在 300 秒内以 64 的队列深度运行 4 KiB 随机写入来获得上述吞吐量。

在 mClock 中考虑 I/O 成本 ¶

使用 mClock 的服务具有与之相关的成本。每种服务类型的成本可能不同。mClock 调度器在计算参数（如reservation、weight 和limit）的标签时会考虑成本。标签计算确定可以从操作队列中解队列的下一个服务类型操作的时间。通常，成本越高，操作在操作队列中停留的时间越长。

进行了一项成本建模研究，以确定 SSD 和 HDD 设备类型的每 I/O 成本和每字节成本。这些作为 Ceph 选项设置，并在 mClock 下方使用：

osd_mclock_cost_per_io_usec
osd_mclock_cost_per_io_usec_hdd
osd_mclock_cost_per_io_usec_ssd
osd_mclock_cost_per_byte_usec
osd_mclock_cost_per_byte_usec_hdd
osd_mclock_cost_per_byte_usec_ssd

有关上述每个选项设置值的更多详细信息，请参阅 mClock 配置参考。

mClock 配置文件分配 ¶

下表显示了低级 mClock 每个配置文件的份额。对于reservation 和limit 等参数，份额表示 OSD 总容量的百分比。对于high_client_ops 配置文件，reservation 参数设置为 OSD 总容量的 50%。因此，对于 NVMe（基线 21500 IOPS）设备，为客户端操作预留的最小值为 10750 IOPS。启用配置文件后，会进行这些分配。

权重参数是无单位的。请参阅 OSD 配置参考。

high_client_ops（默认） ¶

与后台恢复和其他 Ceph 内部客户端相比，此配置文件为外部客户端 ops 分配更多的预留和限制。默认情况下启用此配置文件。

服务类型	保留	权重	限制
客户端	50%	2	MAX
后台恢复	25%	1	100%
后台尽力服务	25%	1	MAX

balanced ¶

此配置文件将相等的预留分配给客户端 ops 和后台恢复 ops。内部最佳努力客户端获得较低的预留，但具有非常高的限制，以便在没有竞争服务的情况下快速完成。

服务类型	保留	权重	限制
客户端	40%	1	100%
后台恢复	40%	1	150%
后台尽力服务	20%	1	MAX

high_recovery_ops ¶

与外部客户端和 Ceph 内部的其他客户端相比，此配置文件为后台恢复分配更多的预留。例如，管理员可以在非高峰时段临时启用此配置文件以加快后台恢复速度。

服务类型	保留	权重	限制
客户端	30%	1	80%
后台恢复	60%	2	200%
后台尽力服务	1 (MIN)	1	MAX

custom ¶

自定义配置文件允许用户完全控制 mClock 和 Ceph 配置参数。要使用此配置文件，用户必须深入了解 Ceph 和 mClock 调度器的工作原理。必须手动设置不同服务类型的所有reservation、weight 和limit 参数以及任何 Ceph 选项。如果内置配置文件不满足要求，可以使用此配置文件进行实验和探索目的。在这种情况下，在启用此配置文件之前，必须进行充分的测试。

恢复测试步骤 ¶

在启动 Ceph 集群之前，根据前一节中获得的基线吞吐量，适当设置以下 mClock 配置参数：

osd_mclock_max_capacity_iops_hdd
osd_mclock_max_capacity_iops_ssd
osd_mclock_profile

测试步骤（使用 cbt） ¶

启动带有 4 个 OSD 的 Ceph 集群。
使用复制因子 3 配置 OSD。
创建一个恢复池以填充恢复数据。
创建一个客户端池并在其中预填充一些对象。
创建恢复线程并关闭一个 OSD。
在集群处理 OSD 关闭事件后，将恢复数据预填充到恢复池中。对于涉及 SSD 的测试，在恢复池中预填充 100K 个 4MiB 对象。对于涉及 HDD 的测试，在恢复池中预填充 5K 个 4MiB 对象。
完成预填充阶段后，启动并启动关闭的 OSD。此时开始回填/恢复阶段。
在回填/恢复开始后，测试继续在另一个线程上使用单个客户端在客户端池上启动客户端 I/O。
在上述步骤 8 中，cbt 捕获与客户端延迟和带宽相关的统计信息。该测试还捕获错误放置对象的总数以及每秒恢复的错误放置对象数量。

总而言之，上述步骤在测试期间创建了两个池。恢复在一个池上触发，客户端 I/O 在另一个池上触发。捕获的测试统计信息在下面讨论。

非默认 Ceph 恢复选项 ¶

除了上面已经提到的非默认 bluestore 节流之外，以下一组 Ceph 恢复相关选项已针对 WPQ 和 mClock 调度器的测试进行了修改。

osd_max_backfills = 1000
osd_recovery_max_active = 1000
osd_async_recovery_min_cost = 1

上述选项将并发本地和远程回填或恢复操作的 OSD 数量限制设置为较高值。在这些条件下，对 mClock 调度器的功能进行测试和讨论如下。

测试结果 ¶

使用 NVMe SSD 的测试结果 ¶

客户端吞吐量比较 ¶

图 1 显示了跨调度器及其各自配置的平均客户端吞吐量比较。

图 1：NVMe SSD 平均客户端吞吐量

图表中的 WPQ（def）显示了使用所有其他 Ceph 配置设置设置为默认值的情况下，使用 WPQ 调度器获得的平均客户端吞吐量。默认设置下 osd_max_backfills 限制每个 OSD 的并发本地和远程回填或恢复操作的数量为 1。因此，与基线值 21500 IOPS 相比，获得的平均客户端吞吐量令人印象深刻，仅略高于 18000 IOPS。

但是，使用 WPQ 调度器以及上述非默认选项，情况却大不相同，如图表中 WPQ（BST）所示。在这种情况下，获得的平均客户端吞吐量急剧下降到仅 2544 IOPS。非默认恢复选项对客户端吞吐量产生了重大影响。换句话说，恢复操作会压倒客户端操作。下文的章节讨论了这些条件下的恢复速率。

使用非默认选项，使用 mClock 和启用默认配置文件（high_client_ops）执行相同的测试。根据配置文件分配，在恢复操作过程中，50%（10750 IOPS）的预留目标正在实现，平均吞吐量为 11209 IOPS。这比 WPQ（BST）获得的吞吐量高出 4 倍以上。

如上图所示，获得了类似的吞吐量，balanced（11017 IOPS）和high_recovery_ops（11153 IOPS）配置文件。这清楚地表明，mClock 能够在进行多个并发回填/恢复操作时提供客户端所需的 QoS。

客户端延迟比较 ¶

图 2 显示了调度器及其各自配置的平均完成延迟 (clat) 以及平均第 95、99 和 99.5 百分位数。

图 2：平均客户端延迟和百分位数 NVMe SSD

使用 WPQ(Def) 获得的平均 clat 延迟为 3.535 毫秒。但在此情况下，并发恢复的数量受到严重限制，平均约为 97 个对象/秒或 ~388 MiB/s，这是客户端看到的低延迟的主要因素。

使用 WPQ(BST) 和非默认恢复选项时，情况大不相同，平均 clat 延迟飙升至平均近 25 毫秒，糟糕了 7 倍！这是由于大量的并发恢复，测量结果为 ~350 个对象/秒或 ~1.4 GiB/s，接近 OSD 的最大带宽。

启用 mClock 并使用默认 high_client_ops 配置后，平均 clat 延迟为 5.688 毫秒，考虑到大量的并发活动型后台回填/恢复，这非常令人印象深刻。mClock 根据最小配置分配的 OSD 最大带宽的 25% 对恢复速率进行了限制，降低到平均 80 个对象/秒或 ~320 MiB/s，从而使客户端操作能够满足 QoS 目标。

对于 balanced 和 high_recovery_ops 等其他配置，平均客户端 clat 延迟没有太大变化，保持在 5.7 - 5.8 毫秒之间，如上图所示，百分位延迟也有所变化。

图 3：Clat 延迟比较 NVMe SSD

也许更引人注目的图表是图 3 中显示的比较图表，该图表跟踪测试期间平均 clat 延迟的变化。该图表显示了 WPQ 和 mClock 配置之间的平均延迟差异。在测试的初始阶段，大约 150 秒内，WPQ 调度器和 mClock 调度器的配置之间的平均延迟差异非常明显且不言而喻。high_client_ops 配置显示最低延迟，其次是 balanced 和 high_recovery_ops 配置。WPQ(BST) 在整个测试过程中具有最高的平均延迟。

恢复统计信息比较 ¶

另一个重要的方面是 mClock 配置设置如何影响恢复带宽和恢复时间。图 4 概述了每个 mClock 配置的恢复速率和时间，以及它们与 WPQ 调度器的不同之处。在所有情况下，需要恢复的对象总数约为 75000 个，如以下图表所示。

图 4：恢复速率比较 NVMe SSD

直观地，high_client_ops 应该对恢复操作产生最大的影响，事实也如此，因为它需要平均 966 秒才能以 80 个对象/秒的速度完成恢复。正如预期的那样，恢复带宽最低，平均约为 ~320 MiB/s。

图 5：平均恢复吞吐量 NVMe SSD

balanced 配置通过为客户端和恢复操作分配相同的预留和权重，提供了一个很好的折衷方案。恢复速率曲线介于 high_recovery_ops 和 high_client_ops 曲线之间，平均带宽约为 ~480 MiB/s，并在 ~120 个对象/秒的速度下完成恢复，平均需要 ~647 秒。

high_recovery_ops 配置以牺牲其他操作为代价，提供最快的完成恢复操作的方式。与使用 high_client_ops 配置观察到的带宽相比，恢复带宽几乎是 ~635 MiB/s 的两倍。平均对象恢复速率为 ~159 个对象/秒，并在大约 488 秒内完成。

使用 HDD 的测试结果（配置了 WAL 和 dB） ¶

恢复测试是在配置了 bluestore WAL 和 dB 的 HDD 上执行的，而更快的 NVMe SSD 则用于配置 dB。测量的基线吞吐量为 340 IOPS。

客户端吞吐量和延迟比较 ¶

图 6 和 7 显示了 WPQ 和 mClock 及其配置的平均客户端吞吐量比较和延迟。

图 6：平均客户端吞吐量 HDD(WALdB)

使用 WPQ(Def)，获得的平均客户端吞吐量约为 ~308 IOPS，因为并发恢复的数量受到严重限制。平均 clat 延迟约为 ~208 毫秒。

但是对于 WPQ(BST)，由于并发恢复，客户端吞吐量受到显著影响，为 146 IOPS，平均 clat 延迟为 433 毫秒。

图 7：平均 Clat 延迟和百分位数 HDD(WALdB)

使用 high_client_ops 配置，mClock 能够满足客户端操作的 QoS 要求，平均吞吐量为 271 IOPS，几乎是基线吞吐量的 80%，平均 clat 延迟为 235 毫秒。

对于 balanced 和 high_recovery_ops 配置，平均客户端吞吐量略微下降到 ~248 IOPS 和 ~240 IOPS。正如预期的那样，平均 clat 延迟分别增加到 ~258 毫秒和 ~265 毫秒。

图 8：Clat 延迟比较 HDD(WALdB)

图 8 中的 clat 延迟比较图表提供了对测试过程中延迟差异的更全面的了解。正如 NVMe SSD 案例中观察到的那样，HDD 案例中 high_client_ops 配置也显示最低延迟，其次是 balanced 和 high_recovery_ops 配置。在测试的前 200 秒内，很容易在配置之间辨别这一点。

恢复统计信息比较 ¶

图 9 和 10 中的图表比较了恢复速率和时间。如以下图表所示，在所有使用配置了 WAL 和 dB 的 HDD 的情况下，需要恢复的对象总数约为 4000 个。

图 9：恢复速率比较 HDD(WALdB)

正如预期的那样，high_client_ops 对恢复操作的影响最大，因为它需要平均 ~1409 秒才能以 ~3 个对象/秒的速度完成恢复。正如预期的那样，恢复带宽最低，为 ~11 MiB/s。

图 10：平均恢复吞吐量 HDD(WALdB)

balanced 配置正如预期的那样，提供了一个不错的折衷方案，平均带宽为 ~16.5 MiB/s，并在 ~4 个对象/秒的速度下完成恢复，平均需要 ~966 秒。

high_recovery_ops 配置最快，带宽几乎是 high_client_ops 配置的两倍，为 ~21 MiB/s。平均对象恢复速率为 ~5 个对象/秒，并在大约 747 秒内完成。这与 WPQ(Def) 在 647 秒内以 23 MiB/s 的带宽和 5.8 个对象/秒的速度完成的恢复时间有些相似。