码迷,mamicode.com
首页 > 其他好文 > 详细

Ceph性能优化 之 配置参数调优

时间:2016-05-06 13:09:39      阅读:2039      评论:0      收藏:0      [点我收藏+]

标签:

该文同时发表在盛大游戏G云微信公众号,粘贴于此,方便各位查阅

Ceph,相信很多IT朋友都听过。因为搭上了Openstack的顺风车,Ceph火了,而且越来越火。然而要用好Ceph却也不是件易事,在QQ群里就经常听到有初学者抱怨Ceph性能太烂,不好用。事实果真如此吗!如果你采用Ceph的默认配置来运行你的Ceph集群,性能自然不能如人意。俗话说,玉不琢,不成器;Ceph也有它的脾性,经过良好配置优化的Ceph性能还是不错的。下文简单分享下,盛大游戏G云在Ceph优化上的一些实际经验,如有错误之处,欢迎指正。

下文的Ceph配置参数摘自Ceph Hammer 0.94.1 版本

Ceph配置参数优化

首先来看看Ceph客户端与服务端的交互组件图:

技术分享

Ceph是一个统一的可扩展的分布式存储,提供Object,Blockfile system三种访问接口;它们都通过底层的librados与后端的OSD交互;OSD是Ceph的对象存储单元,实现数据的存储功能。其内部包含众多模块,模块之间通过队列交换消息,相互协作共同完成io的处理;典型模块有:网络模块Messenger,数据处理模块Filestore,日志处理模块FileJournal等。

面对众多的模块,Ceph也提供了丰富的配置选项,初步统计Ceph有上千个配置参数,要配置好这么多参数,难度有多大可想而知。G云内部主要使用Ceph Block Storage,即:Ceph rbd;下文的配置参数优化也就限于rbd客户端(librbd)和OSD端。
下面先来看看客户端的优化

rbd客户端配置优化

当Ceph作为虚拟机块存储使用时,Qemu是通过librbd,这个客户端库与Ceph集群交互的;与其相关的配置参数基本都以rbd_为前缀。可以通过如下命令获取librbd的当前配置:

//path/to/socket指向某个osd的admin socket文件
#> ceph --admin-daemon {path/to/socket} config show | grep rbd

下面对其中的某些配置参数进行详细说明:

  • rbd cache: 是否使能缓存,默认情况下开启。
  • rbd cache size:最大的缓存大小,默认32MB
  • rbd cache max dirty:缓存中脏数据的最大值,用来控制回写,不能超过rbd cache size,默认24MB
  • rbd cache target dirty:开始执行回写的脏数据大小,不能超过rbd cache max dirty,默认16MB
  • rbd cache max dirty age: 缓存中单个脏数据的最大缓存时间,避免因为未达到回写要求脏数据长时间存在缓存中,默认1s

点评:开启Cache能显著提升顺序io的读写性能,缓存越大性能越好;如果容许一定的数据丢失,建议开启。

  • rbd cache max dirty object:最大的Object对象数,默认为0,表示通过rbd cache size计算得到,librbd默认以4MB为单位对磁盘Image进行逻辑切分,每个chunk对象抽象为一个Objectlibrbd中以Object为单位来管理缓存,增大该值可以提升性能。

点评:在ceph-0.94.1中该值较小,建议按照ceph-0.94.4版本中的计算公式增大该值,如下:

obj = MIN(2000, MAX(10, cct->_conf->rbd_cache_size / 100 / sizeof(ObjectCacher::Object)));

我配置的时候取 sizeof(ObjectCacher::Object) = 128, 128是我基于代码估算的Object对象大小

  • rbd cache writethrough until flush:默认为true,该选项是为了兼容linux-2.6.32之前的virtio驱动,避免因为不发送flush请求,数据不回写;设置该参数后,librbd会以writethrough的方式执行io,直到收到第一个flush请求,才切换为writeback方式。

点评:如果您的Linux客户机使用的是2.6.32之前的内核建议设置为true,否则可以直接关闭。

  • rbd cache block writes upfront:是否开启同步io,默认false,开启后librbd要收到Ceph OSD的应答才返回。

