第 4 部分：RHCS 3.2 Bluestore 高级性能调查

简介 ¶

回顾：在 博客第 3 篇 中，我们介绍了 RHCS 集群的扩展性能，并观察到，在增加 60% 的额外硬件资源后，我们可以获得 95% 更高的 IOPS，这证明了 Red Hat Ceph Storage 集群的可扩展性。

这是关于 RHCS 3.2 BlueStore 在全闪存集群上运行的性能博客系列的第四篇。在本集中，我们将回顾各种 RHCS 配置的性能结果，这将帮助我们做出合理的决策，以构建一个 Red Hat Ceph Storage 配置，从而在当前实验室可用的硬件和软件下获得最佳性能。为了您的方便，这篇博客文章已被划分为多个简短的基准测试部分，请尽情阅读！！

基准测试 1：每个 NVMe 设备 4 个 OSD 与 2 个 OSD ¶

关键要点 ¶

• 使用 RHCS 3.2 BlueStore，2 个 OSD/NVMe 是理想的比例
• 4 个 OSD/NVMe 比 2 个 OSD/NVMe 配置消耗更多的 CPU 资源，并且对 IOPS 的提升递减

总结 ¶

从历史上看，对于 Ceph Filestore OSD 后端，通常建议的 OSD 数量与 NVMe 设备的比例为 4 个 OSD/NVMe。随着 Ceph OSD 子系统的最新改进，特别是随着 Bluestore OSD 后端的通用可用性，可以实现更高的每 OSD 性能，因此部署超过 2 个 OSD/NVMe 设备提供的回报递减。在本基准测试中，我们希望验证我们的假设，即 2 个 OSD/NVMe 设备是最佳配置。

图 1 表明，在 2 个 OSD/NVMe 和 4 个 OSD/NVMe 配置中，聚合 IOPS 没有变化。有趣的是，使用 2 个 OSD/NVMe 配置的 CPU 利用率更好（更低）。此外，如图 2 所示，与 4 个 OSD/NVMe 配置相比，2 个 OSD/NVMe 的平均延迟更低。因此，这验证了我们的假设，即 RHCS 3.2 BlueStore 后端需要更少的 OSD/NVMe 设备（2 个 OSD/NVMe）与需要 4 个 OSD/NVMe 的 FileStore 后端相比。

与 4 个 OSD/NVMe 相比，RHCS 3.2 Bluestore 使用 2 个 OSD/NVMe 配置可提供以下优势

• 更低的随机小写延迟。
• 更大的 Bluestore Onode 缓存/OSD。
• 更低的每个 OSD 的 CPU 使用率。
• 每个 OSD 可用的更多总内存和 vCPU，从而提高了 Ceph 集群的弹性和稳定性。
• 减少 OSD 数量减轻了对 RocksDB/WAL 设备的压力。

图 1. 2 个 OSD 与 4 个 OSD 节点 CPU 利用率

图 2. 2OSD 与 4OSD 延迟与 IOPS

基准测试 2：CPU 核心与 NVMe 比例 ¶

关键要点 ¶

• 对于全闪存集群，添加物理核心有助于提高随机写入和 70R/30W 混合工作负载的 IOPS 数量，直到受 CPU 饱和限制为止。
• 使用 RHCS 3.2 BlueStore OSD 后端，发现最佳的物理 CPU 核心与 NVMe 比例为 6:1。使用上一代 Ceph OSD 后端（FileStore），该比例为 10:1，因此 BlueStore 也显著提高了 CPU 利用率。

摘要 ¶

此测试旨在找到针对性能的最佳 CPU 物理核心与 NVMe 比例。从图 3 的结果中可以看出，对于随机写入和混合工作负载（70% 读取，30% 写入），随着 CPU 的增加，我们获得更高的 IOPS 数量。这与我们在先前使用小块的测试结果中看到的情况一致，其中限制因素是 CPU。对于随机读取，从 6 个 CPU 增加到 8 个 CPU 几乎没有收益，这也有道理，如果您回想一下 图，我们展示了随机读取 4Kb 工作负载的媒体利用率，媒体利用率约为 88%。

因此，从结果中我们可以推断，使用 RHCS 3.2 BlueStore，6 个 CPU 核心/NVMe 是各种工作负载模式的最佳比例。增加 CPU 超过 6 个提供的回报递减，并且可能无法证明所涉及的成本。值得注意的是，使用上一代 Ceph OSD 后端，即 FileStore，该比例为 10 个 CPU 核心/NVMe。因此，RHCS 3.2 与 BlueStore 不仅提供更高的性能，而且还需要更低的系统资源。

图 3. 物理核心/NVMe 比例性能

表 1. 从 4 个到 6 个到 8 个物理核心的 IOPS 百分比增加。块大小 4Kb

基准测试 3：池副本 2 与池副本 3 ¶

主要收获 ¶

