Ceph Cuttlefish VS Bobtail Part 3: 128K RBD 性能
目录
简介 ¶
我惊叹于你仍然在这里！你一定是受虐狂（或者你还没有阅读 第一部分 和 第二部分 呢！）如果你还没有吓跑，那就准备好了！今天我们将研究 Ceph Kernel 和 QEMU/KVM RBD 实现在使用 fio 进行 128K IO 时表现如何。同样，我们将测试性能如何随着并发 IO 数量的增加而扩展，跨越不同的卷甚至不同的虚拟机。我们将使用我们在第二部分中使用的相同的顺序写入、随机写入、顺序读取和随机读取 IO 模式。
如往常一样，如果你想简要了解用于这些测试的硬件和软件，请点击 这里。如果你想了解测试设置，请点击 这里。
为了回顾一下，在下面的每个图像中，你将看到 6 个三维图，代表给定 IO 模式的吞吐量结果。左侧的图像显示 Bobtail 版本的测试结果，而右侧的图像显示 Cuttlefish 的测试结果。顶部的图像显示使用 1-8 个卷和每个卷 1-16 个并发 IO 时测试 Kernel RBD 的吞吐量。顶部下一组图像是针对单个客户机上的 QEMU/KVM，以及多个卷，类似于 Kernel RBD 测试。底部的图像是针对 QEMU/KVM，但每个客户机运行 1-8 个客户机，每个客户机一个卷。
128KB FIO 顺序写入 (BTRFS OSDS) ¶
好吧，一些有趣的结果一开始就出现了。就像 4K 顺序读取一样，我们看到 RBD 缓存正在显著地发挥作用。虽然我们可以获得相当不错的 Kernel RBD 性能，但它无法与 IO 被合并时获得的性能相提并论。说到这里，这应该给你一个提示，关于我们下一步在 4M IO 中会看到什么。需要注意的是，Bobtail 的吞吐量扩展有些奇怪。我们改进了 Cuttlefish 中的 RBD 缓存工作方式，并且它似乎在这里非常明显。另外请注意，多客户机测试的扩展比将多个卷添加到单个客户机更高。我们需要在其他测试中观察这一点，看看这是否是单客户端限制。
- 正在对文件系统执行 128k IO…
- 运行在虚拟块设备之上…
- 运行在虚拟机之上…
- 使用虚拟网络接口…
- 运行在软件定义的网络桥之上…
- 利用软件定义的绑定网络接口…
- 在一个单一的物理客户端上…
并且获得超过 1.4GB/s 的速度。这甚至没有包括服务器端涉及的所有软件层！现代技术难道不令人惊叹吗？
128KB FIO 顺序写入 (EXT4 OSDS) ¶
EXT4 看起来与 BTRFS 相当相似，但 Cuttlefish 的多客户机测试中扩展性不如 BTRFS。与 4K 顺序写入测试一样，我们看到增加 IO 深度确实有一定影响，但影响远不如增加卷/客户机的数量显著。
128KB FIO 顺序写入 (XFS OSDS) ¶
Cuttlefish 中的 XFS 性能与 BTRFS 保持一致，但多客户机测试中高 IO 深度和 VM 计数时性能却出现了一些奇怪的下降。这可能是随机的慢速结果，或者可能表明我们正在达到某种客户端限制（鉴于我们的客户端节点的规格和涉及的吞吐量，这是完全有可能的）。无论如何，Cuttlefish 看起来比 Bobtail 更好，因为我们改进了 XFS 的 OSD 性能，并且改进了 RBD 缓存的工作方式。
128KB FIO 随机写入 (BTRFS OSDS) ¶
转向 128K 随机写入，我们可以看到 Cuttlefish 性能远高于 Bobtail，即使对于内核 RBD 也是如此。QEMU/KVM 结果在单客户机测试中也得到了显著改善。多客户机测试可能有所改善，但在这种情况下，Bobtail 实际上表现得很好。再次，RBD 缓存似乎正在很好地允许即使是低并发级别也能饱和磁盘后端。即使我们正在执行直接 IO，缓存也发生在缓冲区缓存层之下。
128KB FIO 随机写入 (EXT4 OSDS) ¶
唉！就像 4K 结果一样，我们看到 EXT4 比 BTRFS 差得多。性能实际上会随着更多卷的增加而下降。尽管如此，我们可以看到 Cuttlefish 的性能比 Bobtail 更好，所以并非全是坏消息。显然，在没有进行任何调整的情况下，Ceph 在随机 128K 写入方面在 BTRFS 上速度更快。
128KB FIO 随机写入 (XFS OSDS) ¶
如果你只看 Bobtail 的结果，XFS 几乎和 EXT4 一样慢。Cuttlefish 的改进确实有所帮助。它仍然不如 BTRFS 快，但在 Cuttlefish 中正在变得越来越接近。在内核 rbd 和单客户机测试中，性能会随着更多卷的增加而略微下降，这有点令人担忧。如果你考虑到随机写入正在分布到更多驱动器上，因此 OSD 中可能发生较少的写入合并，这可能是有道理的。另一方面，性能似乎在多客户机测试中提高，所以可能是某种单客户端限制。
128KB FIO 顺序读取 (BTRFS OSDS) ¶
哎呀！内核 RBD 顺序读取性能看起来很棒。良好的扩展性，考虑到工作负载，合理的性能等等。QEMU/KVM 性能低得多，尤其是在单客户机的情况下。在多客户机的情况下，它很低，除非我们转到 8 个 VM 并使用 16 的 IO 深度，这时它会急剧上升！我回过头去查看了显示从每个底层 OSD 设备读取多少数据的 collectl 数据。至少初步检查似乎证实了这些结果是准确的。在 QEMU/KVM 上使用 BTRFS 进行 128k 顺序读取时，似乎正在发生一些非常奇怪的事情。一些可能值得调查的候选者是客户端和 OSD 上的 IO 调度程序在做什么，调整 read_ahead_kb 会改变什么，以及客户端文件系统调整是否会有任何影响。
128KB FIO 顺序读取 (EXT4 OSDS) ¶
EXT4 128K 顺序读取性能在内核 RBD 上看起来与 btrfs 相似，如果速度稍慢的话。在 QEMU/KVM 测试中，结果看起来稍微不那么疯狂了，但仍然存在我们在 BTRFS 中看到的奇怪扩展的提示。尽管如此，部分原因是这些结果可能看起来更“正常”，因为在多客户机测试中，Cuttlefish 吞吐量不会像 bobtail 吞吐量那样随着高并发而急剧上升。
128KB FIO 顺序读取 (XFS OSDS) ¶
哇！如果你只看 Kernel RBD，XFS 在 128K 顺序读取方面比 BTRFS 或 EXT4 慢得多。但是，它保持了相同的平滑扩展行为。如果这就是我们测试的所有内容，XFS 会看起来很糟糕。事实上，如果你回过头去查看 第一部分 中 128k 对象读取结果，你不会对 XFS 在此测试中速度最慢感到惊讶。
但是，当你查看 QEMU/KVM 结果时，另一个故事出现了。虽然 BTRFS 和 EXT4 在 QEMU/KVM 测试中显示出非常奇怪（通常很差）的扩展行为，但 XFS 似乎像在 Kernel RBD 中一样扩展。事实上，QEMU/KVM 结果比内核 RBD 结果快得多。我还没有对这里发生的事情给出特别好的解释，但至少从表面上看，如果你要使用 QEMU/KVM 进行 128K 顺序读取，XFS 似乎提供了最一致的良好结果。我们将不得不看看在调整读取提前和其他可调参数后，情况是否仍然如此。
128KB FIO 随机读取 (BTRFS OSDS) ¶
128K 随机读取肯定比顺序读取慢一些，这对于旋转磁盘来说是相当合理的。Bobtail 在内核 RBD 中显示出良好的扩展行为，但在 QEMU/KVM 中却没有。幸运的是，Cuttlefish 在各个方面都显示出更好的行为，QEMU/KVM 结果比 Kernel RBD 快约 20%。使用 QEMU/KVM，我们正在获得大约 80-85 IOPS 的每个磁盘。
128KB FIO 随机读取 (EXT4 OSDS) ¶
另一方面，EXT4 看起来相当平庸。性能与驱动器应该能够执行的性能（以及 BTRFS 的性能）相比并不是很高。扩展行为在内核 RBD 中相当简单，但在 QEMU/KVM 中看起来有些奇怪。让我们看看 XFS 是否会更好。
128KB FIO 随机读取 (XFS OSDS) ¶
XFS 在 128k 随机读取方面比 BTRFS 慢一点，但总体性能与 BTRFS 相当，并且远好于我们看到的 EXT4。扩展行为也看起来很好。多客户机测试的扩展性再次优于多卷内核 RBD 测试和单客户机 QEMU/KVM 测试。基于所有这些，如果使用 QEMU/KVM 进行 128k 读取，XFS 似乎是一个不错的选择。
结论 ¶
好吧，这真是一场激烈的测试！这次我们看到很多有趣的事情，有一些令人印象深刻的 RBD 缓存顺序写入数字，以及 bobtail（在某些情况下是 Cuttlefish）中奇怪的扩展问题！XFS 成为一个令人惊讶的整体良好选择，用于 QEMU/KVM 的 128K 读取，而 BTRFS 在使用内核 RBD 时仍然更快。然而，我认为这里的读取结果提出了更多的问题，而不是答案，我们需要更深入地研究才能真正解释它们。但是，这只能留到另一天，因为接下来我们将进行大型 4M IO 测试。我们能否像在第一部分中使用 RADOS 基准测试时那样饱和 10GbE 绑定链接？你必须等到明天第四部分才能找到答案！
更新：第四部分 已经发布！
