Quincy 中的 QoS：mClock 和 WPQ 调度器与后台操作的比较 - 第 2 部分

简介 ¶

这篇博文是《“WPQ 和 mClock 调度器与后台和恢复操作的比较 - 第一部分”》的后续博文。 本文解释了对加权优先级队列和 mClock 调度器与后台 scrub 操作进行比较的研究。 这项研究的目标是观察后台操作对客户端操作的影响，并查看我们可以调整哪些 mClock 和 Ceph 参数以实现更好的整体性能。 该研究包括并行运行后台 scrub 操作和客户端操作，并总结这些结果。

概述 ¶

本研究旨在回答以下问题

• 默认的 mClock 配置文件如何处理 scrub 操作，与 WPQ 相比如何？
• 我们可以调整哪些参数来增加或减少 scrub 所需的时间？
• 当 scrub 和客户端操作并行运行时，客户端操作会受到什么影响？
• 当 scrub、恢复和客户端操作并行运行时，客户端和恢复操作会受到什么影响？

我们针对所有 mClock 配置文件和 WPQ 运行了以下测试

• 客户端和 scrub 操作并行运行在单独的池中
• 客户端、scrub 和恢复操作并行运行在单独的池中

我们使用以下指标来比较结果

• 外部客户端
  • 平均吞吐量 (IOPS)
  • 平均和百分位延迟
• 后台 Scrub
  • 平均 scrub 吞吐量 (MiB/s)
  • Scrub 持续时间 (s)
• 后台恢复
  • 平均恢复吞吐量
  • 每秒恢复的错位对象数量

测试环境 ¶

用于测试的单个节点配置如下

• 软件配置：CentOS Stream release 8 Linux Kernel 5.9.1-1.el8.elrepo.x86_64
• CPU：2 x Intel(R) Xeon(R) Platinum 8276M CPU @ 2.20GHz
• nproc：40
• 系统内存：64 GiB
• Tuned-adm 配置文件：network-latency
• CephVer：ceph version 17.2.0-176-g6551f450487 (6551f450487afe6c3f7bdd7a7c9c891e447045ed) quincy (stable)
• 存储：Intel® NVMe SSD DC P4510 Series (SSDPE2KX080T8)

所有 Ceph 池都配置了复制因子 3。 为测试配置了该节点上的总共 4 个 OSD。

测试方法 ¶

我们使用 CBT 测试框架来运行上述测试。 我们向 CBT 添加了 2 个新测试

1. 运行 scrub 和客户端操作并行
2. 运行 scrub、恢复和客户端操作并行

这些测试首先使用 osd_op_queue 设置为 WPQ 运行，以便建立一个基准，我们可以用它来比较 mClock 测试结果。 然后，我们使用 osd_op_queue 设置为 mClock 调度器运行测试。 使用 WPQ 和 mClock 各进行了 3 次重复性运行，我们比较了这些结果的平均值以避免任何异常值。

建立基线客户端吞吐量 (IOPS) ¶

对于测试，NVMe SSD 用作 OSD 的后端设备。 设置了 OSD 到设备的 1:1 映射。 但是，在实际测试之前，通过在配置了相同 OSD 的 RBD 池上运行“fio”基准测试以及复制因子 3 来建立基线吞吐量。 对于本研究，使用基准测试建立了大约 15K IOPS (58.6 MiB/s) @ 4KiB 随机写入的平均基线客户端吞吐量。 使用 这些步骤确定了 bluestore 节流参数，即 bluestore_throttle_bytes 和 bluestore_throttle_deferred_bytes 为 2 MiB（请注意，使用了“fio”工具而不是 OSD 基准测试）。

OSD 容量确定是通过 自动化过程完成的。 这代表了单个 OSD 的原始容量，通常较高。 这被 mClock 配置文件用于计算 OSD 中每个服务级别（例如，客户端、恢复和其他后台操作）的 QoS 分配。

mClock 配置参数 ¶

对于测试，我们使用了 mClock 内置配置文件。 有关这些配置文件的详细信息，请参见 mClock 内置配置文件部分。 我们还在某些部分试验了 mClock 自定义配置文件，并在下面提到了该配置文件的详细信息。

其他 Ceph 配置参数 ¶

使用 mClock 时禁用了 osd_scrub_sleep 选项。

