问题描述
一个服务连接不上ceph的对象存储网关,重启ceph对象存储网关,也不生效。
ceph服务网关的日志如下:
2017-10-31 19:51:21.158008 7f3b789b99c0 0 deferred set uid:gid to 167:167 (ceph:ceph)
2017-10-31 19:51:21.158206 7f3b789b99c0 0 ceph version 10.2.7 (50e863e0f4bc8f4b9e31156de690d765af245185), process radosgw, pid 1321
2017-10-31 19:51:21.244854 7f3b789b99c0 0 client.34193.objecter FULL, paused modify 0x7f3b7a1388d0 tid 0
2017-10-31 19:56:21.158388 7f3b5dc9b700 -1 Initialization timeout, failed to initialize
2017-10-31 19:56:21.410096 7f918b9bb9c0 0 deferred set uid:gid to 167:167 (ceph:ceph)
2017-10-31 19:56:21.410202 7f918b9bb9c0 0 ceph version 10.2.7 (50e863e0f4bc8f4b9e31156de690d765af245185), process radosgw, pid 1459
2017-10-31 19:56:21.546455 7f918b9bb9c0 0 client.34214.objecter FULL, paused modify 0x7f918d689c70 tid 0
使用ceph health
查看发现:
$ ceph health
1 full osd(s); pool default.rgw.buckets.data has many more objects per pg than average (too few pgs?); full flag(s) set;
问题解决
根据Ceph官方文档中的描述,当一个OSD full比例达到95%时,集群将不接受任何Ceph Client端的读写数据的请求。
通过命令ceph osd df
,发现一个osd使用空间超过95:
$ ceph osd df
ID WEIGHT REWEIGHT SIZE USE AVAIL %USE VAR PGS
0 0.48799 1.00000 499G 295G 204G 59.17 1.32 47
5 0.97609 1.00000 999G 56253M 944G 5.50 0.12 84
1 0.48799 1.00000 499G 341G 158G 68.33 1.53 64
6 0.48318 1.00000 494G 42432k 494G 0.01 0 49
2 0.48799 1.00000 499G 474G 25533M 95.01 2.13 78
3 0.48799 1.00000 499G 204G 295G 40.92 0.92 68
4 0.48799 1.00000 499G 411G 89998M 82.41 1.85 74
TOTAL 3993G 1783G 2209G 44.66
虽然ceph full或者nearfull的解决方法探究也提到,可以先将full的比例提高到98%。但是执行时发现不可更改:
$ ceph tell osd.* injectargs '--mon-osd-full-ratio 0.98'
osd.0: mon_osd_full_ratio = '0.98' (unchangeable)
osd.1: mon_osd_full_ratio = '0.98' (unchangeable)
osd.2: mon_osd_full_ratio = '0.98' (unchangeable)
osd.3: mon_osd_full_ratio = '0.98' (unchangeable)
osd.4: mon_osd_full_ratio = '0.98' (unchangeable)
增加了两块OSD之后,经过了漫长的数据重新分布:
$ ceph health
HEALTH_ERR clock skew detected on mon.registry-ceph02, mon.registry-ceph03; 21 pgs backfill_wait; 2 pgs backfilling; 7 pgs degraded; 6 pgs recovery_wait; 7 pgs stuck degraded; 29 pgs stuck unclean; 1 pgs stuck undersized; 1 pgs undersized; recovery 41684/1371951 objects degraded (3.038%); recovery 694899/1371951 objects misplaced (50.650%); 1 full osd(s); pool default.rgw.buckets.data has many more objects per pg than average (too few pgs?); full flag(s) set; Monitor clock skew detected
当osd使用比例下降到95%以下后,集群恢复正常。
解决方法
根据官方的建议,首选的方案是添加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