点评: 开启后,性能最差,但是最安全。

  • rbd readahead trigger requests: 触发预读的连续请求数,默认为10
  • rbd readahead max bytes: 一次预读请求的最大io大小,默认512KB,为0则表示关闭预读
  • rbd readahead disable after bytes: 预读缓存的最大数据量,默认为50MB,超过阀值后,librbd会关闭预读功能,由Guest OS处理预读(防止重复缓存);如果为0,则表示不限制缓存。

点评:如果是顺序读io为主,建议开启

  • objecter inflight ops: 客户端流控,允许的最大未发送io请求数,超过阀值会堵塞应用io,为0表示不受限
  • objecter inflight op bytes:客户端流控,允许的最大未发送脏数据,超过阀值会堵塞应用io,为0表示不受限

点评:提供了简单的客户端流控功能,防止网络拥塞;在宿主网络成为瓶颈的情况下,rbd cache中可能充斥着大量处于发送状态的io,这又会反过来影响io性能。没有特殊需要的话,不需要修改该值;当然如果带宽足够的话,可以根据需要调高该值

  • rbd ssd cache: 是否开启磁盘缓存,默认开启
  • rbd ssd cache size:缓存的最大大小,默认10G
  • rbd ssd cache max dirty:缓存中脏数据的最大值,用来控制回写,不能超过rbd ssd cache size,默认7.5G
  • rbd ssd cache target dirty:开始执行回写的脏数据大小,不能超过rbd cache max dirty,默认5G
  • rbd ssd chunk order:缓存文件分片大小,默认64KB = 2^16
  • rbd ssd cache path:缓存文件所在的路径

点评:这是盛大游戏G云自己开发的带掉电保护的rbd cache,前面四个参数与前述rbd cache *含义相似,rdb ssd chunk size定义缓存文件的分片大小,是缓存文件的最小分配/回收单位,分片大小直接影响缓存文件的使用效率;在运行过程中librbd也会基于io大小动态计算分片大小,并在合适的时候应用到缓存文件.

上面就是盛大游戏G云在使用Ceph rbd过程中,在客户端所做优化的一些经验,如有错误还请多多批评指正,也欢迎各位补充。继续来看看OSD的调优

OSD配置优化

Ceph OSD端包含了众多配置参数,所有的配置参数定义在src/common/config_opts.h文件中,当然也可以通过命令查看集群的当前配置参数:

#> ceph --admin-daemon {path/to/socket} config show

由于能力有限,下面仅分析常见的几个配置参数:

  • osd op threads:处理peering等请求的线程数
  • osd disk threads:处理snap trim,replica trim及scrub等的线程数
  • filestore op threads:io线程数

点评:相对来说线程数越多,并发度越高,性能越好;然如果线程太多,频繁的线程切换也会影响性能;所以在设置线程数时,需要全面考虑节点CPU性能,OSD个数以及存储介质性质等。通常前两个参数设置一个较小的值,而最后一个参数设置一个较大的值,以加快io处理速度。在发生peering等异常时可以动态的调整相关的值。

  • filestore op thread timeout:io线程超时告警时间
  • filestore op thread suicide timeout:io线程自杀时间,当一个线程长时间没有响应,Ceph会终止该线程,并导致OSD进程退出

点评: 如果io线程出现超时,应结合相关工具/命令分析(如:ceph osd perf),是否OSD所在的磁盘存在瓶颈,或者介质故障等

  • ms dispatch throttle bytes:Messenger流控,控制DispatcherQueue队列深度,0表示不受限

点评:Messenger处在OSD的最前端,其性能直接影响io处理速度。在Hammer版本中,io请求添加到OSD::op_shardedwq才会返回,其他一些请求会直接添加到DispatchQueue中;为避免Messenger成为瓶颈,可以将该值设大点

  • osd_op_num_shards:默认为5,OSD::op_shardedwq中存储io的队列个数
  • osd_op_num_threads_per_shard: 默认为2,为OSD::op_shardedwq中每个队列分配的io分发线程数

点评:作用于OSD::op_shardedwq的总线程数为:osd_op_num_shards*osd_op_num_threads_per_shard, 默认为10;io请求经由Messenger进入,添加到OSD::op_shardedwq后,由上述分发线程发送给后端的filestore处理。视前端网络(如:10Gbps)和后端介质性能(如:SSD),可考虑调高该值。

  • filestore_queue_max_ops:控制filestore中队列的深度,最大未完成io数
  • filestore_queue_max_bytes:控制filestore中队列的深度,最大未完成io数据量
  • filestore_queue_commiting_max_ops:如果OSD后端的文件系统支持检查点,则filestore_queue_max_ops+filestore_queue_commiting_max_ops作为filestore中队列的最大深度,表示最大未完成io数
  • filestore_queue_commiting_max_bytes:如果OSD后端的文件系统支持检查点,则filestore_queue_max_bytes+filestore_queue_commiting_max_bytes作为filestore中队列的最大深度,表示最大未完成io数据量

