OpenStack 如何跨版本升级

Posted 2022-03-04 CSDN云计算

作者 | 孙琦

来源 | 万博智云

OpenStack是中国私有云的事实标准

根据三方统计报告，2020年，中国私有云市场规模达到951.8亿元，同比增长42.1%，私有云在国内IaaS市场占比约45%。私有云提供商有望在云计算市场持续高速发展进程中持续受益。

在中国的私有云企业排名中，以OpenStack为代表的开源技术占比70%，依然占据主流。作为全球部署最广泛的开源云基础设施软件，OpenStack经过10年的发展，在国内已经形成了稳定的以OpenStack为核心的开源云生态体系。尽管在近年来受到了容器等技术的冲击，但是在中国市场中越来越丰富、越来越成熟的用户实践案例表明，OpenStack开源云技术依然保持着足够的活力。然而随着产品版本迭代升级，各企业的私有云平台运营维护，升级改造的压力逐渐增大。

OpenStack为什么升级难？

虽然OpenStack目前已经成为大多数私有云的解决方案，但是做过OpenStack的人都知道，版本升级是OpenStack商业化应用最大的痛。每年两个新版本不说，随着版本升级，老旧的操作系统也不再支持，这样让用户更加不敢轻易的进行升级。虽然后续的OpenStack试图解决这个问题，但是在大多数情况下，商业版本OpenStack为了稳定，往往选择一个较为固定的OpenStack版本，持续进行迭代和优化，这样就带来和社区版本较大的差异，而无法进行升级。

之前看过360公司的一篇《横跨7个版本的OpenStack无感知热升级在360的落地与实践》，洋洋洒洒数千字描述了OpenStack升级的血泪史。对于一家技术实力积累雄厚的互联网公司尚且花费了如此大的代价，对于传统企业客户来说，这几乎就成为了心中永远的痛。在实际项目中，由于无法实现平滑升级，我们往往看到很多客户的环境部署着多套OpenStack不同版本的环境，而每一套都需要配备相应的运维团队，这就造成了客户和云平台厂商两难的尴尬局面。

“不识庐山真面目，只缘身在此山中”，大多数的解决方案专注于OpenStack本身，而今天这篇文章为大家带来一种不同视角的解决方案，从根本上解决OpenStack升级问题，无论你跨多少个版本，都可以完美的解决。

如何破局？

OpenStack升不动或者不敢升本质是云平台上有业务系统运行，所以我们本质上要解决在升级过程中，业务系统连续性的问题，那么最简单的方案就是将业务系统平滑的迁移至新的云平台上，为了防止大家失去耐心读完整篇文章，我先说解决方案：

1. 业务系统迁移过程中不中断：利用主机块级别增量迁移方式（不是OpenStack原生的Live Migration），将主机从原有云平台迁移至新的云平台；

2. 无代理方式：市面上90%以上的迁移方案都是需要在源端安装代理，那么如果用户云主机数量过多，一台台安装代理的成本也实在太高了，对于用户来讲需要一种无代理的方式来实现云平台之间的平滑迁移；

3. 容灾渐进式迁移：按照最小规模部署新版本OpenStack，待主机逐步迁移至新平台后，将闲置计算节点重新加入回新资源池，同时在正式割接前，业务系统可以在新的云平台上统一演练，确保业务可以正常使用，数据完整；

4. 重建管理信息：解决了数据的问题，云平台对应的租户、网络、安全组等资源可以通过导出导入的方式在新的平台上重新构建即可。

如何解决？

HyperMotion是一款基于云原生的迁移产品，基于块级别差量复制实现业务级别热迁移。在我们最初设计产品时，除了注重对云平台云原生能力的利用，还在产品中加入了“软件定义存储控制器”层，这样让HyperMotion不仅仅可以使用自身的数据流能力，还能够轻松使用开放的数据接口，从而实现云环境之间的“数据流转”。另外一方面，HyperMotion是从云端反向设计，不同于传统的灾备产品，更符合云平台管制的需求。

在本场景中，HyperMotion利用OpenStack接口和Ceph RBD接口实现了云主机热迁移问题，从而解决了OpenStack自身版本的困难，基本的原理如下图所示：

首先在旧版本OpenStack上，我们利用云主机构建一台源端同步代理节点，该节点一方面负责调用源端OpenStack API接口，另外一方面负责与Ceph RBD进行通讯，读取块级别差量数据。这种方案下，对于源端的网络有一定的要求，需要源端同步代理节点能够同时访问源端同步代理及Ceph存储网络。

每次同步时，为了不破坏OpenStack自有的管理体系，每一次的快照要从OpenStack层面进行调度，之后再去Ceph层读取数据，这样就不会产生垃圾数据。待数据读出后，通过加密、压缩等手段传输到目标平台。

在目标平台上，我们需要利用云主机资源再建立一台同步代理，用于接收数据。接收的数据并不直接写入Ceph中，而是利用云主机直接写入Cinder的磁盘中，这样做的目的仍然是符合OpenStack管制的需求。

每次写入完成后，利用Cinder快照机制，固化时间点数据，这样我们可以在正式割接前，进行反复的迁移演练，保证业务系统割接后能够正常使用。

最后，在割接窗口期，将最后的增量补全后，利用HyperMotion与OpenStack API的深度对接，按照指定规格同时指定IP地址进行启动，完成割接。

一句话总结一下，通过无代理，渐进式迁移，解决OpenStack版本升级过程中的业务连续性问题，是我们在大量私有云迁移实践中总结的一条行之有效的路径，给大家分享。

往期推荐

从 40% 跌至 4%，“糊”了的 Firefox 还能重回巅峰吗？

Gartner 发布 2022 年汽车行业五大技术趋势

别再用 Redis List 实现消息队列了，Stream 专为队列而生

漫画：什么是“低代码”开发平台？

点分享

点收藏

点点赞

点在看