Ceph Cuttlefish VS Bobtail Part 5: Results Summary & Conclusion
目录
RESULTS SUMMARY ¶
对于那些可能从互联网的某个角落偶然来到这里，还没有看过本系列前面文章的人来说，你可能需要回头从开头开始阅读。
如果你一路从第一部分读到这篇文章，并且仍然在阅读，我必须为你鼓掌。很少有人有足够的注意力来阅读这么多数据，并且仍然关心。甚至 Sage 在一段时间后也失去了兴趣！如果你跳过了 第二部分、第三部分和 第四部分，我不会介意的。我们在这些测试中收集了大量的信息。除非你愿意将解析性能数据作为你生活中的主要部分，否则很容易迷失其中。本文的目标是看看是否可以将这些数据提炼成更易于管理的东西，并从中得出一些有用的结论。我们不会讨论绝对的性能数字，因为我们已经有了很多。相反，我们将着眼于相对性能。
所以让我们停下来思考一下人们真正想要从所有这些数据中得到什么。我们在第二到第四部分中获得了大量关于 Bobtail 和 Cuttlefish 比较的信息，但由于我发布得太晚了，很多人已经升级到 Cuttlefish，而且 Dumpling 就在眼前。为了方便起见，让我们专注于 Cuttlefish。我们收到很多关于内核 RBD 和 QEMU/KVM 比较、是否使用 RBD 缓存以及人们应该在 OSD 上使用哪种底层文件系统的问题。这些问题的答案实际上是多方面的。例如，BTRFS 可能看起来是一个不错的选择，从性能的角度来看。然而，即使在内核的相当新版本中，BTRFS 仍然存在一些在生产部署中可能不受欢迎的错误。不过，这篇文章主要关注性能，所以我们将重点放在性能上。
首要任务是弄清楚如何提炼所有这些数据。我们真正想要的是了解哪些 RBD 实现和哪些文件系统在不同类型的 IO 中表现良好。为此，我们可以查看每种 RBD 和不同文件系统的组合如何相互比较，使用给定的 IO 模式、大小、深度和卷/客户机数量。然后，我们可以对相同 IO 模式和大小的结果进行平均，以获得我们可以直观比较的一小部分数字。现在，重要的是要注意，我们以这样一种方式进行采样，以至于在高 IO 深度和卷计数处比在低计数处（1、2、4、8、16 等）有更少的样本。起初，我倾向于对平均值进行加权以考虑这一点。经过思考后，我实际上更喜欢拥有较低并发水平的更多样本。在实际部署中，你不太可能总是拥有足够的并发量来使整个集群 100% 的时间保持繁忙。此外，在一定的并发水平下，性能会趋于稳定。如果你在高并发水平下过度采样，你会失去大量关于低并发水平下性能表现的宝贵信息。出于这些原因，我决定继续使用简单的平均值。如果你的预期是 100% 的时间让集群保持繁忙的并发量，这可能不是 100% 的代表性，但我认为它提供了一个典型的比较。让我们从 4K 操作开始。
4K RELATIVE PERFORMANCE ¶
如果你有一个高分辨率屏幕，我很抱歉，这可能几乎无法辨认。如果你点击它，你应该最终能够获得图表的完整分辨率版本。我们尝试提炼数据的努力是否有帮助？我认为是的。如果我们查看所有 IO 深度和卷计数中的性能，有什么突出的地方？首先是 QEMU/KVM 更适合写入（这在第二部分中已经很明显），并且在读取方面也几乎同样好。另一个突出的地方是 EXT4 无法很好地处理随机工作负载。BTRFS 对于随机读取来说绝对是最快的，但在 1 个客户机、多卷 QEMU/KVM 顺序写入测试中落后。基于这些观察，我认为我会说，从性能的角度来看，小尺寸 IO 的最佳选择是
所有工作负载
QEMU/KVM，BTRFS 或 XFS
仅读取密集型工作负载
内核 RBD，BTRFS，EXT4 或 XFS
128K RELATIVE PERFORMANCE ¶
从这些结果来看，很明显，对于 128K 写入，你仍然最好使用带有 RBD 缓存的 QEMU/KVM RBD 实现。读取的决定要困难得多。忽略我们在第三部分中看到的所有细节，仅仅根据这些平均值，你可能最好使用内核 RBD 和 BTRFS 或 EXT4。另一方面，XFS 是唯一一个与 QEMU/KVM 配合使用，并且表现相对较好的文件系统。如果你要使用 QEMU/KVM，XFS 似乎可以在所有 IO 模式中提供最一致的良好结果。如果你要使用内核 RBD，BTRFS 或 EXT4 可能是更好的选择。
具有中等读取的写入密集型工作负载
QEMU/KVM，XFS
具有中等写入的读取密集型工作负载
内核 RBD，BTRFS 或 EXT4
4M RELATIVE PERFORMANCE ¶
在大型 IO 大小时，故事实际上与我们在 128K IO 中看到的情况非常相似，唯一的区别是 QEMU/KVM 中缺乏 RBD 缓存并没有造成太大的影响。我认为我们可以说
具有中等读取的写入密集型工作负载
QEMU/KVM，XFS
具有中等写入的读取密集型工作负载
内核 RBD，BTRFS 或 EXT4
结论 ¶
就这样了！我认为基于所有这些，如果你使用 XFS 与 QEMU/KVM，你可能总体上处于一个相当好的状态。它并不总是最快的，但它始终保持相当好。如果你使用内核 RBD，BTRFS 和 EXT4 往往表现更好，但你也应该权衡文件系统稳定性以及潜在的长期性能下降。
现在我负责提出建议了，我确信在几周后，我发现更改预读、日志缓冲区大小或在 RBD 卷上使用不同的文件系统会改变一切。这些测试都是使用 1X 复制进行的，并且在更高的复制级别，会有更多的写入飞行，这可能仅仅由于复制流量而导致更大的并发量。现在，我认为如果你真的对 Ceph 和 RBD 的性能感兴趣，那么这些文章中组合的数据应该为你提供一个良好的基础，以便在检查你自己的设置时进行构建。在第一部分中，我们看到如果你直接针对 RADOS，你可以使绑定的 10GbE 链路达到最大值。在第二到第四部分中，我们详细了解了 RBD 在各种场景下的扩展方式，以及 Cuttlefish 相对于 Bobtail 的改进程度。最后，在第五部分中，我们证明了 XFS 总体上是 QEMU/KVM 的可行选择，而 BTRFS 或 EXT4 可能与内核 RBD 配合使用时速度更快。
我希望本系列文章对你有所帮助！如果你自己进行了任何测试，请通过 IRC 或邮件列表告诉我们。我们很乐意看看！如果你想与我们讨论硬件架构或帮助进行性能分析，我们有一个很棒的团队在我们的专业服务部门准备提供帮助。在下次与 Ceph 爱好者见面之前！
