介绍
从hammer0.94.9升级到Jewel10.2.9,升级跨度很大,另外老集群的数据量很大(320TB),整个集群升级总时间耗费大约2个半小时的操作时间,数据同步和回填耗费了大约6个小时,集群的可用空间出现短暂的紧张状态,回填过程中有部分磁盘超过警戒容量。
升级过程
- 停止客户端服务,卸载了rbd的挂载,停止了各种数据备份和监控
- 依次对所有的mon进行了升级
- 依次对所有的mds进行了升级
- 关闭数据回填和同步
- 依次对所有的osd进行升级
- 打开数据回填,等待集群恢复
- 设置require_jewel_osds,并等待集群数据回填完毕
- 设置sortbitwise
- 挂载客户端,恢复应用服务和相关的监控
升级准备
- 配置文件增加的部分
[global]
setuser_match_path = /var/lib/ceph/$type/$cluster-$id
ms_type = async
- 批量推送所有内核模块和新的repo conf文件
- 核对所有机器ip
- 备份所有线上的集群当下配置
遇到的问题
- 停服时配置文件报错
{"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四个实例的配置才行
- 客户端的操作系统版本决定了ceph的版本,过低的操作系统无法升级到高版本的ceph
- 所有的应用停止之后应该跑一个监控脚本,同步所有的rbd挂载情况,看看有没有没卸载干净的
- 设置require_jewel_osds会引发大量的数据回填。数据回填量会引发第5个问题
- “mon.9 store is getting too big! 17003 MB >= 15360 MB”
原因是因为数据迁移,每次map变化mon都会记录,而且不会删除,等待集群健康后才能删除或者压缩
所以不要在数据同步还没有完成的情况下去设置"mon_compact_on_start = true"
- 每次数据回填快到结束的时候,总是差一点点回填不了,卡住不走了,其中有一个盘快到警戒值了,必须要重新调整权重才行,所以告警中如果出现“ 1 pgs backfill_toofull”,就要格外注意了,必要时要同时调整osd权重才能恢复