对于下面的测试，我们还将 osd_max_scrubs 修改为 5。 该选项限制了并发 scrub 的数量。 osd_max_scrubs 的默认值为 1，为了更好地了解 mClock 如何处理并发 scrub，对其进行了修改。

为了并行运行 scrub 和恢复操作，有必要将 osd_scrub_during_recovery 设置为 true。

客户端操作与后台 Scrub 操作 ¶

测试步骤 ¶

1. 启动具有 4 个 OSD 的 Ceph 集群
2. 创建一个客户端 RBD 池，复制因子为 3，并预填充一些对象到其中。
3. 创建一个具有复制因子 3 的 RADOS scrub 池
4. 使用 1000 万个 32 KiB 大小的对象预填充 scrub 池
5. 启动 scrub 池上的深度 scrub
6. 使用 fio 在 14 分钟内启动客户端池上的 I/O
7. 当客户端 I/O 和深度 scrub 运行时，测试会收集与客户端吞吐量和延迟相关的统计信息。 测试还会收集 scrub 统计信息，例如 scrub 的对象数量和 scrub 持续时间，这些信息被添加到更好的理解 scrub 进度中。

测试结果 ¶

客户端吞吐量比较 ¶

上图显示了不同 mClock 配置文件和 WPQ 之间的平均客户端吞吐量比较。 绘制的客户端吞吐量是来自并行运行 scrub 的 fio 测试获得的平均客户端吞吐量。 fio 测试的持续时间为 840 秒。 深度 scrub 完成的总时间是此持续时间的一个子集。 我们通过运行 fio（4KiB 随机写入）在客户端池上建立了大约 15k IOPS 的基线 IOPS。

该图显示，当 scrub 和客户端操作并行运行时，WPQ 客户端 IOPS 降低了 27%。 相比之下，使用 mClock 调度器的 high_client_ops 配置文件，客户端 IOPS 的下降幅度约为 24%。 这可以归因于该配置文件中为客户端操作提供的较高保留量。 观察其他 mClock 配置文件，我们看到平均客户端 IOPS 的下降幅度略大。 这些配置文件为客户端操作分配较低的保留量，并且该差异在图中可见。

这些结果有助于我们推断，mClock 配置文件提供的平均客户端吞吐量高于 WPQ。 mClock 能够在后台 scrub 操作同时运行时为客户端操作提供所需的 QoS。

客户端延迟比较 ¶

上图显示了 WPQ 调度器和 mClock 调度器配置文件的平均完成延迟 (clat) 以及平均第 95、99 和 99.5 百分位数。 总体而言，我们可以看到 mClock 配置文件比 WPQ 具有更低的平均完成延迟。 如果我们特别关注 high_client_ops 配置文件，平均完成延迟为 5.62 毫秒，比 WPQ 低约 3%。 为了更好地了解 scrub 进行中客户端延迟的样子，我们可以参考下面的图表，我们可以看到 high_client_ops 在整个测试期间的延迟低于 WPQ。

Scrub 比较 ¶

在本节中，我们将查看 scrub 在各种 mClock 配置文件和 WPQ 中的表现。 从初步测试来看，WPQ 完成深度 scrub 的速度快于任何默认 mClock 配置文件。 在深入研究可能导致这种情况的原因后，我们意识到，虽然 mClock 以类似的方式处理计划 scrub 和请求 scrub，而 WPQ 则不然。 为 计划 scrub 赋予的优先级为 5，而为 请求 scrub 赋予的优先级为 120！ 由于测试触发了请求 scrub，因此 WPQ scrub 时间与 mClock scrub 时间之间的差异很大。 为了继续使用该测试来比较计划深度 scrub，我们将 osd_requested_scrub_priority 设置为 5，这是计划 scrub 的优先级。 以下所有测试都使用此值。

上图显示了各种 mClock 配置文件和 WPQ 的深度 scrub 持续时间和平均 scrub 速率的比较。

