Ceph - 每个 NVMe 推荐安装 1 个还是 2 个 OSD？

多年来我们遇到的最常见问题之一是用户是否应该在每个闪存驱动器上部署多个 OSD。这个问题比较复杂，因为随着Ceph的发展，这个问题的答案也在不停的变化。早在 Ceph Nautilus 时代，我们通常建议每个闪存驱动器部署2 个甚至 4 个 OSD。当时在每个闪存设备部署多个 OSD 时，特别是在使用 NVMe 驱动器时，会具有很明显的性能优势。

但在 Octopus 和 Pacific 的发布周期中，这一问题的答案也开始发生变化。社区在 OSD 和 BlueStore 代码中引入了多项性能改进，极大地提高了每个 OSD 的性能。随着Pacific 版本的发布，我们也进行了各种测试，以确定我们的建议是否应该改变。

图片

正如预期的那样，Octopus 和 Pacific 的速度明显快于 Nautilus，但与每个 NVMe 2 个 OSD 与 1 个 OSD 相比，也不再表现出一致的性能增益。一些测试仍然显示出一些增益，但其他测试则显示出轻微的损失。然而，这些测试的范围相当有限。 CPU 资源的可用性是否会改变结果？在性能或资源消耗方面还有其他优点或缺点吗？最后，自 Pacific 以来，我们不断改进 OSD 和 bluestore 代码。下面我们将进行详细验证下。

集群设置

其中 5 个节点被配置为托管 OSD，其中 5 个节点被配置为客户端节点。所有节点都位于同一台 Juniper QFX5200 交换机上，并通过单个 100GbE QSFP28 链路进行连接。使用 CBT 部署了 Ceph 并启动了 FIO 测试。英特尔系统上一个重要的操作系统级别优化是将 TuneD 配置文件设置为“延迟性能”或“网络延迟”。这主要有助于避免与 CPU C/P 状态转换相关的延迟峰值。基于 AMD Rome 的系统在这方面似乎并不那么敏感，而且我还没有确认 TuneD 实际上限制了 AMD 处理器上的 C/P 状态转换。尽管如此，对于这些测试，TuneD 配置文件仍设置为“网络延迟”。

测试设置

安装 Ceph 并配置CBT。通常，在测试 Ceph 时，通常会考虑内核数量和分配给每个 OSD 的内存。然而，在此测试中，最好考虑每个 NVMe 驱动器有多少 CPU 和内存可用。这些系统中的每一个都可以轻松支持每个 NVMe 驱动器 16GB 内存，并且每个 NVMe 最多可以扩展至 20 个 CPU 线程。为了保持正确的内存比率， osd_memory_target 在 1 OSD/NVMe 情况下设置为 16GB，在 2 OSD/NVMe 情况下设置为 8GB。 Numactl 用于控制每个 OSD 的 CPU 线程数。 OSD 被分配给两个“处理器”池，试图同时扩展物理核心和 HT 核心。为此，使用以下 bash 单行代码生成处理器到物理核心的映射：

paste <(cat /proc/cpuinfo | grep "core id") <(cat /proc/cpuinfo | grep "processor") | sed 's/[[:blank:]]/ /g'

这表明处理器 0-63 对应于物理核心，处理器 64-127 对应于 HT 核心。接下来，调用 numactl 来利用相同数量的物理处理器和 HT 处理器（在本文中，我们通常将其称为 CPU 线程）。例如，要将 OSD 分配给由 12 个物理核心和 12 个 HT 核心组成的池（总共 24 个 cpu 线程，或每个 NVMe 4 个线程），则调用 OSD：

...numactl --physcpubind=0-12,64-76 /usr/local/bin/ceph-osd

每个 NVMe 驱动器使用 2 到 20 个 CPU 线程进行测试。 FIO 配置为首先使用大量写入预填充 RBD 卷，然后分别进行 60 秒的 4MB 和 4KB IO 测试。某些后台进程（例如清理、深度清理、PG 自动缩放和 PG 平衡）被禁用。使用具有静态 16384 PG（高于通常建议的值）和 3 倍复制的 RBD 池。

4MB吞吐量

图片

图片

当开始此测试时，我们并没有预料到每个 NVMe 设备有多个 OSD 对于大型 IO 工作负载会产生显着的性能差异。对于读取，差异相当小，尽管 2 个 OSD 配置显示出相当一致的小优势。然而，对于写入，我们惊讶地发现与单个 OSD 配置相比，吞吐量出现适度下降，峰值为每个 NVMe 12 个 CPU 线程。

图片

这些是短期运行的测试，但在每个 CPU 计数样本点重新创建集群，我们看到多个样本的明显趋势。该效果可能是真实的，并且似乎与我们在 Octopus 和 Pacific 中看到的行为相匹配，其中 2 OSD/NVMe 配置中的 4MB 写入吞吐量实际上较低。

4KB随机IOPS

图片

图片

图片