点评: filestore收到前述分发线程递交的io后,其处理过程首先会受到filestore队列深度的影响;如果队列中未完成io超过设置阀值,请求将会堵塞。所以调高该值是不个很明智的选择。

  • journal_queue_max_ops: 控制FileJournal中队列的深度,最大未完成日志io数
  • journal_queue_max_bytes: 控制FileJournal中队列的深度,最大未完成日志io数据量

点评: filestore收到前述分发线程递交的io后,还会受到FileJournal队列的影响;如果队列中未完成io超过设置阀值,请求同样会堵塞;通常,调高该值是个不错的选择;另外,采用独立的日志盘, io性能也会有不少的提升

  • journal_max_write_entries: FileJournal一次异步日志io最大能处理的条目数
  • journal_max_write_bytes: FileJournal一次异步日志io最大能处理的数据量

点评: 这两个参数控制日志异步io每次能处理的最大io数,通常要根据日志文件所在磁盘的性能来设置一个合理值

  • filestore_wbthrottle_enable:默认为true,控制OSD后端文件系统刷新
  • filestore_wbthrottle_*_bytes_start_flusher:xfs/btrfs文件系统开始执行回刷的脏数据
  • filestore_wbthrottle_*_bytes_hard_limit: xfs/btrfs文件系统允许的最大脏数据,用来控制filestore的io操作
  • filestore_wbthrottle_*_ios_start_flusher:xfs/btrfs文件系统开始执行回刷的io请求数
  • filestore_wbthrottle_*_ios_hard_limit:xfs/btrfs文件系统允许的最大未完成io请求数,用来控制filestore的io操作
  • filestore_wbthrottle_*_inodes_start_flusher:xfs/btrfs文件系统开始执行回刷的对象数
  • filestore_wbthrottle_*_inodes_hard_limit:xfs/btrfs文件系统允许的最大脏对象,用来控制filestore的io操作

点评:*_start_flusher参数定义了刷新xfs/btrfs文件系统脏数据阀值,以将磁盘缓存更新到磁盘;*_hard_limit参数会影响filestore的io操作,堵塞filestore op thread线程。所以设置一个较大的值性能会有提升

  • filestore_fd_cache_size: 对象文件句柄缓存大小
  • filestore_fd_cache_shards: 对象文件句柄缓存分片个数

点评:缓存文件句柄能加快文件的访问速度,个人建议缓存所有的文件句柄,当然请记得调高系统的句柄限制,以免句柄耗尽

  • filestore_fiemap: 开启稀疏读写特性

点评: 开启该特性,有助于加快克隆和恢复速度

  • filestore_merge_threshold: pg子目录合并的最小文件数
  • filestore_split_multiple: pg子目录分裂乘数,默认为2

点评:这两个参数控制pg目录的合并与分裂,当目录下的文件数小于filestore_merge_threshold时,该目录的对象文件会被合并到父目录;如果目录的文件数大于filestore_merge_threshold*16*filestore_split_multiple,该目录会分裂成两个子目录。设置合理的值可以加快对象文件的索引速度

  • filestore_omap_header_cache_size: 扩展属性头缓存

点评: 缓存对象的扩展属性_Header对象,减少对后端leveldb数据库的访问,提升查找性能

纯属抛砖引玉,结合个人的实践经验,上文给出了Ceph的一些配置参数设置建议,希望能给大家一些思路。Ceph的配置还是比较复杂的,是一项系统工程,各个参数的配置需要综合考虑各节点的网络情况,CPU性能,磁盘性能等等因素,欢迎大家留言讨论!:-)

Ceph性能优化 之 配置参数调优

标签:

原文地址:http://blog.csdn.net/lzw06061139/article/details/51320138

(0)
(0)
   
举报
评论 一句话评论(0
登录后才能评论!
© 2014 mamicode.com 版权所有  联系我们:gaon5@hotmail.com
迷上了代码!