• 2 倍副本池提供约 30% 更高的 IOPS 和约 50% 更低的平均和尾部延迟，与 3 倍复制的池相比
• 随机读取工作负载保持不变，无论池复制大小如何

摘要 ¶

根据 Red Hat Storage 性能团队和 Ceph 社区进行的多次测试，很明显，2 倍复制的池比 3 倍复制的池表现更好，因为使用 2 倍 Ceph OSD 必须写入更少的数据，从而提供更高的性能。但是，这个问题只有在我们需要了解 IOPS、平均延迟和尾部延迟在全闪存 Ceph 集群上 2 倍与 3 倍复制的池之间的比较时才变得相关。此测试捕捉了以上所有内容。

在图 4 中，我们可以观察到使用 3 个副本需要付出性能代价。因此，2 倍副本池提供约 30% 更高的 IOPS 和约 50% 更低的平均和尾部延迟，与 3 倍复制的池相比。但是，选择副本大小并不像听起来那么简单。必须根据底层介质选择池副本大小。闪存的 MTBF 和 MTTR 远低于 HDD 介质，通常认为如果为闪存选择 2 倍复制的池，为 HDD 介质选择 3 倍复制的池是安全的，但您的用例会有所不同，具体取决于您为存储系统设计的用途。

表 2. 副本 3 与副本 2. 块大小 4Kb

图 4. 池副本 2 与副本 3

基准测试 4：Bluestore 8GB 缓存与 Bluestore 4GB 缓存 ¶

主要收获 ¶

• 对于 RBD 用例，如果数据集适合 Onode 缓存，则可以观察到明显的性能改进。
• 使用 8Gb bluestore 缓存，我们观察到随机写入工作负载的 IOPS 提高 30%，平均延迟降低 32%。

摘要 ¶

对于 Ceph BlueStore 上的 RBD 工作负载，bluestore 缓存的大小会对性能产生重大影响。bluestore 中的 Onode 缓存是分层的。如果未缓存 Onode，它将从 DB 磁盘读取，填充到 KV 缓存中，最后填充到 Bluestore Onode 缓存中。显而易见，在 Onode 缓存中直接命中比从磁盘或 KV 缓存读取速度快得多。

当数据集中所有 Onode 都适合 BlueStore 的块缓存时，Onode 永远不会从磁盘读取，因此 Onode 永远不需要填充到 KV 缓存中。这是 RBD 的最佳场景。另一方面，最坏的情况是从磁盘读取 Onode，这会填充 rocksdb KV 缓存和 bluestore onode 缓存中的新数据，并强制推出旧的 onode，这些 onode 可能会稍后从磁盘重新读取。

因此，我们发现通过将 BlueStore 缓存大小增加到 8G，随机读写（70/30）工作负载的性能可以提高高达 30% 的 IOPS 和 50% 的降低尾部延迟。

表 3. Bluestore 8Gb 缓存与 4Gb 缓存. 块大小 4Kb

基准测试 5：将 Intel Optane P4800x 磁盘用作 WAL/RocksDB 设备 ¶

主要收获 ¶

• Intel Optane P4800x 用作 BlueStore WAL 和 RocksDB 元数据可提供高达约 10% 更高的 IOPS 和约 14% 更低的尾部延迟。
• 如果您的工作负载需要更高的吞吐量和更低的尾部延迟，Intel Optane P4800x 是一个有趣的选择，用于托管 BlueStore 元数据。

摘要 ¶

通过此测试，我们希望回答一个简单的问题“Intel Optane P4800x 用作 BlueStore 元数据设备时，是否可以提高性能？”

为了回答这个问题，进行了两次类似的测试。在第一轮中，BlueStore 元数据（rocksdb 和 WAL）分区与 BlueStore 数据分区位于同一设备（p4500）上。第二轮包括将 BlueStore 元数据（rocksdb 和 WAL）配置在 Intel Optane P4800x 设备上，并将 BlueStore 数据分区放在 P4500 上

图 6 显示了 8KB 块测试中随机读取、写入和读写模式的 IOPS、平均延迟和 P99%。如图所示，使用 Intel Optane P4800x 有助于略微提高 IOPS 并显著改善随机写入工作负载中的 P99 尾部延迟。

实现可预测的性能对于生产数据库至关重要，事实证明数据库工作负载对尾部延迟非常敏感。在测试期间，我们观察到使用 P4800x Intel Optane 驱动器可以最大限度地减少 99 百分位延迟的变化，这不仅我们观察到更低的 P99% 延迟，而且实现了可预测和一致的尾部延迟结果，这对于数据库工作负载至关重要。

图 6. 使用 Intel Optane P4800x 作为 WAL/RocksDB 设备的 Ceph 结果

接下来 ¶

继续基准测试博客系列，在下一节中，我们将解释在 RHCS BlueStore 恢复基准测试期间捕获的结果，我们将了解 RHCS 在不同的恢复场景（单个 OSD、完整节点等）中的表现。