前言
碰到一个cepher问了一个问题：
为什么我的OSD关闭到最后有92个OSD无法关闭,总共的OSD有300个左右
想起来在很久以前帮人处理过一次问题，当时环境是遇上了一个BUG，需要升级到新版本进行解决，然后当时我来做操作，升级以后，发现osd无法启动，进程在，状态无法更新，当时又回滚回去，就可以了，当时好像是K版本升级到J版本，想起来之前看过这个版本里面有数据结构的变化，需要把osd全部停掉以后才能升级，然后就stop掉所有osd，当时发现有的osd还是无法stop，然后就手动去标记了，然后顺利升级
今天这个现象应该跟当时是一个问题，然后搜索了一番参数以后，最后定位在确实是参数进行了控制
实践
我的一个8个osd的单机环境，对所有OSD进行stop以后就是这个状态，还有2个状态无法改变
[root@lab8106 ~]# ceph -s
cluster 49ee8a7f-fb7c-4239-a4b7-acf0bc37430d
health HEALTH_ERR
295 pgs are stuck inactive for more than 300 seconds
295 pgs stale
295 pgs stuck stale
too many PGs per OSD (400 > max 300)
monmap e1: 1 mons at {lab8106=192.168.8.106:6789/0}
election epoch 3, quorum 0 lab8106
osdmap e77: 8 osds: 2 up, 2 in; 178 remapped pgs
flags sortbitwise,require_jewel_osds
pgmap v296: 400 pgs, 1 pools, 0 bytes data, 0 objects
76440 kB used, 548 GB / 548 GB avail
295 stale+active+clean
105 active+clean
看下这组参数：
mon_osd_min_up_ratio = 0.3
mon_osd_min_in_ratio = 0.3
我们修改成0 后再测试
mon_osd_min_up_ratio = 0
mon_osd_min_in_ratio = 0
停止进程
systemctl stop ceph-osd.target
查看状态
[root@lab8106 ~]# ceph -s
cluster 49ee8a7f-fb7c-4239-a4b7-acf0bc37430d
health HEALTH_ERR
48 pgs are stuck inactive for more than 300 seconds
85 pgs degraded
15 pgs peering
400 pgs stale
48 pgs stuck inactive
48 pgs stuck unclean
85 pgs undersized
8/8 in osds are down
monmap e1: 1 mons at {lab8106=192.168.8.106:6789/0}
election epoch 4, quorum 0 lab8106
osdmap e86: 8 osds: 0 up, 8 in
flags sortbitwise,require_jewel_osds
pgmap v310: 400 pgs, 1 pools, 0 bytes data, 0 objects
286 MB used, 2193 GB / 2194 GB avail
300 stale+active+clean
85 stale+undersized+degraded+peered
15 stale+peering
可以看到状态已经可以正常全部关闭了
分析
这里不清楚官方做这个的理由，个人推断是这样的，默认的副本为3，那么在集群有三分之二的OSD都挂掉了以后，再出现OSD挂掉的情况下，这个集群其实就是一个废掉的状态的集群，而这个时候，还去触发down和out，对于环境来说已经是无效的操作了，触发的迁移也属于无效的迁移了，这个时候保持一个最终的可用的osdmap状态，对于整个环境的恢复也有一个基准点
在Luminous版本中已经把这个参数改成
mon_osd min_up_ratio = 0.3
mon_osd_min_in_ratio = 0.75
来降低其他异常情况引起的down，来避免过量的迁移
总结
本篇就是一个参数的实践
变更记录
| Why | Who | When |
|---|---|---|
| 创建 | 武汉-运维-磨渣 | 2017-08-21 |