我们观察到 WPQ 完成 scrub 所需的时间最短。 mClock high_client_ops 配置文件与 WPQ 的 scrub 时间最接近。 这可以归因于该配置文件中后台最佳努力具有最高的保留量 (25%)。 由于 balanced 配置文件为后台操作提供 20% 的保留量，因此完成 scrub 的时间比 high recovery 配置文件少，后者为后台最佳努力提供最低保留量 (1)。 这些结果与我们在上一节中看到的内容相符，即 high_client_ops 配置文件具有比 WPQ 更低的平均客户端延迟和更高的吞吐量。 为了更好地了解 scrub 在测试期间的样子，我们可以参考下面的图表。

试验 mClock 自定义配置文件 ¶

我们的下一步是调整 mClock 配置文件，使其比 WPQ 更快地完成 scrub。 该想法是提供一个选项，如果需要，可以优先处理 scrub 操作，类似于 high_recovery_ops 配置文件为恢复操作提供更高保留量的方式。 在对各种 mClock 参数进行多次修改后，我们发现了一个配置文件，该配置文件的 scrub 持续时间低于 WPQ，scrub 速率更高。 以下是修改后的参数：

下图显示了与默认 mClock 配置文件和 WPQ 相比，scrub 随时间的变化情况。

从上图可以看出，自定义配置文件比 WPQ 和 high client 配置文件更快地完成 scrub。 虽然这证明了可以调整 mClock 参数以获得所需的结果，但自定义配置文件不是客户端和恢复操作的合理配置文件选项，因为它们必须严格限制并且保留量非常低。 这促使我们探索 Ceph 中的现有 scrub 配置参数。 在下一节中，我们将研究如何调整这些参数以与 mClock 更好地配合，并在不影响客户端延迟和吞吐量的情况下实现更短的 scrub 时间。

试验 Scrub 配置参数 ¶

此实验背后的想法是找出可以调整哪些现有的 scrub 参数来更快地完成 scrub，以及它们如何影响客户端延迟和吞吐量。 为了实现更短的 scrub 持续时间，我们研究了以下 scrub 配置参数

1. osd_max_scrubs
2. osd_scrub_cost

osd_max_scrubs 控制 OSD 的同时 scrub 操作的最大数量。 默认情况下，此值为 1。 在前面的测试中，我们将其修改为 5，如前所述。 现在我们将研究修改它会产生什么影响。 osd_scrub_cost 是分配给 scrub 操作的成本。 默认情况下，此成本为 50 MiB。 使用 WPQ，具有较低成本的操作更有可能被选中。 osd_scrub_cost 的工作方式与 mClock 调度器类似。 我们将分析 scrub 成本降低到 20 MiB 的测试结果。

增加 osd max scrubs ¶

下图显示了通过将并发 scrub 数量增加到 10 获得的测试结果。 正如我们所期望的那样，总 scrub 持续时间是 osd max scrubs 为 5 时的一半。

平均吞吐量的差异可以在下面的图表中看到。

将 high client 配置文件（osd max scrubs = 10）的平均客户端延迟与 WPQ 进行比较，我们可以看到 scrub 进行期间延迟的增加。

上图中的蓝色点表示 high client 配置文件测试中 scrub 完成的时间点，osd max scrubs 设置为 10。

从上面的图表中我们可以看到，并发 scrub 数量增加对客户端吞吐量和延迟的影响。如果我们仔细观察这些数据，与 WPQ 相比，高客户端配置的客户端吞吐量降低了 6%。仅在 scrub 期间，高客户端配置的平均客户端延迟约为 7 毫秒。这比 WPQ 的平均客户端延迟（5.8 毫秒）增加了 20%。与此同时，我们看到总 scrub 持续时间减少了 44%。总而言之，这个实验证明了增加 osd_max_scrubs 以减少 scrub 持续时间是一个可行的选择，但用户应小心不要将并发 scrub 数量增加到非常高的数字，因为这会影响客户端吞吐量和延迟。

降低 scrub 成本 ¶

每个操作都与其相关的成本。如本节前面所述，操作的成本越低，它被从队列中取出并执行的可能性就越高。默认情况下，scrub 操作的成本为 50 MiB。WPQ 使用优先级和成本的组合来决定哪些操作被从队列中取出。由于此，很容易控制 scrub 等操作。例如，osd_requested_scrub_priority 为 120。这意味着当用户显式请求 scrub 而不是等待计划的 scrub 时，WPQ 能够优先处理 scrub 操作而不是客户端操作（优先级为 63）。我们正在关注成本参数，希望它也能对 mClock 产生相同的作用。

