Ceph的参数mon_osd_down_out_subtree_limit细解

前言

之前跟一个朋友沟通一个其他的问题的时候，发现了有一个参数 mon osd down out subtree limit 一直没有接触到，看了一下这个参数还是很有作用的，本篇将讲述这个参数的作用和使用的场景

测试环境准备

首先配置一个集群环境，配置基本参数

mon_osd_down_out_interval = 20

调整这个参数为20s,默认为300s,默认一个osd,down超过300s就会标记为out，然后触发迁移,这个是为了方便尽快看到测试的效果，很多测试都是可以这样缩短测试周期的

本次测试关心的是这个参数 mon osd down out subtree limit
参数，那么这个参数做什么用的，我们来看看

[root@lab8106 ceph]# ceph --show-config|grep mon_osd_down_out_subtree_limit
mon_osd_down_out_subtree_limit = rack

首先解释下这个参数是做什么的，这个是控制标记为out的最小子树(bucket)，默认的这个为rack，这个可能我们平时感知不到这个有什么作用，大部分情况下，我们一般都为主机分组或者做了故障域，也很少做到测试去触发它，本篇文章将告诉你这个参数在什么情况下生效，对我们又有什么作用

准备两个物理节点，每个节点上3个osd，一共六个osd，上面的down out的时间已经修改为20s，那么会在20s后出现out的情况

测试过程

测试默认参数停止一台主机单个OSD

首先用默认的mon_osd_down_out_subtree_limit = rack去做测试
开启几个监控终端方便观察

ceph -w
watch ceph osd tree

在其中的一台上执行

systemctl stop ceph-osd@5

测试输出

2016-10-13 10:15:39.673898 mon.0 [INF] osd.5 out (down for 20.253201)
2016-10-13 10:15:39.757399 mon.0 [INF] osdmap e60: 6 osds: 5 up, 5 in

停止一个后正常out

测试默认参数停止掉一台主机所有osd

我们再来停止一台主机所有osd

systemctl stop ceph-osd.target

测试输出

2016-10-13 10:17:09.699129 mon.0 [INF] osd.3 out (down for 23.966959)
2016-10-13 10:17:09.699178 mon.0 [INF] osd.4 out (down for 23.966958)
2016-10-13 10:17:09.699222 mon.0 [INF] osd.5 out (down for 23.966958)

可以看到这台主机上的节点全部都正常out了

测试修改参数后停止一台主机单个OSD

我们再调整下参数

mon_osd_down_out_subtree_limit = rack

将这个参数设置为host

mon_osd_down_out_subtree_limit = host

重启所有的进程，让配置生效，我们测试下只断一个osd的时候能不能out

systemctl stop ceph-osd@5

停止掉osd.5
测试输出

2016-10-13 10:48:45.612206 mon.0 [INF] osd.5 out (down for 21.966238)

可以看到可以osd.5可以正常的out

测试修改参数后停止一台主机所有OSD

我们再来停止lab8107的所有的osd

systemctl stop ceph-osd.target

停止掉 lab8107 所有的osd,可以看到没有out了,这个是因为把故障out设置为host级别了，这个地方出现host级别故障的时候，就不进行迁移了

总结

关键的地方在于总结了，首先我们要想一想，ceph机器的迁移开不开（noout），关于这个问题，一定有两个答案

• 开，不开的话，盘再坏怎么办，就会丢数据了
• 不开，人工触发，默认的情况下迁移数据会影响前端业务

这里这个参数其实就是将我们的问题更加细腻的控制了，我们现在根据这个参数就能做到，迁移可以开，坏掉一个盘的时候我让它迁移，一个盘的数据恢复影响和时间是可以接受的，主机损坏我不让他迁移，为什么？主机损坏你去让他迁移，首先会生成一份数据，等主机好了，数据又要删除一份数据，这个对于磁盘都是消耗，主机级别的故障一定是可修复的，这个地方主机down机，主机电源损坏，这部分数据都是在的，那么这个地方就是需要人工去做这个修复的工作的，对于前端的服务是透明的，默认的控制是down rack才不去标记out，这个当然你也可以控制为这个，比如有个rack掉电，就不做恢复，如果down了两台主机，让他去做恢复，当然个人不建议这么做，这个控制就是自己去判断这个地方需要做不

ceph里面还是提供了一些细微粒度的控制，值得去与实际的应用场景结合，当然默认的参数已经能应付大部分的场景，控制的更细只是让其变得更好

变更记录

Why	Who	When
创建	武汉-运维-磨渣	2016-10-13