因为目前机器比较紧张,须要将我集群中的一批机器提供给其余业务使用,这时问题来了,集群机器的退出意味着数据要从新分布,数据迁移的过程当中比较容易出故障。node
集群中有不少POOL, 有些POOL是客户数据,这很是重要;有些POOL是我测试用,这些POOL对应的OSD能够直接删除,即时集群报pg异常,也无需关心,在删除对应OSD后将对应POOL删除便可,相应的pg异常也消失。app
注:为了不关闭OSD的过程当中发生数据迁移,请设置norecover标记。测试
ceph osd set norecover
删除对应主机上的全部OSD信息的命令以下:线程
killall -9 ceph-osd for i in {108..119} do ceph osd out osd.$i; ceph osd crush remove osd.$i; ceph auth del osd.$i; ceph osd rm $i; ceph auth del osd.$i; done ceph osd crush remove hostname removed item id -10 name 'hostname' from crush map
对于业务用到的POOL分布在了10台机器上,如今要从这10台机器中释放出五台,这须要涉及到数据迁移了。有三种办法进行处理。code
将要退出的机器依次设置为out状态。一台机器作完后作另一台,由系统负责将数据迁走;进程
将要推出的机器权重调整为0,由系统负责将数据迁走;v8
这是最快的办法,只涉及到一次迁移,等待数据迁移完毕后,就能够将不须要的OSD关闭并移除了。rem
症状表现,在集群状态中显示少许PG状态异常。 active + remapped + backfilling active + remappedit
[root@gnop029-ct-zhejiang_wenzhou-16-11 ~]# ceph -s cluster c6e7e7d9-2b91-4550-80b0-6fa46d0644f6 health HEALTH_WARN 2 pgs backfilling 3 pgs stuck unclean recovery 24/2148593 objects misplaced (0.001%) norecover,noscrub,nodeep-scrub flag(s) set monmap e3: 3 mons at {a=101.71.4.11:6789/0,b=101.71.4.12:6789/0,c=101.71.4.13:6789/0} election epoch 446, quorum 0,1,2 a,b,c osdmap e69909: 120 osds: 120 up, 120 in; 3 remapped pgs flags norecover,noscrub,nodeep-scrub pgmap v8678900: 10256 pgs, 16 pools, 2763 GB data, 1047 kobjects 7029 GB used, 197 TB / 214 TB avail 24/2148593 objects misplaced (0.001%) 10253 active+clean 2 active+remapped+backfilling 1 active+remapped
[root@ceph]# ceph pg dump_stuck unclean ok pg_stat state up up_primary acting acting_primary 23.1c1 active+remapped+backfilling [59,37] 59 [76,84] 76 23.23b active+remapped [35,7] 35 [82,119] 82 23.221 active+remapped+backfilling [15,18] 15 [70,82] 70
后来我开启了scrub和deepscrub, 将全部pg扫描后就恢复为active + clean。io
在发生数据迁移时,有时候某些osd会由于负载太高,致使osd进程退出,这是须要作两方面工做: