注意
本文档适用于 Ceph 的开发版本。
使用 mClock 和 WPQ 调度器的 QoS 研究
简介
mClock 调度器为使用它的每项服务提供三个控制参数。在 Ceph 中，使用 mClock 的服务例如包括客户端 I/O、后台恢复、Scrub、快照修剪和 PG 删除。这三个控制参数（如 weight、reservation 和 limit）用于根据每个服务的权重按比例分配资源，前提是该服务至少获得其预留量（reservation）且不超过其限制量（limit）。在 Ceph 中，如果已知每个 OSD 的 IOPS 容量，这些控制参数用于为每种服务类型分配 IOPS。mClock 调度器基于 dmClock 算法。有关更多详细信息，请参阅 基于 mClock 的 QoS 部分。
Ceph 对 mClock 的使用主要是实验性的，并以探索性心态进行。对于继续使用代码库或根据需要修改代码库的其他组织和个人来说，情况仍然如此。
DmClock 存在于其自己的 存储库 中。在 Ceph Pacific 版本之前，可以通过将 osd_op_queue Ceph 选项设置为 “mclock_scheduler” 来启用 mClock。可以使用 Ceph 选项为每种服务类型设置额外的 mClock 参数，例如 reservation、weight 和 limit。例如，osd_mclock_scheduler_client_[res,wgt,lim] 就是其中一个选项。有关更多详细信息，请参阅 基于 mClock 的 QoS 部分。即使设置了所有 mClock 选项，mClock 的全部功能也无法实现，原因如下：
OSD 容量（以吞吐量 (IOPS) 计）未知。
没有限制执行。换句话说，使用 mClock 的服务被允许超出其限制，导致无法实现所需的 QoS 目标。
每种服务类型的份额未分配给操作分片的数量。
为了解决上述问题，对 Ceph 代码库中的 mClock 调度器进行了改进。请参阅 mClock 配置参考。通过这些改进，mClock 的使用更加用户友好和直观。这是完善和优化 Ceph 中 mClock 使用方式的众多步骤之一。
概述
作为完善 mClock 调度器工作的一部分，进行了一项比较研究。该研究涉及使用两种调度器并行运行客户端操作和后台恢复操作的测试。收集结果并进行比较。从测试结果中比较了每种服务类型的调度器之间的以下统计数据：
外部客户端
平均吞吐量 (IOPS)，
平均和百分位数（95th、99th、99.5th）延迟，
后台恢复
平均恢复吞吐量，
每秒恢复的错放对象数
测试环境
软件配置: 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 配置文件: 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。有关详细的测试步骤，请参阅下一节。为了进行比较，使用默认的 加权优先级队列 (WPQ) 调度器执行了 3 次测试。这样做是为了建立一个可靠的平均值，以便稍后比较 mClock 调度器的结果。
在此之后，使用 mClock 调度器和不同的 mClock 配置文件（即 high_client_ops、balanced 和 high_recovery_ops）执行相同的测试，并收集结果进行比较。对于每个配置文件，测试执行 3 次，本研究报告了这些运行的平均值。
注意
对 HDD 进行了配置 bluestore WAL 和 dB 以及未配置 bluestore WAL 和 dB 的测试。下面进一步讨论的图表有助于突出调度器及其配置之间的比较。
建立基准客户端吞吐量 (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) |
注意
SSD 的 bluestore_throttle_bytes 和 bluestore_throttle_deferred_bytes 确定为 256 KiB。对于 HDD，为 40MiB。上述吞吐量是通过在队列深度为 64 下运行 4 KiB 随机写入 300 秒获得的。
mClock 配置文件分配
下表显示了每个配置文件的低级 mClock 份额。对于 reservation 和 limit 等参数，份额表示为总 OSD 容量的百分比。对于 high_client_ops 配置文件，reservation 参数设置为总 OSD 容量的 50%。因此，对于 NVMe（基准 21500 IOPS）设备，为客户端操作预留了至少 10750 IOPS。一旦启用配置文件，这些分配就会在后台进行。
weight 参数是无单位的。请参阅 基于 mClock 的 QoS。
high_client_ops（默认）
与后台恢复和 Ceph 中的其他内部客户端相比，此配置文件为外部客户端操作分配了更多的预留和限制。此配置文件默认启用。
服务类型 |
预留量 |
权重 |
限制量 |
|---|---|---|---|
client |
50% |
2 |
最大值 |
后台恢复 |
25% |
1 |
100% |
后台尽力而为 |
25% |
2 |
最大值 |
balanced（平衡）
此配置文件为客户端操作和后台恢复操作分配相同的预留量。内部尽力而为客户端获得较低的预留量但非常高的限制量，以便在没有竞争服务的情况下它们可以快速完成。
服务类型 |
预留量 |
权重 |
限制量 |
|---|---|---|---|
client |
40% |
1 |
100% |
后台恢复 |
40% |
1 |
150% |
后台尽力而为 |
20% |
2 |
最大值 |
high_recovery_ops
与外部客户端和 Ceph 中的其他内部客户端相比，此配置文件为后台恢复分配了更多的预留量。例如，管理员可能会在非高峰时段暂时启用此配置文件以加快后台恢复。
服务类型 |
预留量 |
权重 |
限制量 |
|---|---|---|---|
client |
30% |
1 |
80% |
后台恢复 |
60% |
2 |
200% |
后台尽力而为 |
1（最小值） |
2 |
最大值 |
custom（自定义）
自定义配置文件允许用户完全控制 mClock 和 Ceph 配置参数。要使用此配置文件，用户必须对 Ceph 和 mClock 调度器的工作原理有深入的了解。必须手动设置不同服务类型的所有 reservation、weight 和 limit 参数以及任何 Ceph 选项。此配置文件可用于实验和探索目的，或者如果内置配置文件不满足要求。在这种情况下，必须在启用此配置文件之前执行充分的测试。
恢复测试步骤
在启动 Ceph 集群之前，根据上一节获得的基准吞吐量适当设置了以下 mClock 配置参数：
有关更多详细信息，请参阅 mClock 配置参考。
测试步骤（使用 cbt）
启动具有 4 个 OSD 的 Ceph 集群。
配置 OSD，复制因子为 3。
创建一个恢复池以填充恢复数据。
创建一个客户端池并在其中预填充一些对象。
创建恢复线程并标记一个 OSD down 并 out。
在集群处理 OSD down 事件后，恢复数据被预填充到恢复池中。对于涉及 SSD 的测试，将 100K 个 4MiB 对象预填充到恢复池中。对于涉及 HDD 的测试，将 5K 个 4MiB 对象预填充到恢复池中。
预填充阶段完成后，将 downed OSD 启动并 in。此时开始回填阶段。
回填/恢复一开始，测试就会继续在另一个线程上使用单个客户端启动客户端 I/O。
在上面的步骤 8 中，cbt 捕获与客户端延迟和带宽相关的统计数据。测试还捕获错放对象的总数和每秒恢复的错放对象数。
总而言之，上述步骤在测试期间创建了 2 个池。在一个池上触发恢复，同时在另一个池上触发客户端 I/O。测试期间捕获的统计数据如下所述。
非默认 Ceph 恢复选项
除了上面提到的非默认 bluestore 限制之外，还修改了以下一组 Ceph 恢复相关选项，用于 WPQ 和 mClock 调度器的测试。
osd_max_backfills= 1000osd_recovery_max_active= 1000
上述选项对每个 OSD 的并发本地和远程回填操作数量设置了较高的限制。在这些条件下，测试了 mClock 调度器的能力，结果如下所述。
测试结果
NVMe SSD 测试结果
客户端吞吐量比较
下图显示了调度器及其各自配置之间的平均客户端吞吐量比较。
图表中的 WPQ(def) 显示了使用 WPQ 调度器且所有其他 Ceph 配置设置都设置为默认值时获得的平均客户端吞吐量。 osd_max_backfills 的默认设置将每个 OSD 的并发本地和远程回填或恢复次数限制为 1。因此，与基准值 21500 IOPS 相比，获得的平均客户端吞吐量令人印象深刻，略高于 18000 IOPS。
然而，对于 WPQ 调度器以及 非默认 Ceph 恢复选项 部分中提到的非默认选项，情况大不相同，如图表中的 WPQ(BST) 所示。在这种情况下，获得的平均客户端吞吐量急剧下降到仅 2544 IOPS。非默认恢复选项对客户端吞吐量产生了显著影响。换句话说，恢复操作压倒了客户端操作。下面进一步的章节讨论了这些条件下的恢复速率。
使用非默认选项，使用 mClock 并启用默认配置文件 (high_client_ops) 执行相同的测试。根据配置文件分配，在恢复操作过程中，平均吞吐量为 11209 IOPS，达到了 50% (10750 IOPS) 的预留目标。这比使用 WPQ(BST) 获得的吞吐量高出 4 倍以上。
如上图所示，使用 balanced (11017 IOPS) 和 high_recovery_ops (11153 IOPS) 配置文件获得了相似的吞吐量。这清楚地表明 mClock 能够在并发回填/恢复操作进行时为客户端提供所需的 QoS。
客户端延迟比较
下图显示了调度器及其各自配置之间的平均完成延迟 (clat) 以及平均 95th、99th 和 99.5th 百分位数。
使用 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 毫秒，考虑到高数量的并发活动后台回填/恢复，这令人印象深刻。根据最大 OSD 带宽的 25% 的最小配置文件分配，mClock 将恢复速率限制在平均 80 个对象/秒或约 320 MiB/s，从而允许客户端操作达到 QoS 目标。
对于其他配置文件，如 balanced 和 high_recovery_ops，平均客户端 clat 延迟没有太大变化，保持在 5.7 - 5.8 毫秒之间，如上图所示，平均百分位数延迟有所变化。
也许更有趣的图表是上面显示的比较图表，它跟踪测试期间平均 clat 延迟的变化。该图表显示了 WPQ 和 mClock 配置文件之间平均延迟的差异。在测试的初始阶段，大约 150 秒内，WPQ 调度器和 mClock 配置文件之间的平均延迟差异非常明显且不言而喻。 high_client_ops 配置文件显示最低延迟，其次是 balanced 和 high_recovery_ops 配置文件。 WPQ(BST) 在整个测试过程中具有最高的平均延迟。
恢复统计数据比较
另一个要考虑的重要方面是恢复带宽和恢复时间如何受到 mClock 配置文件设置的影响。下图概述了每个 mClock 配置文件的恢复速率和时间，以及它们与 WPQ 调度器的不同之处。如上图所示，在所有情况下要恢复的对象总数约为 75000 个对象。
凭直觉，high_client_ops 应该对恢复操作影响最大，情况确实如此，因为它以 80 个对象/秒的速度完成恢复平均需要 966 秒。恢复带宽如预期最低，平均约为 320 MiB/s。
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 上执行恢复测试，bluestore WAL 和 dB 配置在更快的 NVMe SSD 上。测得的基准吞吐量为 340 IOPS。
客户端吞吐量和延迟比较
下图显示了 WPQ 和 mClock 及其配置文件之间的平均客户端吞吐量比较。
使用 WPQ(Def)，获得的平均客户端吞吐量约为 308 IOPS，因为并发恢复的数量非常有限。平均 clat 延迟为约 208 毫秒。
然而，对于 WPQ(BST)，由于并发恢复，客户端吞吐量受到显著影响，吞吐量为 146 IOPS，平均 clat 延迟为 433 毫秒。
使用 high_client_ops 配置文件，mClock 能够满足客户端操作的 QoS 要求，平均吞吐量为 271 IOPS，接近基准吞吐量的 80%，平均 clat 延迟为 235 毫秒。
对于 balanced 和 high_recovery_ops 配置文件，平均客户端吞吐量略微下降到分别约为 248 IOPS 和 240 IOPS。平均 clat 延迟如预期增加到分别约为 258 毫秒和 265 毫秒。
上面的 clat 延迟比较图表提供了对整个测试过程中延迟差异的更全面洞察。如 NVMe SSD 案例中所观察到的，high_client_ops 配置文件在 HDD 案例中也显示最低延迟，其次是 balanced 和 high_recovery_ops 配置文件。在测试的前 200 秒内，很容易辨别配置文件之间的差异。
恢复统计数据比较
下图比较了恢复速率和时间。如上图所示，在使用配置了 WAL 和 dB 的 HDD 的所有情况下，要恢复的对象总数约为 4000 个对象。
正如预期的那样，high_client_ops 对恢复操作影响最大，因为它以约 3 个对象/秒的速度完成恢复平均需要约 1409 秒。恢复带宽如预期最低，约为 11 MiB/s。
balanced 配置文件如预期提供了体面的折衷方案，平均带宽约为 16.5 MiB/s，以约 4 个对象/秒的速度完成恢复平均需要约 966 秒。
high_recovery_ops 配置文件是最快的，带宽约为 21 MiB/s，几乎是 high_client_ops 配置文件的两倍。平均对象恢复速率为约 5 个对象/秒，并在大约 747 秒内完成。这与 WPQ(Def) 观察到的恢复时间（647 秒，带宽为 23 MiB/s，速率为 5.8 个对象/秒）有些相似。
HDD 测试结果（未配置 WAL 和 dB）
还对未配置 bluestore WAL 和 dB 的 HDD 进行了恢复测试。测得的基准吞吐量为 315 IOPS。
这种未配置 WAL 和 dB 的配置可能很少见，但仍然进行了测试，以了解 mClock 在 OSD 容量处于较低端的非常严格的环境中表现如何。下面的章节和图表与上面介绍的非常相似，仅供参考。
客户端吞吐量和延迟比较
如下图所示，平均客户端吞吐量、延迟和百分位数如前所述进行了比较。
恢复统计数据比较
恢复速率和时间如下图所示。
主要收获和结论
mClock 能够使用配置文件为服务类型分配适当的 reservation、weight 和 limit，从而提供所需的 QoS。
通过使用每个 I/O 的成本和每字节的成本参数，mClock 可以为不同的设备类型（SSD/HDD）适当调度操作。
迄今为止的研究表明，对 mClock 调度器进行的改进取得了可喜的成果。计划对 mClock 和配置文件调整进行进一步的改进。进一步的改进还将基于在更大集群上和不同工作负载下的更广泛测试反馈。