ceph的crush算法是个好东西,能够实现对象读写位置的计算,诶,最大的问题是,pg分布怎么如此不均衡
写在前面
松鼠哥的ceph专业课程上线啦!
面向新手同学,从0实战,全面入门ceph安装部署与运维,有需要的同学赶紧扫码订购吧:
在能够直接使用ceph自带的工具进行调整的情况下,尽量使用其进行调整优化,达到效果
问题的出现
在实际使用ceph的过程中,我们经常会遇到这样的问题,创建了pool之后,ceph osd df
会看到这些pool的pg在osd上分布不均匀,甚至相差很大,尤其是像rbd-pool或者rgw-data这样的数据pool,相差十几几十个pg,在集群用到80%以上时会出现让我们十分头疼的问题,就是部分osd已经到了nearfull
,但是部分osd只用了60%
解决这个问题的有效办法就是在集群刚建好的时候,对pool进行调整,调整的方法就是对osd进行reweight,通过多次的reweight,指定的pool在osd上能大致得到比较好的均衡效果,但是,这个前提是在集群刚建好的时候,而且,遇到扩容场景,这种多次调整的办法就不行了
解决思路
我们在生产上使用ceph,最希望的情况就是每一个磁盘使用量都几乎一样,这就意味着至少主要承载数据的pool的pg在所有指定的osd上是近乎完美分布的,而且,在扩容之后,所有osd的用量仍能保持非常均衡的水平,而使用最小的代价达到,有办法做到吗?
当然是有的,从12.2.x版本开始,社区开发出了一个工具osdmaptool
,这个工具允许我们对指定的osdmap进行运算,结合ceph osd pg-upmap-items
命令实现单个pg级别的人为迁移,这就意味着,我们可以人为地指定某个pg迁移到指定的osd上,真的太神奇了!
要知道,pg的分布是通过crushmap、reweight等参数输入到算法而计算出来的,目的是让client能够通过计算的方式得出应该在哪个位置进行读写,而人为改变pg在一定程度上可以说是违背了算法的本意
upmap
摘录一段官方的介绍
1 | Starting in Luminous v12.2.z there is a new pg-upmap exception table in |
也就是,upmap能够实现人为的指定pg分布,但是,需要客户端能够识别新的pg-upmap的结构,因为跟使用crush算法直接计算得出pg分布不同,人为修改了pg的位置后,就不能单单通过算法的到移动后的pg的位置了,必须提出新的结构
如何使用
这里我们实践一下,看看这个工具是不是真的那么好用
根据要求,使用upmap的前提条件有两个,第一是ceph版本必须是12.2.x及后续版本,第二是ceph的client特性至少要支持到luminous,才能保证client能够解读pg-upmap的新结构
在测试前,我们先导出集群的osdmap
1 | [store@server228 ~]$ ceph osd getmap -o thisosdmap |
然后我们查看一下此时集群中rgw的data pool的pg分布情况
1 | [store@server228 ~]$ osdmaptool --test-map-pgs --pool 5 ./thisosdmap |
可以看到,这个pool没有进行过reweight,最大的osd pg差达到了35,接下来对这个pool进行测算
对ceph 12.2.x及后续版本,我们使用下面的命令指定client的最低版本要求
1 | [store@server228 ~]$ ceph osd set-require-min-compat-client luminous --yes-i-really-mean-it |
可以看到,集群的client
仍有一个是jewel的,但是对后续没有影响
接下来,我们使用导出的osdmap进行计算,得出移动哪些pg
1 | [store@server228 ~]$ osdmaptool thisosdmap --upmap afterupmap --upmap-pool lab-zone1.rgw.buckets.data --upmap-max 100 --upmap-deviation 0.01 |
这里最多计算100次,误差在1%,我们的到了移动pg的建议,在aftermap中
1 | [store@server228 ~]$ head -n5 afterupmap |
可以看到,osdmaptool帮我们生成了移动pg所需要的全部命令,我们直接应用这些命令
1 | [store@server228 ~]$ source afterupmap |
执行完成,相关pg进入remapped+backfill状态,即pg的移动,待数据迁移完成,我们再对比一下osdmap中的pg 差异
1 | [store@server228 ~]$ ceph osd getmap -o new_thisosdmap |
可以看到,迁移后的到的新的pg分布近乎完美,pg分布最大差仅为2,而且是一次调整就的到了这样的结果,美滋滋~
缺点
东西虽好,不过经过实际测试是有使用限制的
这个修改会使得计算得出来的pg位置与实际pg的位置有差异,这个差异的重映射需要client的内核的支持
在我们的环境中,使用了rbd的场景进行测试,建立rbd池并进行上述一波操作后,在client host上用rbd device map rbd/testrbd
的方式尝试挂载rbd,均失败,报错为
1 | kernel: libceph: mon2 172.16.100.49:6789 feature set mismatch, my 40106b84a842a52 < server's 60106b84aa42a52, missing 200000000200000 |
经过多方排查,发现只要使用osdmap进行计算并使用upmap进行修改后,客户端就不好map上,即使rbd的特性该关的都关了,crushmap的选项也关掉了,这个是pg映射的问题,唯有升级高版本内核才可以,所以说,如果在内核版本无所谓的场景,这个手法才可以完美使用
总结
小规模集群的pg自然分布不均及扩容后的pg分布问题一直困扰着我们,在社区群或者读者来邮件中发现,有些同学为了保持pg的均衡分布,给每个osd分配了1000+个pg,这是非常夸张且不理智的做法,现在有了更好的工具,从之前的reweight,到后来的balancer,再到现在非常好用的upmap+osdmap,感谢社区为解决实际应用问题作出的努力
参考资料
- 本文作者: 奋斗的松鼠
- 本文链接: http://www.strugglesquirrel.com/2019/05/22/超实用的pg均衡工具upmap/
- 版权声明: 本博客所有文章除特别声明外,创作版权均为作者个人所有,未经允许禁止转载!