借助 Nautilus，我们在 4KB 随机读取和随机写入测试中看到了 2 个 OSD/NVMe 的显着优势。在相同的硬件、相同的操作系统、相同的内核版本并运行完全相同的测试时，我们看到了 Octopus 和 Pacific 的不同行为。我们不再拥有可用于这些 Reef 测试的相同硬件或操作系统，但我们看到的行为看起来更接近我们在之前的测试平台上在 Pacific 中看到的情况。在每个 NVMe 驱动器上部署 2 个 OSD 并没有特别的 IOPS 优势，除非每个 NVMe 驱动器有 16 个或更多 CPU 线程。事实上，对于每个 NVMe 有 2-4 个 CPU 线程的部署，IOPS 会受到轻微影响。这次测试有几个直接的结论：

• 使用默认调整时，OSD 的扩展范围不会超过每个 14-16 个 CPU 线程。
• 在高 CPU 线程数下，随机读取比随机写入更能从多个 OSD 中受益。
• 在 CPU 线程数较低的情况下，每个 NVMe 运行多个 OSD 会增加一定量的额外开销。

但 IOPS 并不是唯一需要考虑的因素。延迟怎么样？那么资源消耗呢？

4KB随机延迟

图片

图片

图片

在这些测试中，我们有 50 个 fio 客户端进程运行，每个进程的 io_深度为 128。 Ceph 可以实现显着较低的平均延迟，但在这种情况下，我们使 OSD 饱和到完全受 CPU 限制的程度。在这种情况下，延迟与 IOPS 成正比。

图片

平均延迟减少遵循与我们在 IOPS 中看到的类似模式。在每个 NVMe 有 2 个 OSD 的低 CPU 线程数下，平均延迟稍差（较高），但在 CPU 线程数非常高时，平均延迟明显更好（较低）。

4KB随机99%尾部延迟

图片

图片

到目前为止，我们还没有看到强有力的证据表明，除非 CPU 线程比率非常高，否则每个 NVMe 部署多个 OSD 具有显着优势。但在一种情况下，我们仍然看到了显着的优势。在几乎所有情况下，每个 NVMe 运行多个 OSD 都能一致地减少尾部延迟。

99% Tail 延迟的改善非常显着，在某些情况下，每个 NVMe 运行 2 个 OSD 可将 99% 延迟减少一半。虽然此处未显示，但 99.9% 延迟的改进甚至更好。虽然对于每个 NVMe 运行多个 OSD 的大多数 Reef 部署可能不会表现出显着的性能优势，但它可能会表现出显着的尾部延迟优势。但是……有代价吗？

图片

4KB随机CPU使用率

图片

图片

图片

尽管通过 numactl 将 OSD 限制为仅使用一定数量的 CPU 线程，但每个 NVMe 配置 2 个 OSD 始终比每个 NVMe 1 个 OSD 的情况使用更多的 CPU。让我们进一步看看这如何转化为 CPU 效率。

图片

图片

图片

我们之前看到，两种 OSD 配置在最多 16 个 CPU 线程时表现相似。此后，每个 NVMe 配置的 2 个 OSD 继续扩展，而单个 OSD 配置则达到顶峰。我们还发现，每个 NVMe 配置 2 个 OSD 的尾部延迟显着降低。在这里，我们看到每个 CPU 线程在每个 NVMe 配置的 2 个 OSD 中更加努力地工作，以实现相同的 IOPS，尽管还有其他优势。这可能会导致更高的功耗和更多的热量产生。需要注意的是：此处报告的随机写入结果将复制因素纳入其中，以与我们去年秋天在这里发布的太平洋地区结果相匹配。虽然测试配置与去年秋天并不完全相同，但看来我们在这些 Reef 测试中实现了适度的效率改进。

4KB随机内存使用

虽然每个 NVMe 案例的 2 个 OSD 中的 CPU 使用率显着增加，但内存使用率的增加相对较小。通常，与每个 NVMe 使用 1 个 OSD 相比，会有大约 3-6% 的损失。两种配置均未使用此数据集大小的 OSD 可用的全部内存量。

图片

图片

图片

结论

之前我们看到，在 Ceph 的 Nautilus 版本和 Pacific 版本之间，每个 NVMe 使用多个 OSD 的性能优势发生了显着变化。现在 Reef 已经发布，我们进行了更广泛的分析，并注意到我们的测试系统的一些细微的优点和缺点：

其他硬件配置可能会根据 CPU、闪存或其他性能特征显示不同的缩放行为。不过，我相信这些结果应该可以概括地说明在现代 Ceph 版本中每个 NVMe 配置运行 2 个 OSD 的潜在优点和缺点。与往常一样，最好的了解方法是测试一下自己，看看您的发现是否与我们在这里看到的相符。感谢您的阅读，如果您有任何疑问或想更多地讨论 Ceph 性能，请随时与我们联系。

原文： https://ceph.io/en/news/blog/2023/reef-osds-per-nvme/