OpenStack 如何跨版本升级

作者 | 孙琦

来源 | 万博智云

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

业务系统迁移过程中不中断：利用主机块级别增量迁移方式（不是OpenStack原生的Live Migration），将主机从原有云平台迁移至新的云平台；
无代理方式：市面上90%以上的迁移方案都是需要在源端安装代理，那么如果用户云主机数量过多，一台台安装代理的成本也实在太高了，对于用户来讲需要一种无代理的方式来实现云平台之间的平滑迁移；
容灾渐进式迁移：按照最小规模部署新版本OpenStack，待主机逐步迁移至新平台后，将闲置计算节点重新加入回新资源池，同时在正式割接前，业务系统可以在新的云平台上统一演练，确保业务可以正常使用，数据完整；
重建管理信息：解决了数据的问题，云平台对应的租户、网络、安全组等资源可以通过导出导入的方式在新的平台上重新构建即可。

如何解决？

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