ceph集群单个osd超95%导致集群无法读写集群恢复过程

ceph新手，最近遇到的一个问题，已解决，请参考，文中有错误的话欢迎指正

故障描述

openstack环境中若干台虚拟机无法正常操作，尝试从horizon中重启虚拟机，重启过程中虚拟机状态一直停留在”powering on”的状态，无法进入系统

查看openstack环境，发现后端ceph的状态异常,一个OSD full，一个near full。（clock是这个集群已知问题，这里不做介绍）

(ceph-mon)[root@Node-160 /]# ceph -s
    cluster 8a946765-1bb5-40bc-a0bc-4cd830aee2a4
     health HEALTH_ERR
            clock skew detected on mon.192.168.1.159, mon.192.168.1.160
            1 full osd(s)
            1 near full osd(s)
            full flag(s) set
            Monitor clock skew detected 
     monmap e1: 3 mons at {192.168.1.158=192.168.1.158:6789/0,192.168.1.159=192.168.1.159:6789/0,192.168.1.160=192.168.1.160:6789/0}
            election epoch 16, quorum 0,1,2 192.168.1.158,192.168.1.159,192.168.1.160
     osdmap e321: 13 osds: 13 up, 13 in
            flags nearfull,full,sortbitwise,require_jewel_osds
      pgmap v2886234: 624 pgs, 11 pools, 1706 GB data, 383 kobjects
            5121 GB used, 2061 GB / 7183 GB avail
                 624 active+clean
  client io 365 kB/s rd, 436 op/s rd, 0 op/s wr

其中一个osd的使用率显示是full的状态。 根据Ceph官方文档中的描述，当一个OSD full比例达到95%时，集群将不接受任何Ceph Client端的读写数据的请求。所以导致虚拟机在重启时，无法启动的情况。

查看ceph集群中各osd的使用率

发现osd的使用不均衡，最高的已超过95%，最低的才40%多点，缺省的均衡方式是按照PGS数量来做均衡，osd之间相差不大，但是真实占用的空间差别太大，根据ceph集群的定义，即使只有一个osd的使用率超过95%，整个集群将不可用，无法读写。

(ceph-mon)[root@Node-158 /]# ceph osd df  
ID WEIGHT  REWEIGHT SIZE  USE   AVAIL  %USE  VAR  PGS 
 0 1.00000  1.00000  552G  353G   198G 64.02 0.90 142 
 2 1.00000  1.00000  552G  371G   181G 67.21 0.94 136 
 1 1.00000  1.00000  552G  440G   112G 79.71 1.12 159 
 4 1.00000  1.00000  552G  381G   170G 69.11 0.97 140 
 3 1.00000  1.00000  552G  338G   214G 61.20 0.86 125 
 5 1.00000  1.00000  552G  431G   120G 78.15 1.10 162 
 6 1.00000  1.00000  552G  422G   130G 76.45 1.07 160 
 7 1.00000  1.00000  552G  492G 61380M 89.15 1.25 158 
 8 1.00000  1.00000  552G  416G   135G 75.42 1.06 143 
 9 1.00000  1.00000  552G  525G 28015M 95.05 1.33 153 
10 1.00000  1.00000  552G  348G   203G 63.15 0.89 135 
11 1.00000  1.00000  552G  242G   310G 43.90 0.62 127 
12 1.00000  1.00000  552G  354G   197G 64.20 0.90 132 
              TOTAL 7183G 5120G  2062G 71.29          
MIN/MAX VAR: 0.62/1.33  STDDEV: 12.67

解决方法

根据官方的建议，首选的方案是添加osd磁盘，添加后将触发数据的重新均衡，full的osd使用率降到95%以下后err状态自然会清除。当时的实际情况无法添加。

网上查到的方案：

方案一，删除无用的rbd磁盘，这个办法也能够解决问题，由于当前的集群状态是err状态，不允许任何读写操作，所以删除的时候也会被卡住，网上查询的办法是使用“ceph osd unset full”命令暂时强制集群恢复读写，但是删除的时候遇到另一个”image still has watchers“的问题，所以该方法也未测试成功

方案二，临时调整osd full的阈值，然后删除不需要的rbd磁盘

ceph tell osd.* injectargs '--mon-osd-full-ratio 0.98'

实际执行命令的时候提示该参数unchangeable，所以也没成功。

---

临时方案

为了使集群能尽快回复读写状态，临时把osd.9所在的节点关机，集群丢失一个osd，但没了这个full的osd，集群的是warnning状态，这个状态下集群开始恢复数据，虽然不是active+clean的状态，但是ceph是可用的。这样做只是个临时方案，osd.9所在的节点如果不开机，数据无法达到完整状态，但只要开机，集群检测到full的osd，又会变成ERR状态。

---

最后方案

调整每个osd的weigh值，使数据重新分布

(ceph-mon)[root@Node-158 ceph]# ceph osd crush reweight osd.10 1.05 
reweighted item id 10 name 'osd.10' to 1.05 in crush map

