Ceph Cuttlefish VS Bobtail Part 1: 简介和 RADOS 基准测试

2013年7月9日 MarkNelson

目录

  1. 简介
  2. 系统设置
  3. 测试设置
  4. 4KB 结果
  5. 128KB 结果
  6. 4MB 结果
  7. 结论

简介

大家好，读者们！你们可能以为在我上次性能调优文章后，我已经彻底摆脱你们了，因为我一直保持着沉默。但事实并非如此！实际上，我们 Inktank 的每个人都非常忙碌。不幸的是，这些数据迟到了一个多月，比我预期的晚了一个月。一些像履行合同义务和睡觉这样的琐事一直碍事！但现在，亲爱的读者，我终于溜走，向你轰炸大量的新数据了（哦，我会的！）。那么我们到底要看什么呢？Cuttlefish 与 Bobtail 的性能，当然！ （我知道它快要变成 Dumpling 了。）与我们之前的文章不同，这次我们不仅仅要在本地系统上运行 RADOS 基准测试。我们有大量 RADOS 基准测试、Kernel RBD 和 QEMU/KVM 测试，我们将在几篇文章中探讨这些测试。不仅如此，我们还有一个单独的客户端节点，并且所有这些都在通过绑定 10GbE 链路完成的。这次我们把事情推向了极致！加油！

系统设置

与之前的一些文章不同，这次我们只测试磁盘的 JBOD 配置。事实上，我们用 4 个 LSI SAS9207-8i 控制器、24 个旋转磁盘和 8 个 SSD 作为日志的 Supermicro 36 驱动器底盘填满了。根据我们在 之前的测试 中看到的情况，这应该是一个高性能配置。客户端和服务器节点之间设置了一个轮询绑定的 10GbE 链路。在基本的 iperf 测试中，该链路被证明能够在两个方向上传输约 2GB/s 的数据，只要有足够的并发性即可。

OSD 节点的硬件设置

  • Chassis: Supermicro 4U 36-drive SC847A
  • Motherboard: Supermicro X9DRH-7F
  • 磁盘控制器：4 X LSI SAS9207-8i
  • CPUS: 2 X Intel XEON E5-2630L (2.0GHz, 6-core)
  • RAM: 8 X 4GB Supermicro ECC Registered DDR1333 (32GB total)
  • 磁盘：24 X 7200RPM Seagate Constellation ES 1TB 企业 SATA
  • SSD：8 X Intel 520 180GB
  • NIC: Intel X520-DA2 10GBE

客户端节点的硬件设置

  • 机箱：Supermicro 1U 4 驱动器 SC815
  • 主板：Supermicro X9SCM
  • 磁盘控制器：Intel 集成 C204
  • CPU：1 X Intel XEON E3-1220 V2 (3.1GHz，4 核)
  • 内存：4 X 2GB Hynix ECC DDR1333 (总共 8GB)
  • 磁盘：1 X 7200RPM Seagate Constellation ES 1TB 企业 SATA
  • NIC: Intel X520-DA2 10GBE

As far as software goes, these tests will use

  • OS: Ubuntu 12.04
  • 内核：来自 Ubuntu 仓库的 3.8.0-19
  • 工具：collectl 3.6.0-1
  • Ceph：0.56.4，0.61.2
  • qemu-kvm：1.0+noroms-0ubuntu14.8

测试设置

在接下来的测试中，我们将查看 Cuttlefish 和 Bobtail 在几种不同场景下的性能

  • 远程服务器 RADOS 基准测试
  • 远程服务器使用多个 Kernel RBD 卷的 fio 测试
  • 远程客户机使用多个 QEMU/KVM 卷的 fio 测试
  • 远程客户机使用多个 QEMU/KVM 客户机的 fio 测试

CFQ 用作所有设备的 IO 调度器，并使用默认的 nr_requests 和 read_ahead_kb 设置。Ceph 身份验证被禁用，并且启用了 filestore xattr 使用 omap。在每次测试之前，都会调用 sync 并在所有节点上清除缓存。Ceph 被配置为使用 1x（即无）复制，以便尽可能地强调 RBD 客户端吞吐量。

对于 RBD 测试，创建了 100GB 的卷，并使用 4096 PGs 的池格式化为 XFS 文件系统。fio 被配置为预分配每个进程 1 个 64GB 文件，以确保读取期间的行为正确。使用 Direct IO 来限制客户端页面缓存的影响，同时使用 libaio 引擎以便可以测试多个 IO 深度。

以下是每个上述测试的详细设置

  • RADOS 基准测试：客户端上运行 4 个并发的 RADOS 基准测试实例，每个实例有 32 个并发 IO。为 RADOS 基准测试的每个实例创建了一个单独的 2048 PG 池，以确保重复读取不会来自页面缓存。
  • Kernel RBD：fio 以各种方式在 1 到 8 个内核 RBD 卷上运行。未使用任何特殊参数。
  • 多卷 QEMU/KVM：fio 以各种方式在单个 QEMU/KVM 客户机上的 1 到 8 个 virtio 卷上运行。客户机配置为 4 个核心和 6GB 的内存。启用了 RBD 缓存。
  • 多客户机 QEMU/KVM：fio 以各种方式在客户端节点上运行的 1 到 8 个 QEMU/KVM 客户机上运行。每个客户机配置为 1 个核心和 768MB 的内存。启用了 RBD 缓存。

