ceph配置

文章目录
  1. 1. 1,⼀些固定配置参数
  2. 2. 2,⽹络配置参数
    1. 2.1. 参考:
  3. 3. 3,pool size配置参数
  4. 4. 4,认证配置参数
  5. 5. 5,osd down out配置参数
    1. 5.1. 参考:
  6. 6. 6,objecter配置参数
    1. 6.1. 配置建议:
  7. 7. 7,ceph rgw配置参数
    1. 7.1. 参考:
  8. 8. 8,debug配置参数
    1. 8.1. 参考:
  9. 9. 9,osd op配置参数
  10. 10. 10,osd client message配置参数
    1. 10.1. 配置建议:
  11. 11. 11,osd scrub配置参数
    1. 11.1. 配置建议:
    2. 11.2. 参考:
  12. 12. 12,osd thread timeout配置参数
  13. 13. 13,filestore merge/split配置参数
    1. 13.1. 解决办法:
    2. 13.2. 参考:
  14. 14. 14,filestore fd cache配置参数
  15. 15. 15,filestore sync配置参数
  16. 16. 16,filestore throttle配置参数
    1. 16.1. 参考:
  17. 17. 17,filestore finisher threads配置参数
  18. 18. 18,journal配置参数
  19. 19. 19,rbd cache配置参数

Posted on 2017-05-15 | In [c]{.ul} [eph]{.ul} | | 4099

[概]{.ul} [述 ]{.ul}

Ceph的配置参数很多,从⽹上也能搜索到⼀⼤批的调优参数,但这些参数为什么这么设置?设置为这样是否合理?解释的并不多

本⽂从当前我们的ceph.conf⽂件⼊⼿,解释其中的每⼀项配置,做为以后参数调优和新⼈学习的依据;

Network Configuration Reference — Ceph Documentation

1,⼀些固定配置参数

以上通常是通过ceph-deploy⽣成的,都是ceph monitor相关的参数,不⽤修改;

2,⽹络配置参数

public network:monitor与osd,client与monitor,client与osd通信的⽹络,最好配置为带宽较⾼的万兆⽹络;

cluster network:OSD之间通信的⽹络,⼀般配置为带宽较⾼的万兆⽹络;

参考:

