技术文章

BLOG

4小时如何完成中大规模满负荷SDS集群升级?

2019-02-12 · XSKY

​​虽然不是第一次为客户实施升级项目,但是面对华东地区某金融客户3套SDS集群共73节点的中大规模升级需求,新入职的XSKY售后Niko还是不免有一些忐忑:

整个集群规模达到1048个OSD,升级过程中有可能存在异常中断、升级后部分OSD无法启动的风险,以及内部小规模升级测试未发现的问题等,都将可能招致整个的项目升级失败。

更令人头大的是,为了不影响业务的正常运行,客户需要在4小时的停机窗口时间内完成全部3套集群的升级,除去升级后集群健康检查时间,真正留给升级的时间仅3小时左右,这对升级方案的成熟度以及现场排障能力都提出了极大挑战。

看出了“菜鸟”Niko的担忧,早已经是轻车熟路的资深售后老李一脸淡定。“放心,万事OK。针对这样的Case我们早有成熟的预案和完备的验证方案,尽量将风险扼杀在摇篮中,并且和客户在升级前、中、后都会有全流程的项目拉通。”

“可是,凡事都有万一,万一还是失败了呢。”Niko望向老李嘟噜着说道。

老李还是一脸的云淡风轻,顿了顿说道:“退一万步说,即使升级失败,我们还有完备的回滚方案,能够保证客户的应用正常运行以及确保数据0丢失。” 听到这,Niko心头疑虑顿消,迅速投入到升级方案制定中……

一、启动升级

实际上,该金融客户早前经过几次扩容,已经部署投入到生产环境的XSKY SDS存储产品节点超过100多个,承载的各种金融应用业务系统上千套。

随着持续的系统扩容,尤其是针对该金融客户当前集群规模较大且OSD数量过多的现状,新版本极大的提升了OSD运行的稳定性;同时通过将SSD缓存的读写Cache比例由静态配置变成运行间动态调整,能够自动适配业务负载,提高了性能;另外还增加了文件存储功能、ROW无损快照技术等新功能。

因此,客户计划利用年前(2018年11月24日凌晨)核心交换机替换的时间窗口,将存储集群版本升级至XSKY目前对外商用的3.2大版本。

客户存储资源规划

此次计划升级的共有3个集群,其中集群1(6个存储节点+6个计算节点)按照计划将率先进行升级,系业务测试环境作为生产环境升级的演练;集群2共有63个存储节点,是本次升级中的“重头戏”,由于集群规模大,升级风险也最大;集群3有4个存储节点。

为了将升级风险降至最低,同时确保升级全过程的顺利进行,XSKY临时组织了由研发、售后、售前等组成的专门的项目升级保障队伍,并经过和客户的密切沟通后,将本次的升级项目分为三个阶段:

阶段一:升级项目的准备阶段(2018年11月15日-2018年11月23日);
阶段二:升级项目的升级阶段(2018年11月23日 20:00-2018年11月24日 6:30);
阶段三:升级项目的后期监控阶段(2018年11月24日 -2018年12月7日 )。
二、升级过程

11月15日,由项目总负责人完善《华东地区某金融客户– 1124 SDS 集群升级部署变更方案》;11月16日,XSKY升级小组和客户讨论方案细节:

  • 由于本次升级,需要在4小时的停机窗口时间内完成3套集群共73个存储节点的升级,时间紧任务重,故针对升级过程中的每一步操作,尤其是每一个命令的执行都进行反复的讨论和验证,并对命令执行消耗的时间进行评估;
  • 与对接的各个部门(包括OpenStack和网络)进行多次升级模拟演练,保证升级过程的顺利,同时确保所有的升级以及回退操作都可以在预定的停机窗口内完成;
  • 11月19日-11月23日,驻场工程师负责完成升级前的各项准备工作,包括信息收集、监控集群状态、准备升级相关脚本和测试版本升级的可行性等。

11月23日 20:10,按照预定计划升级集群1,升级完集群1后发现:

  • 升级工具在使用ansible分发升级包时走的是admin的千兆网络;
  • 分发升级包过程中采用的是串行分发,导致升级中传包时间比预期的多了3分钟。

升级小组立即根据集群1升级时间对集群2升级再次进行时间估算,发现集群2升级节点传包阶段预计要消耗40分钟,超过预估时间20分钟。

由于集群2分配升级时间仅有3小时,在这短短的3小时内,要完成63个存储节点升级包的分发和安装,数据库的更新等操作,同时还要为升级过程中突发问题的处理和回退预留时间,因此传包耗时长的问题将直接导致后面的升级操作很难在停机窗口内完成。

说明:插图与文无关

此时,升级项目小组面临着是否升级的重大抉择,顶着巨大的压力,项目总负责人决定:利用11月23日21:00到11月24日3:00这之间的空档时间,进行脚本的优化,将分发升级包的操作从升级脚本中拆出来;同时另一方面进行升级包的上传工作,提前做好准备工作。

由项目总负责人牵头,研发工程师开始优化升级脚本,经过反复的验证测试、问题排查、模拟多种安装过程,最终在11月24日2:10验证成功。

在11月24日2:46开始在集群2配置优化后的升级脚本并执行升级操作,期间经历了主数据库连接数过多导致升级退出,经过现场和远端工程师的调整优化,终于在11月24日5:45升级成功。

升级完成后,在工程师的保驾护航下,集群2经受住了1500台业务虚机同时开机的巨大挑战,存储监控显示实时读IOPS最大10万,实时读带宽最大2.5GB/S。

虚机全部开机后最终存储读IOPS稳定在1万,读带宽稳定在120MB/S。而集群3在11月23日0:40-11月24日1:40也全部同时完成升级。

为了保证用户业务运行的平稳性和连贯性,升级完成并验收后,XSKY还为该客户提供了为期2个星期的监控期,定期监控集群运行状况并汇总相关信息发送给客户,期间监控显示一切正常,这也标志着升级目标的最终达成。