Ceph的参数mon_osd_down_out_subtree_limit细解
Ceph的参数mon_osd_down_out_subtree_limit细解
zphj1987前言
之前跟一个朋友沟通一个其他的问题的时候，发现了有一个参数 mon osd down out subtree limit 一直没有接触到，看了一下这个参数还是很有作用的，本篇将讲述这个参数的作用和使用的场景
测试环境准备
首先配置一个集群环境，配置基本参数
1 | mon_osd_down_out_interval = 20 |
调整这个参数为20s,默认为300s,默认一个osd,down超过300s就会标记为out，然后触发迁移,这个是为了方便尽快看到测试的效果，很多测试都是可以这样缩短测试周期的
本次测试关心的是这个参数 mon osd down out subtree limit
参数，那么这个参数做什么用的，我们来看看
1 | [root@lab8106 ceph]# ceph --show-config|grep mon_osd_down_out_subtree_limit |
首先解释下这个参数是做什么的，这个是控制标记为out的最小子树(bucket)，默认的这个为rack，这个可能我们平时感知不到这个有什么作用，大部分情况下，我们一般都为主机分组或者做了故障域，也很少做到测试去触发它，本篇文章将告诉你这个参数在什么情况下生效，对我们又有什么作用
准备两个物理节点，每个节点上3个osd，一共六个osd，上面的down out的时间已经修改为20s，那么会在20s后出现out的情况
测试过程
测试默认参数停止一台主机单个OSD
首先用默认的mon_osd_down_out_subtree_limit = rack去做测试
开启几个监控终端方便观察
1 | ceph -w |
在其中的一台上执行
1 | systemctl stop ceph-osd@5 |
测试输出
1 | 2016-10-13 10:15:39.673898 mon.0 [INF] osd.5 out (down for 20.253201) |
停止一个后正常out
测试默认参数停止掉一台主机所有osd
我们再来停止一台主机所有osd
1 | systemctl stop ceph-osd.target |
测试输出
1 | 2016-10-13 10:17:09.699129 mon.0 [INF] osd.3 out (down for 23.966959) |
可以看到这台主机上的节点全部都正常out了
测试修改参数后停止一台主机单个OSD
我们再调整下参数
1 | mon_osd_down_out_subtree_limit = rack |
将这个参数设置为host
1 | mon_osd_down_out_subtree_limit = host |
重启所有的进程，让配置生效，我们测试下只断一个osd的时候能不能out
1 | systemctl stop ceph-osd@5 |
停止掉osd.5
测试输出
1 | 2016-10-13 10:48:45.612206 mon.0 [INF] osd.5 out (down for 21.966238) |
可以看到可以osd.5可以正常的out
测试修改参数后停止一台主机所有OSD
我们再来停止lab8107的所有的osd
1 | 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 |
