介绍 一个让ceph强大的原因就是ceph提供了一系列的可调整的选项。你可以控制ceph管道中的多少数据以及多少操作被缓存。你可以定制不同的清除策略，或者更改文件存储操作的线程数。不利的一面是，要深入研究可能有点吓人，甚至让人不知道如何下手。在Inktank我们得到了很多关于这些选项如何影响性能的问题。答案往往是视情况而定。不同的硬件和软件配置将有利于不同Ceph选项。为了让人们知道什么东西可能值得看,我们决定过一遍一些最有可能会对性能产生影响的选项。本文中,使用磁盘JBOD配置时，我们将看到不同的ceph参数。
因为Inktank是愿意支付我画网络漫画(嗨伙计们!)，我看到的一切就相当于下面这幅画。
在我们继续之前，如果你不是很很熟悉ceph的配置，这是关于ceph的配置文档。 一旦你对此有所了解，你要查看的可调参数在这里： here。 系统设置我们将使用SAS2208 控制器进行这个测试。这支持JBOD，多重RAID0，单RAID0配置。不幸的是不同的控制器上的表现也不同,所以这些结果可能并不代表其他控制器。希望他们至少会提供一个初始的起点,或许想类似的配置如何执行。 硬件配置包括:
软件配置：
测试设置写了一个python工具来读取YAML配置文件，以及根据不同的参数设置自动生成ceph.conf配置文件。然后我们使用基准测试工具对每个配置文件进行测试。一些参数配置将被组合在一起以减少总的测试数量。以下YAML文件片段展示了不同的设置。
类似于以前的文章,我们运行测试直接在SC847a使用本机t TCP套接字连接。我们在每块磁盘的起始部分设置10G的日志分区。本文章只对 SAS2208的JBOD模式进行测试，这种模式不使用主板缓存。其他模式可能在后面的文章进行测试。CFQ用作所有测试IO调度器。 我们使用的是Ceph的可靠的内置基准测试命令:“RADOS bench” 来生成结果。（我今后将写一篇用smalliobench来测试的文章）。rados bench 有一定的好处有缺点。一方面它将明确地显示不同大小的对象读写速度。但它并不显示小IO大对象执行的速度有多快。出于这个原因,这些结果并不一定反映RBD如何最终执行。 类似之前的文章，我们将执行8个并发的 RADOS bench来合并结果，以确保这不是一个瓶颈。我们让每个RADOS bench 实例分别往自己的pool写2048个pg。这样做是为了确保后面的测试实例读取到独一无二的对象，而不是之前读取的对象的缓存。您可能还注意到,我们使用的每个池的PG数量是2的整数幂个。由于Ceph的方式实现PG分裂行为,有一个2的整数幂的后卫(尤其是在低PG计数!)可以改善数据均匀分布在osd。在较大的PG计数这可能不是那么重要。 RADOS bench给你一些灵活性的运行设置，对于对象应该是多大,有多少并发,测试应该运行多久。我们已经选定了5分钟测试使用下面的排列:
对于每种组合，我们运行相同的测试分别在 BTRFS, XFS, 或者 EXT4的osd 文件系统上。每次测试都会重新格式化文件系统以及重新运行mkcephfs以确保个先前的测试碎片不会影响后面的测试结果。请记住,试图使用这些结果来判断一个ceph集群是如何执行将是一个误导。每个文件系统在不同的阶段可能运行的机制完全不同。尽管如此,每个测试重新格式化文件系统是必要的,以确保不同的测试之间比较公平。每个文件系统的格式化命令和挂载选项如下:
在测试期间,collectl用于记录各种系统的性能统计数据。 4KB RADOS BENCH 写入测试结果 |
