Ceph Cuttlefish VS Bobtail Part 2: 4K RBD Performance
目录
简介 ¶
欢迎回来！如果您还没有机会阅读我们 Ceph Cuttlefish VS Bobtail 比较的 第一部分，现在是时候了。今天，我们将研究 Ceph Kernel 和 QEMU/KVM RBD 实现使用 fio 进行 4K IO 时的性能。我们将测试性能如何随着并发 IO 数量的增加而扩展，跨不同的卷，甚至不同的虚拟机。
这里有很多数据，您可能想知道为什么我们投入了如此多的精力进行所有这些测试。每种 IO 模式和 IO 大小都有助于我们更好地了解 Ceph 和 RBD 在不同情况下的性能。通过查看不同的扩展场景，我们可以确定需要什么样的并发量以及达到此平台上峰值吞吐量所需的并发量。有了这些数据，我们可以开始推测不同类型的应用程序将如何执行。
在下面的每个图像中，您将看到 6 个三维图，代表给定 IO 模式的吞吐量结果。左侧的图像显示 Bobtail 版本的测试结果，而右侧的图像显示 Cuttlefish 的测试结果。顶部的图像显示使用 1-8 个卷和每个卷 1-16 个并发 IO 时 Kernel RBD 的吞吐量。从顶部开始的下一组图像是针对单个客户机和多个卷的 QEMU/KVM，类似于 Kernel RBD 测试。底部的图像是针对 QEMU/KVM，但每个客户机运行 1-8 个客户机，每个客户机一个卷。
在继续之前，如果您想简要了解这些测试中使用的硬件和软件，请点击 此处。如果您想了解测试设置本身，请点击 此处。
4KB FIO 顺序写入 (BTRFS OSDS) ¶
糟糕！如果这些图表难以查看，您可以点击其中任何一个以（最终）查看更大的完整尺寸图像。那么我们有什么呢？嗯，首先显而易见的是，对于顺序 4K 写入，QEMU/KVM 中的 RBD 缓存正在显著发挥作用。即使我们正在执行直接 IO 并绕过客户端缓冲区缓存，RBD 缓存也更像磁盘缓存，并在可能的情况下在后台合并写入。因此，QEMU/KVM 测试在顺序 4K 写入方面明显更快。一个有趣的副作用是，它并不总是似乎随着更高的并发量线性扩展。当测试单个客户机上的多个卷时，我们达到了一个增加每个 fio 进程的并发操作数反而会降低性能而不是提高性能的临界点。当我们增加主机上的客户机数量时，性能以奇怪且出乎意料的方式扩展。事实上，kernel RBD 的结果看起来最清晰，我们看到跨卷的良好扩展以及 cuttlefish 的适度性能提升。有趣的是，kernel RBD 性能并没有随着增加的 IO 深度很好地扩展。
4KB FIO 顺序写入 (EXT4 OSDS) ¶
EXT4 性能结果似乎与 BTRFS 结果非常相似。我们看到许多相同的扩展行为和吞吐量数字，有一些小的变化。看起来使用 Cuttlefish 时，RBD 缓存行为可能略有变化，但由于结果似乎很嘈杂，因此很难判断。
4KB FIO 顺序写入 (XFS OSDS) ¶
我们还没有真正涉及的一件事是性能如何随着更多卷/客户机/IO 深度而增加。Ceph 倾向于大量的并发。并发越多，IO 越能跨所有 OSD 传播，每个 OSD 保持完全利用率就越好，就像大规模并行计算机中的线程一样。XFS 结果中没有出现任何真正的新情况，但 kernel RBD 结果确实显示了 Cuttlefish 的显著改进。这与我们使用 RADOS Bench 看到的情况相符。
4KB FIO 随机写入 (BTRFS OSDS) ¶
首先查看 kernel RBD 的结果，我们看到随着 IO 深度增加，扩展了很多。跨卷也有一些扩展，但不如顺序写入那么多。Kernel RBD 似乎达到了大约 15 MB/s 的峰值，这大约是每个 OSD 的 160 IOPS。这是这些驱动器应该能够做的上限。
继续查看 QEMU/KVM 的结果，性能似乎随着更多卷/客户机而扩展，但几乎在所有情况下都高于 Kernel RBD。它达到了大约 27 MB/s 的峰值，这大约是每个 OSD 的 288 IOPS。这肯定高于磁盘可以支持的水平，所以肯定有些事情正在发生。可能是 BTRFS 提供了一些优势，或者可能由于我们只使用总磁盘空间的一小部分进行写入（每个卷 64GB），即使对于随机写入，我们也能获得一些有益的缓存行为。日志也会为小随机写入的突发提供一些有限的优势，因为写入日志是顺序的，并且 OSD 可以在将其提交到日志后立即确认请求。可能所有或其中任何事情都可能产生影响。
4KB FIO 随机写入 (EXT4 OSDS) ¶
性能在所有方面都明显低于 BTRFS。这部分可能是由文件系统刷新器影响 BTRFS、EXT4 和 XFS 上小写入行为的方式解释的。在 Bobtail 中，我们为小于 64KB 的操作禁用了它，这在使用 XFS 和 BTRFS 时有所帮助，但 EXT4 则不然。有关这些结果的更多信息，请参阅我们的 Bobtail 性能调整文章。
除此之外，看起来在比较 Bobtail 和 Cuttlefish 时，EXT4 的小随机写入性能得到了全面提升。
4KB FIO 随机写入 (XFS OSDS) ¶
使用 XFS，Kernel RBD 4K 随机写入性能与 Bobtail 中的 EXT4 一样低，但随着 Cuttlefish 的改进甚至超过了 EXT4。它仍然不如 BTRFS 快。这可能是由于 BTRFS 在磁盘上布局数据的方式造成的。QEMU/KVM 另当别论。性能得到了显著提高，并且似乎略快于 BTRFS。这意味着高 QEMU/KVM IOPS 速率肯定是由底层文件系统行为以外的某些因素造成的。查看客户端虚拟机和底层 OSD 上的 collectl 数据，日志似乎正在正确地将 4k 数据块写入 SSD。但是，写入 OSD 磁盘的大小范围各不相同。可能我们看到的是由于 IO 调度器在将数据从日志刷新到数据磁盘时至少进行少量写入重新排序和合并造成的。
我应该指出的是，我们没有对 RBD 或 OSD 的文件系统和设备进行大量的调整，而只是调整了一些基本的文件系统选项。如果进行更多调整，这些结果可能会发生变化。当然，当我们开始直接在 SSD 上查看 OSD 时，对于高吞吐量的小随机写入工作负载，几乎肯定需要进行大量的调整。
4KB FIO 顺序读取 (BTRFS OSDS) ¶
继续进行 RBD 4K 顺序读取，看起来性能随着大量的并发量而扩展更高。我怀疑客户端和 OSD 端都预读正在帮助这里。调整客户端和服务器端的 read_ahead_kb 可能会大大提高性能，但如果增加得太多，也可能会损害随机小读取。Kernel RBD 和 QEMU/KVM RBD 吞吐量结果相似，但内核版本可能稍快。增加 IO 深度可以显著提高低值时的性能，但随着 IO 深度增加，收益似乎正在减少。再次看来，需要多个卷和/或客户机才能实现高聚合吞吐量。
4K 顺序读取在 Cuttlefish 中也似乎更快，并且扩展看起来在多客户机测试中更加平滑。
4KB FIO 顺序读取 (EXT4 OSDS) ¶
使用 EXT4 的 4K 顺序读取性能与 BTRFS 非常相似，除了 Bobtail 上的多客户机测试。在这种情况下，正在发生一些奇怪的扩展，似乎在高 IO 深度和大量客户机时，性能高于我们看到的情况。很难猜测到底发生了什么，但现在值得注意的是可能存在一些奇怪的事情。
4KB FIO 顺序读取 (XFS OSDS) ¶
没有真正的惊喜。XFS 4K 顺序读取性能看起来很平稳，并且与我们看到的 BTRFS（并且在大多数情况下与我们看到的 EXT4）非常接近。性能再次随着 IO 深度增加到 2 而扩展，但此后大部分时间保持不变。使用多个卷和/或客户机确实可以提高性能。
4KB FIO 随机读取 (BTRFS OSDS) ¶
4K 随机读取性能自然低于顺序读取结果。Bobtail 中 kernel RBD 有一些奇怪的扩展行为。Cuttlefish 大部分扩展良好，但在大 IO 深度值和并发写入大量客户机时，看起来性能有所下降。这是我们需要关注的事情，以确保我们没有遇到任何 Ceph 特定的扩展问题。
4KB FIO 随机读取 (EXT4 OSDS) ¶
EXT4 在 Bobtail 的 4K 随机读取扩展行为中也显示出一些奇怪的现象。理论上，Cuttlefish 在其中一些测试中较慢，但原因并不完全清楚。在这种情况下，可能值得运行多个测试，看看这些结果是否一致。
4KB FIO 随机读取 (XFS OSDS) ¶
XFS 可能是提供最稳定的 4K 随机读取性能的。虽然吞吐量并没有像 BTRFS 那样高，但数字看起来不错，并且在涉及多个客户机时，最高可达到每个磁盘约 85 IOPS。这相当不错，但仍有改进的空间。与 4K 随机写入一样，有各种设备和文件系统可调参数可以潜在地提高这些数字。
结论 ¶
好吧，这就是我说我们有很多数据要提供给你们的意思！那么我们学到了什么？Cuttlefish 肯定为小写入提供了显著的性能改进。我们也在 RADOS 基准测试中看到了这一点。对于小顺序写入，RBD 缓存显著提高了写入性能，但也使扩展行为变得不太可预测。在读取方面，尚不清楚 Cuttlefish 是否始终更快，但至少对于小顺序读取，通常似乎提供适度的改进。
说到 RADOS 基准测试，这些数字不能直接与第一部分的 RADOS 基准测试数字进行比较，因为 RBD 的压力方式与 RADOS 不同（4k IO 到 4MB 对象与 4k IO 到 4k 对象）。除此之外，我们预分配了所有 fio 数据，因此代表 RBD 中块的每个对象已经存在。在 RADOS 基准测试中，我们为每次写入创建一个新对象，而在 RBD 中，我们修改现有对象中的数据，该对象可能或可能没有缓存其现有元数据。话虽如此，除了 RBD 缓存产生巨大差异的顺序写入之外，我们的数字都相当接近。这可能是一种虚假的安慰，但希望表明 RBD 在这里做得相当好。因此，我们完成了对 4K RBD 性能的调查。接下来我们将用 128K IO 重复所有这些操作。明天再见！
更新：第三部分已经发布！