对于所有测试，使用了以下 IO 大小

  • 4KB
  • 128KB
  • 4M

RADOS 基准测试写入对象并以与写入顺序相同的顺序读取它们。使用上述 IO 大小使用各种模式测试了 fio。

  • 随机写
  • 随机读
  • 顺序写入
  • 顺序读取

对于每个排列，BTRFS、XFS 和 EXT4 都被用作基础 OSD 文件系统。不幸的是，由于运行了数千个独立的测试来生成结果，因此没有足够的时间在每次测试之间重新格式化集群。这可能会影响某些测试的性能，尤其是小 IO 测试，因为随着时间的推移可能会有更大的元数据碎片。从你的角度来看，这可能或可能不是更有效的测试。无论如何，在比较这些结果与之前文章的结果时，都应该记住这一点，因为在每个测试之间都会重建集群。

每个文件系统都有传递的 mkfs 和挂载选项

  • mkfs.btfs options: -l 16k -n 16k
  • btrfs mount options: -o noatime
  • mkfs.xfs 选项：-f -i size=2048
  • xfs 挂载选项：-o inode64,noatime
  • mkfs.ext4 选项
  • ext4 mount options: -o noatime,user_xattr

在测试期间，collectl 用于记录各种系统性能指标。

4KB RADOS BENCH RESULTS

啊，RADOS 基准测试。太好了，太简单了！或者你可能会认为！实际上，这些写入结果的原因非常复杂。它涉及日志如何写入 SSD，对象如何写入和存储在磁盘上，各种文件系统元数据层，写入重新排序以及小块数据如何合并。这绝对不像写入磁盘的顺序写入，但行为也不是完全随机的。最终，最好只是将结果视为它们所代表的：通过 RADOS 写入大量并发 4K 对象的速度。请注意，EXT4 和 XFS 在 cuttlefish 上表现更好。特别是 XFS 快了两倍多！这主要是由于将 pg 信息和 pg 日志数据移动到 leveldb 所做的努力。

首先要注意的是，在所有情况下，读取性能都优于写入性能。我怀疑这主要是因为 RADOS 基准测试以与写入顺序相同的顺序读取对象，并从服务器端预读中获得一些好处。有趣的是，EXT4 和 XFS 的读取性能略有提高。我们最好的猜测是，我们在 Cuttlefish 中对 pg 信息和 pg 日志所做的改进允许 EXT4 和 XFS 更智能地在磁盘上布局数据，这会影响读取测试。

128KB RADOS 基准测试写入结果

使用 128K 对象，我们再次看到 Cuttlefish 有一些不错的改进，但在此情况下，XFS 似乎落后于 BTRFS 和 EXT4，即使在 pg 信息和 pg 日志更改之后。出于某种原因，这似乎是 RADOS 基准测试中 XFS 的一个麻烦点。看看当我们使用 fio 测试 rbd 时是否会出现这种行为会很有趣。

读取性能几乎没有改进，这并不令人意外，因为 cuttlefish 中很少有更改会影响 OSD 处理读取的方式。在这种情况下，BTRFS 似乎严重优于 EXT4 和 XFS。

4MB RADOS 基准测试结果

现在真正的乐趣开始了！使用 RADOS 基准测试，我们只需 24 个旋转磁盘和 8 个 SSD 日志即可饱和绑定 10GbE 链路。很有可能我们甚至不需要那么多 SSD 就可以做到这一点。唯一的例外是，使用 bobtail，XFS 速度不够快，无法饱和链路，但使用 cuttlefish 中的更改，所有 3 个都可以做到。此时，我们需要 40GbE 或 Infiniband，具有本机 RDMA 或 rsocket，才能真正了解我们可以将事物推到什么程度。

好吧，4MB 读取不如 4MB 写入令人印象深刻，因为我们没有完全饱和绑定 10GbE 链路，但 1.8GB/s 也不错！XFS 性能再次随着 cuttlefish 的改进。同样，我们怀疑这是由于我们所做的更改导致磁盘上数据重新排序更好。

结论

等等，什么？什么？！这可能是迄今为止我写过的最轻的文章！但别担心，我们很快会发布更多内容！现在，请考虑一下，使用 librados 写入对象，你可以轻松饱和客户端和服务器上的绑定 10GbE 链路，只要有能力足够的硬件设置即可！通过进行一些调整（例如，用于日志的 NVRAM 卡以及用旋转磁盘填满整个底盘），我们可能会接近 40GbE 或 Infiniband 的限制。这太棒了！

另外请注意，Cuttlefish 似乎为 XFS 和 EXT4 提供了巨大的性能提升。我猜你们可能已经厌倦了查看 RADOS 基准测试数字了。明天我们将发布此调查的第二部分，我们将开始查看 RBD 的表现如何，以及我们是否可以使用 fio 达到类似的性能水平。到时再见！

更新：第二部分已经发布！