osd缺省的weight值为1，调整以后数据会向weigh值高的osd上重新分布，
把一些比较空闲的osd weight值调高，接收数据,使用率高的osd weight调低，释放数据

  (ceph-mon)[root@Node-158 ceph]# ceph osd df
ID WEIGHT  REWEIGHT SIZE  USE   AVAIL %USE  VAR  PGS 
 0 1.00000  1.00000  552G  298G  254G 53.97 0.91 144 
 2 1.00000  1.00000  552G  319G  233G 57.79 0.98 145 
 1 0.89999  1.00000  552G  329G  223G 59.60 1.01 148 
 4 1.00000  1.00000  552G  323G  229G 58.53 0.99 144 
 3 1.04999  1.00000  552G  311G  241G 56.37 0.95 135 
 5 1.00000  1.00000  552G  372G  179G 67.46 1.14 166 
 6 1.00000  1.00000  552G  381G  171G 68.97 1.17 167 
 7 0.79999  1.00000  552G  345G  207G 62.50 1.06 132 
 8 1.00000  1.00000  552G  349G  202G 63.29 1.07 146 
 9 0.75000  1.00000  552G  360G  192G 65.16 1.10 126 
10 1.04999  1.00000  552G  303G  249G 54.89 0.93 141 
11 1.09999  1.00000  552G  249G  302G 45.23 0.77 139 
12 1.00000  1.00000  552G  298G  254G 53.99 0.91 139 
              TOTAL 7183G 4242G 2941G 59.06          
MIN/MAX VAR: 0.77/1.17  STDDEV: 6.23

最终集群恢复正常

附：（转帖）删除image时image still has watchers问题处理
抱歉忘了从哪转的了，亲测有效

在Ceph集群日常运维中，管理员可能会遇到有的image删除不了的情况，有一种情况是由于image下有快照信息，只需要先将快照信息清除，然后再删除该image即可，还有一种情况是因为该image仍旧被一个客户端在访问，具体表现为该image中有watcher，如果该客户端异常了，那么就会出现无法删除该image的情况。还有一种情况，就算image没有watcher了，但是还有mount占用，也可能删除不了
watcher是什么？
　　Ceph中有一个watch/notify机制(粒度是object)，它用来在不同客户端之间进行消息通知，使得各客户端之间的状态保持一致，而每一个进行watch的客户端，对于Ceph集群来说都是一个watcher。
如何查看当前image上的watcher?
　　因为watch的粒度是object，想要了解一个image上的watcher信息，最简单的方法就是查看该image的header对象上的watcher信息。
　　首先找到image的header对象
　　[root@Node62 ~]# rbd info test_img
　　rbd image 'test_img':
　　size 5000 MB in 1250 objects
　　order 22 (4096 kB objects)
　　block_name_prefix: rbd_data.fa7b2ae8944a
　　format: 2
　　features: layering, exclusive-lock, object-map, fast-diff, deep-flatten
　　查询到该image的block_name_prefix为 rbd_data.fa7b2ae8944a那么该image的header对象则为rbd_header.fa7b2ae8944a，然后我们就可以通过命令查看该image的header对象上的watcher信息。
　　[root@Node62 ~]# rados listwatchers -p rbd rbd_header.fa7b2ae8944a
　　watcher=192.8.8.10:0/1262448884 client.170939 cookie=140096303678368
      也可以：
root@ceph01:~/my-cluster# rbd status test-imgWatchers:    watcher=172.16.71.203:0/52000001 client.134475 cookie=140465230511472
    如果image为格式1：
     [root@nc1 ~]# rbd info hzb-mysql
     rbd image 'hzb-mysql':
     size 2048 MB in 512 objects
     order 22 (4096 kB objects)
     block_name_prefix: rb.0.11895f.6b8b4567
     format: 1
     则用：rados -p rbd listwatchers 'hzb-mysql.rbd
Ceph集群异常客户端Watcher处理
　　刚才查看到test_img这个image上有一个watcher，假设客户端watcher=192.8.8.10:0/1262448884出现异常，那么我们如何处理呢？其实我们只需要将此异常客户端设置到OSD的黑名单即可：
　　[root@Node62 ~]# ceph osd blacklist add 192.8.8.10:0/1262448884
　　blacklisting 192.8.8.10:0/1262448884 until 2017-03-27 02:11:54.206165 (3600 sec)
　　此时我们再去查看该image的header对象的watcher信息：
　　[root@Node62 ~]# rados listwatchers -p rbd rbd_header.fa7b2ae8944a
　　异常客户端的watcher信息已经不存在了，这个时候我们就可以对该image进行删除操作了。这种方法不是最推荐的，但是目前还找不到很好的解决方法。
       查询黑名单列表：
ceph osd blacklist ls
     从黑名单移出某一个
root@ceph01:~# ceph osd blacklist rm 172.16.71.203:0/2000001un-blacklisting 172.16.71.203:0/2000001
   清空黑名单里面的东西
root@ceph01:~# ceph osd blacklist clear removed all blacklist entries