对于下面提到的所有 mClock 测试，我们将 scrub 成本降低到 20 MiB。对于 WPQ 测试，我们使用了默认的 osd_requested_scrub_priority 120。

在上面的图表中我们可以看到 mClock 配置的 scrub 持续时间缩短。这些配置的 scrub 性能看起来与 WPQ（scrub 优先级 = 120）相似。我们可以在比较测试期间的平均客户端延迟和 scrub 速率的图表中看到相同的情况，其中高恢复配置和 WPQ 的趋势相似。

虽然我们看到 mClock 配置具有更好的 scrub 性能，但让我们看看与 WPQ 相比，平均吞吐量如何变化。在下面的图表中，很明显 mClock 配置比 WPQ 具有更好的吞吐量。特别是，高客户端配置继续提供比其他配置和 WPQ 更高的吞吐量。降低 osd scrub 成本帮助 mClock 配置提供了与 WPQ 用户请求 scrub 相当的 scrub 性能。而且没有任何客户端吞吐量和延迟损失！

客户端操作与后台 Scrub & 恢复 ¶

测试步骤 ¶

1. 启动具有 4 个 OSD 的 Ceph 集群
2. 创建一个具有复制因子为 3 的客户端 RBD 池，并预填充一些对象到其中。
3. 创建一个具有复制因子为 3 的 RBD 恢复池。
4. 标记一个 OSD 离线并不可用。在集群处理 OSD 离线事件后，预填充 50K 个 4MiB 对象到恢复池中。
5. 创建一个具有复制因子 3 的 RADOS scrub 池
6. 暂时禁用恢复和回填操作。
7. 启动步骤 4 中关闭的 OSD
8. 将 scrub 池预填充 100000 个 4 MiB 大小的对象
9. 启动 scrub 池上的深度 scrub，并同时启用恢复和回填
10. 使用 fio 在客户端池上进行 9 分钟的 I/O
11. 在客户端 I/O 和深度 scrub 运行时，测试会收集与客户端吞吐量和延迟相关的统计信息。测试还会收集 scrub 统计信息，例如 scrub 对象数量和 scrub 持续时间，以及恢复统计信息。

测试结果 ¶

客户端吞吐量比较 ¶

上面的图表显示了在恢复和 scrub 同时进行时客户端吞吐量的下降。所有配置的吞吐量下降相似，它们之间的差异不显著。为了更好地理解，我们将在下一节中比较客户端延迟。

客户端延迟比较 ¶

下面的图表描述了在测试期间各种配置的平均客户端延迟如何变化。

在测试开始时，mClock 配置的客户端延迟出现跳跃。这可以归因于恢复的开始。正如我们将在下一节中看到的，与 WPQ 相比，mClock 配置的恢复速率要快得多。随着时间的推移，这个峰值会平稳下来，我们可以看到客户端延迟恢复到正常趋势——有时甚至低于 WPQ。

Scrub 和恢复比较 ¶

下面的图表显示了测试期间的 scrub 和恢复速率。在 scrub 速率比较中，mClock 配置需要一些时间才能开始 scrub，而 WPQ 可以看到 scrub 几乎立即开始。

在比较恢复速率的图表中，可以观察到几乎相反的趋势。所有 mClock 配置的已恢复对象数量开始迅速减少。WPQ 似乎启动缓慢，最终完成恢复的时间比 mClock 配置要长得多。

上述行为可以归因于

• mClock 为恢复操作保留更多的 IOPS
• Scrub 操作具有更高的成本，为 50 MiB，而恢复操作的成本为 20 MiB

结论 ¶

总而言之，在查看默认 mClock 配置如何处理 scrub 和恢复等后台操作后，我们可以说 mClock 配置尝试比 scrub 更快地完成恢复。此外，使用 mClock 自定义配置进行的实验证明，通过更高的分配，我们可以实现更快的 scrub。除了 mClock 参数之外，我们还探索了可以调整的现有 Ceph 配置参数，以使用 mClock 获得更好的 scrub 性能。mClock 调度器是 Quincy 版本的默认 osd_op_queue。请告诉我们您使用 mClock 的体验如何，感谢您的阅读！如有任何疑问，请随时联系 ceph-users@ceph.io。