因为坏盘或者osd本身需要进行单独升级、修改的时候,osd需要重建,osd的重建会引发pg的迁移使得集群发生数据转移,在数据量很大的情况下,这种数据转移要尽可能地避免
网上有不少关于osd删除、重建的文章,也不乏质量高的牛人博客,例如徐大神删除osd的正确方式,还有ceph业内大牛Sébastien HanCeph: properly remove an OSD
参考了不少高质量的文章后,笔者打算利用手上环境实际验证一下这些方法
最常规做法
此前我们的1.6PB集群出现过一次坏盘,导致了数个osd重建,由于当时集群拥有超不多二十亿张图片,线上业务还要不间断写入,压力不少
将osd设置out
使用ceph osd out x
将osd设置out出集群后,会引发第一次数据迁移,告诉集群该osd异常了,不要再向它写数据,它的pg也迁出来,分布到其他osd上
等待数据迁移完成。。。耗时三小时
将osd进程stop
将osd进程stop才能进行后续
从crushmap中移除osd
使用ceph osd crush remove osd.x 将osd移除,这不仅使得osd所在节点的权重发生变化,更重要的是,使osd的基数发生了变化,在crush算法计算数据分布的时候,osd基数发生变化是很重要的影响,这会引发第二次数据迁移
等待数据迁移完成。。。耗时三小时
从集群中删除osd
此时该osd仍然在集群中注册,还没有删除干净,使用ceph auth del osd.x
删除osd的认证信息,并使用ceph osd rm x
将osd从集群中删除
重新创建osd
重新创建osd后,osd所在节点权重会再次发生变化,并且,osd数量发生变化导致crush算法的基数发生变化,引发数据第三次迁移
的呆数据迁移完成。。。耗时三小时
以上就是ceph官方推荐的osd删除
的步骤,注意到有三次数据迁移,很心累。实际上,有不少同行会在osd移出集群后,不等待数据平衡完成就立即删除osd,这样会减少一次数据迁移,我们在集群数据量少的时候也这么干过,但是在线上集群没有这么做,会有什么后果,不太清楚-.-
大神推荐做法
上述徐大神和Han的博文提到,应该首先将osd的reweight降为0,从而使得数据迁出,再删除osd,下面直播一下这种方式
首先将osd reweight为0,此命令一出,osd立即自动out出集群
1 | [tanweijie@ceph-2-52 ~]$ sudo ceph osd reweight 0 0 |
此时osd df信息显示该osd的权重和容量信息被清空,只待将pg迁出去
1 | 0 hdd 5.29999 0 0B 0B 0B 0 0 475 |
数据均衡后,集群恢复正常
1 | [tanweijie@ceph-2-52 ~]$ sudo ceph -s |
此时查看osd df信息,发现pg已经全部迁出
1 | 0 hdd 5.29999 0 0B 0B 0B 0 0 0 |
按照大神推荐,此时将osd移出crushmap,发现有pg迁移
1 | [cephfsd@ceph-2-52 ceph-deploy]$ sudo ceph osd crush remove osd.0 |
随后是大规模的数据均衡,等待数据迁移完成后,集群恢复正常
1 | [cephfsd@ceph-2-52 ceph-deploy]$ sudo ceph -s |
此时,继续删除osd的auth和rm osd,均不会发生数据迁移;后续,新建osd重新加入集群,一定会导致数据均衡
综上,即使osd reweight为0,在移出crushmap的时候仍然会发生数据迁移,只是这次迁移的量会比out出集群小一些,但仍然涉及了大量的数据
个中缘由,osd从crushmap删除后,虽然weight为0,从crushmap中删除并不会引起节点权重变化,但是crush算法决定数据写入的时候,除了权重外,更重要的是基于osd的数量作为基数来计算实际的数据分布,因而所有crushmap的osd增减必然会引发数据的均衡
注:上文引述两位大神的文章的创作时间比较早,不排除他们使用的是10.x版本,而本文介绍的destroy方法为12.x版本引入,在此声明版本差异
实测最优的osd重建方法
官方建议的换盘方式是基于destroy来重建osd,下面实战一下这个方法
首先将osd reweight为0,然后将对应的进程停止,此时集群up和out的osd减一(测试集群基于上面的操作),集群开始进行数据均衡,systemctl stop ceph-osd@1.service
,注意到,reweight为0后会立即触发osd的数据迁移
1 | [cephfsd@ceph-2-52 backup]$ sudo ceph -s |
osd仍在集群但out,osd总数数不变,接下来destroy这个osd
1 | [cephfsd@ceph-2-52 backup]$ sudo ceph osd destroy 1 --yes-i-really-mean-it |
此时这个osd.1状态应该为destroyed,接下来zap处理osd磁盘,这里仅在原来的磁盘及分区上重建osd,实际中可能需要更换磁盘
1 | [cephfsd@ceph-2-52 ceph-deploy]$ sudo ceph-volume lvm zap /dev/sdf3 |
这样,这个准备给osd用的磁盘已经准备好了,现在我们重建这个osd,按照官方的说法,我们先prepare这个osd,实际上可以直接用create的方法进行创建
1 | [cephfsd@ceph-2-52 ceph-deploy]$ sudo ceph-volume lvm prepare --osd-id 1 --data /dev/sdf3 --block.wal /dev/sdd1 --block.db /dev/sdd2 |
至此,这个osd就重建完了,但是此时osd还没有in进集群,所以它现在属于自由的osd,即使它有集群的osd id
1 | -2 40.41992 host ceph-2-52 |
这里,首先使用ceph osd reweight 1 0.xxx
将重建后的osd权重设置为重建前的权重,然后start并in这个osd,集群开始进行数据均衡
1 | [cephfsd@ceph-2-52 ceph-deploy]$ sudo ceph -s |
数据迁移完成后,查看osd的信息
1 | 1 hdd 5.29999 0.81580 5.30TiB 291GiB 5.02TiB 5.35 1.03 477 |
至此,osd的重建完成了,整个过程没有将osd移出crushmap,因此没有触发移出时的数据迁移,其实认真想想,我们真的需要将osd移出crushmap吗?磁盘损坏了,我们的目的是更换磁盘,然后数据backfill进来,或者我们需要升级osd,也就是重建一下osd,集群osd数在绝大多数情况下都不会减少,因而我们将osd移出crushmap其实是没有必要的做法
这里对比一下osd.1在重建前pg的分布情况,就可以理解刚才为什么需要在osd in进集群前进行reweight
事实上,osd本身的reweight在集群使用前就应该调整均匀,pg分布不均匀会导致很多问题,reweight均衡后,这个osd df信息非常有必要记录下来,为的是后续重建osd的时候作为reweight的参考,试想一下osd重建之后,reweight为1.000加入到集群,它的reweight为整个集群最大,所以pg数会最多,这就导致本来比较均衡的pg变得不均衡了,这个时候也非常不适合使用reweight命令进行多次调整,因为每次调整都会引发一次pg重分布,这就有够麻烦的了,所以事先知道重建前reweight的值,在in入集群前调整好,osd加入集群后,pg的分布就算不能与原来完全一致,但是仍然能保证pg分布的均衡度
总结
osd重建在实际ceph的运维中还是比较常见的,重建过程的数据恢复随集群数据规模而增加,并且恢复速度还会影响正常的读写业务,所以在操作的时候要非常小心,本文通过基于12.2.8版本做实验,得出了destroy的方式重建osd才是数据迁移次数最低的结论,不当之处欢迎批评指正
参考资料
ADDING/REMOVING OSDS
深入浅出BlueStore的OSD创建与启动
- 本文作者: 奋斗的松鼠
- 本文链接: http://www.strugglesquirrel.com/2018/11/20/luminous-12-2-8重建osd的正确姿势/
- 版权声明: 本博客所有文章除特别声明外,创作版权均为作者个人所有,未经允许禁止转载!