[ttp://docs.ceph.com/docs/master/rados/configuration/network-config-ref/]{.ul}

3,pool size配置参数

这两个是创建ceph pool的时候的默认size参数,⼀般配置为3和1,3副本能⾜够保证数据的可靠性;

4,认证配置参数

以上是Ceph authentication的配置参数,默认值为开启ceph认证;

在内部使⽤的ceph集群中⼀般配置为none,即不使⽤认证,这样能适当加快ceph集群访问速度;

5,osd down out配置参数

mon_osd_down_out_interval :ceph标记⼀个osd为down and out的最⼤时间间隔mon_osd_min_down_reporters :mon标记⼀个osd为down的最⼩reporters个数(报告该osd为down的其他osd为⼀个reporter)

mon_osd_report_timeout :mon标记⼀个osd为down的最⻓等待时间

osd_heartbeat_interval :osd发送heartbeat给其他osd的间隔时间(同⼀PG之间的osd才会有

heartbeat)

osd_heartbeat_grace :osd报告其他osd为down的最⼤时间间隔,grace调⼤,也有副作⽤,如果某个osd异常退出,等待其他osd上报的时间必须为grace,在这段时间段内,这个osd负责的pg的io会hang住,所以尽量不要将grace调的太⼤。

基于实际情况合理配置上述参数,能减少或及时发现osd变为down(降低IO hang住的时间和概率), 延⻓osd变为down and out的时间(防⽌⽹络抖动造成的数据recovery);

参考:

[h]{.ul} [ttp://docs.ceph.com/docs/master/rados/configuration/mon-osd-interaction/]{.ul} [h]{.ul} [ttp://blog.wjin.org/posts/ceph-osd-heartbeat.html]{.ul}

6,objecter配置参数

osd client端objecter的throttle配置,它的配置会影响librbd,RGW端的性能;

配置建议:

调⼤这两个值

7,ceph rgw配置参数

rgw_frontends :rgw的前端配置,⼀般配置为使⽤轻量级的civetweb;prot为访问rgw的端⼝,根据实际情况配置;num_threads为civetweb的线程数;

rgw_thread_pool_size :rgw前端web的线程数,与rgw_frontends中的num_threads含义⼀致,但

num_threads 优 于 rgw_thread_pool_size 的 配 置 , 两 个 只 需 要 配 置 ⼀ 个 即 可 ; rgw_override_bucket_index_max_shards :rgw bucket index object的最⼤shards数,增⼤这个值能减少bucket index object的访问时间,但也会加⼤bucket的ls时间;

rgw_max_chunk_size :rgw最⼤chunk size,针对⼤⽂件的对象存储场景可以把这个值调⼤;

rgw_cache_lru_size :rgw的lru cache size,对于读较多的应⽤场景,调⼤这个值能加快rgw的响应速度;

rgw_bucket_default_quota_max_objects :配合该参数限制⼀个bucket的最⼤objects个数;

参考:

[h]{.ul} [ttp://docs.ceph.com/docs/jewel/install/install-ceph-gateway/]{.ul}

[h]{.ul} [ttp://ceph-users.ceph.narkive.com/mdB90g7R/rgw-increase-the-first-chunk-size]{.ul} [h]{.ul} [ttps://access.redhat.com/solutions/2122231]{.ul}

8,debug配置参数

关闭了所有的debug信息,能⼀定程度加快ceph集群速度,但也会丢失⼀些关键log,出问题的时候不好分析;

参考:

[h]{.ul} [ttp://www.10tiao.com/html/362/201609/2654062487/1.html]{.ul}

9,osd op配置参数

osd_enable_op_tracker :追踪osd op状态的配置参数,默认为true;不建议关闭,关闭后osd的slow_request,ops_in_flight,historic_ops ⽆法正常统计;

打开op tracker后,若集群iops很⾼, osd_num_op_tracker_shard 可以适当调⼤,因为每个shard都有个独⽴的mutex锁;

osd_op_threads :对应的work queue有peering_wq (osd peering请求),

recovery_gen_wq (PG recovery请求);

osd_disk_threads :对应的work queue为 remove_wq (PG remove请求);

[osd_op_num_shards]{.ul} 和osd_op_num_threads_per_shard :对应的thread pool为osd_op_tp ,work queue为op_shardedwq ;

处理的请求包括:

1.

2.

3.

调⼤osd_op_num_shards 可以增⼤osd ops的处理线程数,增⼤并发性,提升OSD性能;

10,osd client message配置参数

这个是osd端收到client messages的capacity配置,配置⼤的话能提升osd的处理能⼒,但会占⽤较多的系统内存;

配置建议:

服务器内存⾜够⼤的时候,适当增⼤这两个值

11,osd scrub配置参数

Ceph osd scrub是保证ceph数据⼀致性的机制,scrub以PG为单位,但每次scrub回获取PG lock,所以它可能会影响PG正常的IO;

Ceph后来引⼊了chunky的scrub模式,每次scrub只会选取PG的⼀部分objects,完成后释放PG lock, 并把下⼀次的PG scrub加⼊队列;这样能很好的减少PG scrub时候占⽤PG lock的时间,避免过多影响PG正常的IO;

同理,引⼊的osd_scrub_sleep 参数会让线程在每次scrub前释放PG lock,然后睡眠⼀段时间,也能很好的减少scrub对PG正常IO的影响;

配置建议:

osd_scrub_begin_hour 和osd_scrub_end_hour :OSD Scrub的开始结束时间,根据具体业务指定;

osd_scrub_sleep :osd在每次执⾏scrub时的睡眠时间;有个bug跟这个配置有关,建议关闭;

osd_scrub_load_threshold :osd开启scrub的系统load阈值,根据系统的load average值配置该参数;

osd_scrub_chunk_min 和osd_scrub_chunk_max :根据PG中object的个数配置;针对RGW全是

⼩⽂件的情况,这两个值需要调⼤;

参考:

[h]{.ul} [ttp://www.jianshu.com/p/ea2296e1555c]{.ul} [h]{.ul} [ttp://tracker.ceph.com/issues/19497]{.ul}

12,osd thread timeout配置参数

osd_op_thread_timeout 和osd_op_thread_suicide_timeout 关联的work queue为:

- 关联的请求为: OpRequestRef , PGSnapTrim , PGScrub

- 关联的请求为:osd peering

osd_recovery_thread_timeout 和osd_recovery_thread_suicide_timeout 关联的work queue

为:

- 关联的请求为:PG recovery

Ceph的work queue都有个基类WorkQueue_ ,定义如下:

这⾥的timeout_interval 和suicide_interval 分别对应上⾯所述的配置timeout 和

当thread处理work queue中的⼀个请求时,会受到这两个timeout时间的限制:

  • 到时间后设置m_unhealthy_workers+1

  • 到时间后调⽤assert,OSD进程crush

对应的处理函数为:

当前仅有RGW添加了worker的perfcounter,所以也只有RGW可以通过perf dump查看total/unhealthy

的worker信息:

对应的配置项为:

filestore_op_threads :对应的thread pool为op_tp ,对应的work queue为op_wq ;filestore的所有请求都经过op_wq处理;

增⼤该参数能提升filestore的处理能⼒,提升filestore的性能;配合filestore的throttle⼀起调整;

配置的含义与上⼀节中的[thread_timeout/thread_suicide_timeout]{.ul} 保持⼀致;

13,filestore merge/split配置参数

这两个参数是管理filestore的⽬录分裂/合并的,filestore的每个⽬录允许的最⼤⽂件数为:

在RGW的⼩⽂件应⽤场景,会很容易达到默认配置的⽂件数(320),若在写的过程中触发了filestore 的分裂,则会⾮常影响filestore的性能;

每次filestore的⽬录分裂,会依据如下规则分裂为多层⽬录,最底层16个⼦⽬录:

例如PG 31.4C0, hash结尾是4C0,若该⽬录分裂,会分裂为 DIR_0/DIR_C/DIR_4/{DIR_0, DIR_F} ;

原始⽬录下的object会根据规则放到不同的⼦⽬录⾥,object的名称格式为: * head_xxxxX4C0_* ,分裂时候X是⼏,就放进⼦⽬录DIR_X⾥。⽐如object: * head_xxxxA4C0_* , 就放进⼦⽬录

⾥;

解决办法:

  1. 增⼤merge/split配置参数的值,使单个⽬录容纳更多的⽂件;

  2. filestore_merge_threshold 配置为负数;这样会提前触发⽬录的预分裂,避免⽬录在某⼀时间段的集中分裂,详细机制没有调研;

  3. 创建pool时指定expected-num-objects ;这样会依据⽬录分裂规则,在创建pool的时候就创建分

裂的⼦⽬录,避免了⽬录分裂对filestore性能的影响;

参考:

[h]{.ul} [ttp://docs.ceph.com/docs/master/rados/configuration/filestore-config-ref/]{.ul} [h]{.ul} [ttp://docs.ceph.com/docs/jewel/rados/operations/pools/#create-a-pool]{.ul}

[h]{.ul} [ttp://blog.csdn.net/for_tech/article/details/51251936]{.ul} [h]{.ul} [ttp://ivanjobs.github.io/page3/]{.ul}

14,filestore fd cache配置参数

filestore的fd cache是加速访问filestore⾥的file的,在⾮⼀次性写⼊的应⽤场景,增⼤配置可以很明显的提升filestore的性能;

15,filestore sync配置参数

filestore_wbthrottle_enable 的配置是关于filestore writeback throttle的,即我们说的filestore处理workqueue op_wq 的数据量阈值;默认值是true,开启后XFS相关的配置参数有:

若使⽤普通HDD,可以保持其为true;针对SSD,建议将其关闭,不开启writeback throttle;

filestore_min_sync_interval 和 filestore_max_sync_interval 是 配 置 filestore flush outstanding IO到disk的时间间隔的;增⼤配置可以让系统做尽可能多的IO merge,减少filestore写磁盘的压⼒,但也会增⼤page cache占⽤内存的开销,增⼤数据丢失的可能性;

filestore_commit_timeout 是配置filestore sync entry到disk的超时时间,在filestore压⼒很⼤时, 调⼤这个值能尽量避免IO超时导致OSD crush;

16,filestore throttle配置参数

在jewel版本⾥,引⼊了dynamic throttle,来平滑普通throttle带来的⻓尾效应问题;

⼀般在使⽤普通磁盘时,之前的throttle机制即可很好的⼯作,所以这⾥默认

filestore_queue_high_delay_multiple 和filestore_queue_max_delay_multiple 都为0;

针对⾼速磁盘,需要在部署之前,通过⼩⼯具ceph_smalliobenchfs 来测试下,获取合适的配置参数;

参考:

[h]{.ul} [ttp://docs.ceph.com/docs/jewel/dev/osd_internals/osd_throttles/]{.ul} [h]{.ul} [ttp://blog.wjin.org/posts/ceph-dynamic-throttle.html]{.ul}

[h]{.ul} [ttps://github.com/ceph/ceph/blob/master/src/doc/dynamic-throttle.txt]{.ul} [C]{.ul} [eph BackoffThrottle分析]{.ul}

17,filestore finisher threads配置参数

这两个参数定义filestore commit/apply的finisher处理线程数,默认都为1,任何IO commit/apply完成后,都需要经过对应的ondisk/apply finisher thread处理;

在使⽤普通HDD时,磁盘性能是瓶颈,单个finisher thread就能处理好;

但在使⽤⾼速磁盘的时候,IO完成⽐较快,单个finisher thread不能处理这么多的IO commit/apply reply,它会成为瓶颈;所以在jewel版本⾥引⼊了finisher thread pool的配置,这⾥⼀般配置为2即可;

18,journal配置参数

journal_max_write_bytes 和journal_max_write_entries 是journal⼀次write的数据量和entries 限制;

针对SSD分区做journal的情况,这两个值要增⼤,这样能增⼤journal的吞吐量;

journal_throttle_high_multiple 和journal_throttle_max_multiple 是JournalThrottle 的配置参数, JournalThrottle 是BackoffThrottle 的封装类,所以JournalThrottle 与我们在filestore throttle介绍的dynamic throttle⼯作原理⼀样;

从上述代码中看出相关的配置参数有:

19,rbd cache配置参数

rbd_cache_size :client端每个rbd image的cache size,不需要太⼤,可以调整为64M,不然会⽐较占client端内存;

参照默认值,根据rbd_cache_size 的⼤⼩调整rbd_cache_max_dirty 和

rbd_cache_max_dirty :在writeback模式下cache的最⼤bytes数,默认是24MB;当该值为0 时,表示使⽤writethrough模式;

rbd_cache_target_dirty :在writeback模式下cache向ceph集群写⼊的bytes阀值,默认

16MB;注意该值⼀定要⼩于rbd_cache_max_dirty 值

rbd_cache_writethrough_until_flush :在内核触发flush cache到ceph集群前rbd cache⼀直是writethrough模式,直到flush后rbd cache变成writeback模式;

rbd_cache_max_dirty_age :标记OSDC端ObjectCacher中entry在cache中的最⻓时间;