一个让ceph强大的原因就是ceph提供了一系列的可调整的选项。你可以控制ceph管道中的多少数据以及多少操作被缓存。你可以定制不同的清除策略,或者更改文件存储操作的线程数。不利的一面是,要深入研究可能有点吓人,甚至让人不知道如何下手。在Inktank我们得到了很多关于这些选项如何影响性能的问题。答案往往是视情况而定。不同的硬件和软件配置将有利于不同Ceph选项。为了让人们知道什么东西可能值得看,我们决定过一遍一些最有可能会对性能产生影响的选项。本文中,使用磁盘JBOD配置时,我们将看到不同的ceph参数。
因为Inktank是愿意支付我画网络漫画(嗨伙计们!),我看到的一切就相当于下面这幅画。
在我们继续之前,如果你不是很很熟悉ceph的配置,这是关于ceph的配置文档。 一旦你对此有所了解,你要查看的可调参数在这里: here。
我们将使用SAS2208 控制器进行这个测试。这支持JBOD,多重RAID0,单RAID0配置。不幸的是不同的控制器上的表现也不同,所以这些结果可能并不代表其他控制器。希望他们至少会提供一个初始的起点,或许想类似的配置如何执行。
硬件配置包括:
Chassis: Supermicro 4U 36-drive SC847A
Motherboard: Supermicro X9DRH-7F
Disk Controller: On-board SAS2208
CPUS: 2 X Intel XEON E5-2630L (2.0GHz, 6-core)
RAM: 8 X 4GB Supermicro ECC Registered DDR1333 (32GB total)
Disks: 8 X 7200RPM Seagate Constellation ES 1TB Enterprise SATA
NIC: Intel X520-DA2 10GBE
软件配置:
OS: Ubuntu 12.04
Kernel: 3.6.3 from Ceph’s GitBuilder archive
Tools: blktrace, collectl, perf
Ceph: Ceph “next” branch from just before the 0.56 bobtail release.
写了一个python工具来读取YAML配置文件,以及根据不同的参数设置自动生成ceph.conf配置文件。然后我们使用基准测试工具对每个配置文件进行测试。一些参数配置将被组合在一起以减少总的测试数量。以下YAML文件片段展示了不同的设置。
default: global: log_to_syslog: "false" log_file: "/var/log/ceph/$name.log" auth_cluster_required: "none" auth_service_required: "none" auth_client_required: "none" filestore_xattr_use_omap: "true" mon: mon_osd_data: "/srv/mon.$id" mon.a: host: "burnupiX" mon_addr: "127.0.0.1:6789" parametric: debugging_off: debug_lockdep: "0/0" debug_context: "0/0" debug_crush: "0/0" debug_mds: "0/0" debug_mds_balancer: "0/0" debug_mds_locker: "0/0" debug_mds_log: "0/0" debug_mds_log_expire: "0/0" debug_mds_migrator: "0/0" debug_buffer: "0/0" debug_timer: "0/0" debug_filer: "0/0" debug_objecter: "0/0" debug_rados: "0/0" debug_rbd: "0/0" debug_journaler: "0/0" debug_objectcacher: "0/0" debug_client: "0/0" debug_osd: "0/0" debug_optracker: "0/0" debug_objclass: "0/0" debug_filestore: "0/0" debug_journal: "0/0" debug_ms: "0/0" debug_mon: "0/0" debug_monc: "0/0" debug_paxos: "0/0" debug_tp: "0/0" debug_auth: "0/0" debug_finisher: "0/0" debug_heartbeatmap: "0/0" debug_perfcounter: "0/0" debug_rgw: "0/0" debug_hadoop: "0/0" debug_asok: "0/0" debug_throttle: "0/0" osd_op_threads: [1, 4, 8] osd_disk_threads: [2, 4, 8] filestore_op_threads: [1, 4, 8] flush_true: filestore_flush_min: 0 filestore_flusher: "true" flush_false: filestore_flush_min: 0 filestore_flusher: "false" journal_aio: ["true"] ms_nocrc: ["true"] big_bytes: filestore_queue_max_bytes: 1048576000 filestore_queue_committing_max_bytes: 1048576000 journal_max_write_bytes: 1048576000 journal_queue_max_bytes: 1048576000 ms_dispatch_throttle_bytes: 1048576000 objecter_infilght_op_bytes: 1048576000 big_ops: filestore_queue_max_ops: 5000 filestore_queue_committing_max_ops: 5000 journal_max_write_entries: 1000 journal_queue_max_ops: 5000 objecter_inflight_ops: 8192 small_bytes: filestore_queue_max_bytes: 10485760 filestore_queue_committing_max_bytes: 10485760 journal_max_write_bytes: 10485760 journal_queue_max_bytes: 10485760 ms_dispatch_throttle_bytes: 10485760 objecter_infilght_op_bytes: 10485760 small_ops: filestore_queue_max_ops: 50 filestore_queue_committing_max_ops: 50 journal_max_write_entries: 10 journal_queue_max_ops: 50 objecter_inflight_ops: 128
类似于以前的文章,我们运行测试直接在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分钟测试使用下面的排列:
4KB Objects, 16 Concurrent Operations (2 per rados bench instance)
4KB Objects, 256 Concurrent Operations (32 per rados bench instance)
128KB Objects, 16 Concurrent Operations (2 per rados bench instance)
128KB Objects, 256 Concurrent Operations (32 per rados bench instance)
4M Objects, 16 Concurrent Operations (2 per rados bench instance)
4M Objects, 256 Concurrent Operations (32 per rados bench instance)
对于每种组合,我们运行相同的测试分别在 BTRFS, XFS, 或者 EXT4的osd 文件系统上。每次测试都会重新格式化文件系统以及重新运行mkcephfs以确保个先前的测试碎片不会影响后面的测试结果。请记住,试图使用这些结果来判断一个ceph集群是如何执行将是一个误导。每个文件系统在不同的阶段可能运行的机制完全不同。尽管如此,每个测试重新格式化文件系统是必要的,以确保不同的测试之间比较公平。每个文件系统的格式化命令和挂载选项如下:
mkfs.btfs options: -l 16k -n 16k
btrfs mount options: -o noatime
mkfs.xfs options: -f -i size=2048
xfs mount options: -o inode64,noatime
mkfs.ext4 options:
ext4 mount options: -o noatime,user_xattr
在测试期间,collectl用于记录各种系统的性能统计数据。
好吧,希望这个图表展示是不言而喻的,但如果不是,基本上这里的想法是,我们有3个样品为每个文件系统,大量的不同的参数,我们画一个彩色圈表示性能高于或低于默认配置。可能这里最需要注意的是当 filestore flusher 显示启用的时候,BTRFS和XFS的性能变低。除此之外,看起来是授权 journal_aio_true 性能提升最为明显。
就像16个并发操作的结果一样,当启用filestore flusher 的时候BTRFS和XFS性能变低。授权 Journal AIO依然性能提升最为明显。在256个并发操作的情况下,我们可以看到,增加并发操作可以提升性能,减少并发数统一会降低性能。
在这里启用 flusher 的性能依然表现不佳,这明显地降低了XFS和EXT4文件系统的读取性能。禁用调试看起来和增加并发线程操作数一样对提升性能有帮助。
这一点上,我们非常确定,启用flusher对小IO读取性能一点帮助都没有。禁用调试看起来依然有积极作用,这可能对大量的小IO操作生产的大量消息日志处理很有帮助。有趣的是增加并发操作数似乎降低了EXT4文件系统的性能,否则我们就可以得出一个规律,越多的并发操作数,性能越高。还要注意有多少不同的参数似乎在这些结果增加XFS的性能。我有一种感觉,默认的配置对XFS文件系统来说,性能是最好配置性能和最差配置性能的平均水平。
默认情况下,filestore flusher只是支持操作大于64 k。通过显式禁用它,我们看到BTRFS不错的性能提升,但对XFS相反的效果。授权Journal AIO再次提升了性能。
在这种情况下禁用flusher给EXT4的性能提升。更有趣的是,多所有的IO大小操作都显示地禁用flusher会降低性能,尽管我们在做128k的操作。journal AIO再次提高性能,有少数增加或减少性能的其他选项。
又有一些不同的选项,可以提供一些性能改进(看似BTRFS),但最明显的影响读取性能似乎是OSD 操作线程的数量就像在4 k阅读测试中的一样。
我们再次看到“默认”配置的情况下,性能很低。在这种情况下,也许有点偏高(即很多其他事物看起来低)。已经说过,OSD OP线程的数量又似乎有一个非常明显的效果。
本文中的所有译文仅用于学习和交流目的,转载请务必注明文章译者、出处、和本文链接。 2KB翻译工作遵照 CC 协议,如果我们的工作有侵犯到您的权益,请及时联系我们。2KB项目(www.2kb.com,源码交易平台),提供担保交易、源码交易、虚拟商品、在家创业、在线创业、任务交易、网站设计、软件设计、网络兼职、站长交易、域名交易、链接买卖、网站交易、广告买卖、站长培训、建站美工等服务