ceph升级总结

2019独角兽企业重金招聘Python工程师标准>>>

介绍

从hammer0.94.9升级到Jewel10.2.9，升级跨度很大，另外老集群的数据量很大（320TB），整个集群升级总时间耗费大约2个半小时的操作时间，数据同步和回填耗费了大约6个小时，集群的可用空间出现短暂的紧张状态，回填过程中有部分磁盘超过警戒容量。

升级过程

1. 停止客户端服务，卸载了rbd的挂载，停止了各种数据备份和监控
2. 依次对所有的mon进行了升级
3. 依次对所有的mds进行了升级
4. 关闭数据回填和同步
5. 依次对所有的osd进行升级
6. 打开数据回填，等待集群恢复
7. 设置require_jewel_osds，并等待集群数据回填完毕
8. 设置sortbitwise
9. 挂载客户端，恢复应用服务和相关的监控

升级准备

1. 配置文件增加的部分

[global]
setuser_match_path = /var/lib/ceph/$type/$cluster-$id
ms_type = async

2. 批量推送所有内核模块和新的repo conf文件
3. 核对所有机器ip
4. 备份所有线上的集群当下配置

遇到的问题

1. 停服时配置文件报错

  {"message":"Object is not valid","details":[{"path":"/","errors":["AppDefinition must either contain one of 'cmd' or 'args', and/or a 'container'."]}]}will stop server-ss-106-1

这个需要更新6 7 8 9四个实例的配置才行

2. 客户端的操作系统版本决定了ceph的版本，过低的操作系统无法升级到高版本的ceph
3. 所有的应用停止之后应该跑一个监控脚本，同步所有的rbd挂载情况，看看有没有没卸载干净的
4. 设置require_jewel_osds会引发大量的数据回填。数据回填量会引发第5个问题
5. “mon.9 store is getting too big! 17003 MB >= 15360 MB”

原因是因为数据迁移，每次map变化mon都会记录，而且不会删除，等待集群健康后才能删除或者压缩
所以不要在数据同步还没有完成的情况下去设置"mon_compact_on_start = true"

6. 每次数据回填快到结束的时候，总是差一点点回填不了，卡住不走了，其中有一个盘快到警戒值了，必须要重新调整权重才行,所以告警中如果出现“ 1 pgs backfill_toofull”，就要格外注意了，必要时要同时调整osd权重才能恢复

转载于:https://my.oschina.net/xueyi28/blog/3017993