删除osd的正确方式有如下(对比分析)
在ceph的集群当中关于节点的替换的问题,一直按照以前的方式进行的处理,处理的步骤如下:
- 停止osd进程
/etc/init.d/ceph stop osd.0 |
这一步是停止osd的进程,让其他的osd知道这个节点不提供服务了
- 将节点状态标记为out
ceph osd out osd.0 |
这个一步是告诉mon,这个节点已经不能服务了,需要在其他的osd上进行数据的恢复了
- 从crush中移除节点
ceph osd crush remove osd.0 |
从crush中删除是告诉集群这个点回不来了,完全从集群的分布当中剔除掉,让集群的crush进行一次重新计算,之前节点还占着这个crush weight,会影响到当前主机的host crush weight
- 删除节点
ceph osd rm osd.0 |
这个是从集群里面删除这个节点的记录
- 删除节点认证(不删除编号会占住)
ceph auth del osd.0 |
这个是从认证当中去删除这个节点的信息
这个一直是我处理故障的节点osd的方式,其实这个会触发两次迁移,一次是在节点osd out以后,一个是在crush remove以后,两次迁移对于集群来说是不好的,其实是调整步骤是可以避免二次迁移的
新的处理方式(推荐)
- 调整osd的crush weight
ceph osd crush reweight osd.0 0.1 |
说明:这个地方如果想慢慢的调整就分几次将crush 的weight 减低到0 ,这个过程实际上是让数据不分布在这个节点上,让数据慢慢的分布到其他节点上,直到最终为没有分布在这个osd,并且迁移完成
这个地方不光调整了osd 的crush weight ,实际上同时调整了host 的 weight ,这样会调整集群的整体的crush 分布,在osd 的crush 为0 后, 再对这个osd的任何删除相关操作都不会影响到集群的数据的分布
- 停止osd进程
/etc/init.d/ceph stop osd.0 |
停止到osd的进程,这个是通知集群这个osd进程不在了,不提供服务了,因为本身没权重,就不会影响到整体的分布,也就没有迁移
- 将节点状态标记为out
ceph osd out osd.0 |
停止到osd的进程,这个是通知集群这个osd不再映射数据了,不提供服务了,因为本身没权重,就不会影响到整体的分布,也就没有迁移
- 从crush中移除节点
ceph osd crush remove osd.0 |
这个是从crush中删除,因为已经是0了 所以没影响主机的权重,也就没有迁移了
- 删除节点
ceph osd rm osd.0 |
这个是从集群里面删除这个节点的记录
- 删除节点认证(不删除编号会占住)
ceph auth del osd.0 |
这个是从认证当中去删除这个节点的信息
经过验证,第二种方式只触发了一次迁移,虽然只是一个步骤先后上的调整,对于生产环境的的集群来说,迁移的量要少了一次,实际生产环境当中节点是有自动out的功能,这个可以考虑自己去控制,只是监控的密度需要加大,毕竟这个是一个需要监控的集群,完全让其自己处理数据的迁移是不可能的,带来的故障只会更多
替换OSD操作的优化与分析
一、前言
之前有写过一篇删除OSD的正确方式,里面只是简单的讲了下删除的方式怎样能减少迁移量,本篇属于一个扩展,讲述了 Ceph 运维当中经常出现的坏盘提换盘的步骤的优化
基础环境两台主机每台主机8个 OSD,一共 16 个 OSD,副本设置为2,PG 数设置为800,计算下来平均每个 OSD 上的 P G数目为100个,本篇将通过数据来分析不同的处理方法的差别
开始测试前先把环境设置为 noout
,然后通过停止 OSD 来模拟 OSD 出现了异常,之后进行不同处理方法
二、测试三种方法
方法一:首先 out 一个 OSD,然后剔除 OSD,然后增加 OSD
- 停止指定 OSD 进程
- out 指定 OSD
- crush remove 指定 OSD
- 增加一个新的 OSD
一般生产环境会设置为 noout
,当然不设置也可以,那就交给程序去控制节点的 out,默认是在进程停止后的五分钟,总之这个地方如果有 out 触发,不管是人为触发,还是自动触发数据流是一定的,我们这里为了便于测试,使用的是人为触发,上面提到的预制环境就是设置的 noout
开始测试前获取最原始的分布
[root@lab8106 ~]# ceph pg dump pgs|awk '{print $1,$15}'|grep -v pg > pg1.txt |
获取当前的 PG 分布,保存到文件pg1.txt,这个 PG 分布记录是 PG 所在的 OSD,记录下来,方便后面进行比较,从而得出需要迁移的数据
停止指定的 OSD 进程
[root@lab8106 ~]# systemctl stop ceph-osd@15 |
停止进程并不会触发迁移,只会引起 PG 状态的变化,比如原来主 PG 在停止的 OSD 上,那么停止掉 OSD 以后,原来的副本的那个 PG 就会角色升级为主 PG 了
out 掉一个 OSD
[root@lab8106 ~]# ceph osd out 15 |
在触发 out 以前,当前的 PG 状态应该有 active+undersized+degraded
,触发 out 以后,所有的 PG 的状态应该会慢慢变成 active+clean
,等待集群正常后,再次查询当前的 PG 分布状态
[root@lab8106 ~]# ceph pg dump pgs|awk '{print $1,$15}'|grep -v pg > pg2.txt |
保存当前的 PG 分布为pg2.txt
比较 out 前后的 PG 的变化情况,下面是比较具体的变化情况,只列出变化的部分
[root@lab8106 ~]# diff -y -W 100 pg1.txt pg2.txt --suppress-common-lines |
这里我们关心的是变动的数目,只统计变动的 PG 的数目
[root@lab8106 ~]# diff -y -W 100 pg1.txt pg2.txt --suppress-common-lines|wc -l |
第一次 out 以后有102个 PG 的变动,这个数字记住,后面的统计会用到
从 crush 里面删除 OSD
[root@lab8106 ~]# ceph osd crush remove osd.15 |
crush 删除以后同样会触发迁移,等待 PG 的均衡,也就是全部变成 active+clean
状态
[root@lab8106 ~]# ceph pg dump pgs|awk '{print $1,$15}'|grep -v pg > pg3.txt |
获取当前的 PG 分布的状态
现在来比较 crush remove 前后的 PG 变动
[root@lab8106 ~]# diff -y -W 100 pg2.txt pg3.txt --suppress-common-lines|wc -l |
我们重新加上新的 OSD
[root@lab8106 ~]# ceph-deploy osd prepare lab8107:/dev/sdi |
加完以后统计当前的新的 PG 状态
[root@lab8106 ~]# ceph pg dump pgs|awk '{print $1,$15}'|grep -v pg > pg4.txt |
比较前后的变化
[root@lab8106 ~]# diff -y -W 100 pg3.txt pg4.txt --suppress-common-lines|wc -l |
整个替换流程完毕,统计上面的 PG 总的变动
102 +137 +167 = 406
也就是按这个方法的变动为406个 PG,因为是只有双主机,里面可能存在某些放大问题,这里不做深入的讨论,因为我的三组测试环境都是一样的情况,只做横向比较,原理相通,这里是用数据来分析出差别
方法二:先crush reweight 0 ,然后out,然后再增加osd
首先恢复环境为测试前的环境
[root@lab8106 ~]# ceph pg dump pgs|awk '{print $1,$15}'|grep -v pg > 2pg1.txt |
记录最原始的 PG 分布情况
crush reweight 指定OSD
[root@lab8106 ~]# ceph osd crush reweight osd.16 0 |
等待平衡了以后记录当前的 PG 分布状态
[root@lab8106 ~]# ceph pg dump pgs|awk '{print $1,$15}'|grep -v pg > 2pg2.txt |
比较前后的变动
[root@lab8106 ~]# diff -y -W 100 2pg1.txt 2pg2.txt --suppress-common-lines|wc -l |
crush remove 指定 OSD
[root@lab8106 ~]# ceph osd crush remove osd.16 |
这个地方因为上面 crush 已经是0了所以删除也不会引起 PG 变动
然后直接 ceph osd rm osd.16
同样没有 PG 变动
增加新的 OSD
[root@lab8106 ~]#ceph-deploy osd prepare lab8107:/dev/sdi |
等待平衡以后获取当前的 PG 分布
[root@lab8106 ceph]# ceph pg dump pgs|awk '{print $1,$15}'|grep -v pg > 2pg3.txt |
来比较前后的变化
[root@lab8106 ~]# diff -y -W 100 2pg2.txt 2pg3.txt --suppress-common-lines|wc -l |
总的 PG 变动为
166+159=325
方法3:开始做norebalance,然后做crush remove,然后做add
恢复环境为初始环境,然后获取当前的 PG 分布
[root@lab8106 ~]# ceph pg dump pgs|awk '{print $1,$15}'|grep -v pg > 3pg1.txt |
给集群做多种标记,防止迁移
设置为 norebalance,nobackfill,norecover,后面是有地方会解除这些设置的
[root@lab8106 ~]# ceph osd set norebalance |
crush reweight 指定 OSD
[root@lab8106 ~]# ceph osd crush reweight osd.15 0 |
这个地方因为已经做了上面的标记,所以只会出现状态变化,而没有真正的迁移,我们也先统计一下
[root@lab8106 ~]# ceph pg dump pgs|awk '{print $1,$15}'|grep -v pg > 3pg2.txt |
注意这里只是计算了,并没有真正的数据变动,可以通过监控两台的主机的网络流量来判断,所以这里的变动并不用计算到需要迁移的 PG 数目当中
crush remove 指定 OSD
[root@lab8106 ~]#ceph osd crush remove osd.15 |
删除指定的 OSD
删除以后同样是没有 PG 的变动的
ceph osd rm osd.15 |
这个地方有个小地方需要注意一下,不做 ceph auth del osd.15 把15的编号留着,这样好判断前后的 PG 的变化,不然相同的编号,就无法判断是不是做了迁移了
增加新的 OSD
[root@lab8106 ~]#ceph-deploy osd prepare lab8107:/dev/sdi |
我的环境下,新增的 OSD 的编号为16了
解除各种标记
我们放开上面的设置,看下数据的变动情况
[root@lab8106 ceph]# ceph osd unset norebalance |
设置完了后数据才真正开始变动了,可以通过观察网卡流量看到,来看下最终pg变化
[root@lab8106 ceph]# ceph pg dump pgs|awk '{print $1,$15}'|grep -v pg > 3pg3.txt |
这里我们只需要跟最开始的 PG 分布状况进行比较就可以了,因为中间的状态实际上都没有做数据的迁移,所以不需要统计进去,可以看到这个地方动了195个 PG
总共的 PG 迁移量为
195
三、数据汇总
现在通过表格来对比下三种方法的迁移量的比较(括号内为迁移 PG 数目)
|
方法一 |
方法二 |
方法三 |
所做操作 |
stop osd (0) |
crush reweight osd(166) |
set 标记(0) |
PG迁移数量 |
406 |
325 |
195 |
可以很清楚的看到三种不同的方法,最终的触发的迁移量是不同的,处理的好的话,能节约差不多一半的迁移的数据量,这个对于生产环境来说还是很好的,关于这个建议先在测试环境上进行测试,然后再操作,上面的操作只要不对磁盘进行格式化,操作都是可逆的,也就是可以比较放心的做,记住所做的操作,每一步都做完都去检查 PG 的状态是否是正常的
四、总结
从我自己的操作经验来看,最开始是用的第一种方法,后面就用第二种方法减少了一部分迁移量,最近看到资料写做剔除OSD的时候可以关闭迁移防止无效的过多的迁移,然后就测试了一下,确实能够减少不少的迁移量,这个减少在某些场景下还是很好的,当然如果不太熟悉,用哪一种都可以,最终能达到的目的是一样的