根据三方统计报告，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是从云端反向设计，不同于传统的灾备产品，更符合云平台管制的需求。
在本场景中，HyperMotion利用OpenStack接口和Ceph RBD接口实现了云主机热迁移问题，从而解决了OpenStack自身版本的困难，基本的原理如下图所示：
首先在旧版本OpenStack上，我们利用云主机构建一台源端同步代理节点，该节点一方面负责调用源端OpenStack API接口，另外一方面负责与Ceph RBD进行通讯，读取块级别差量数据。这种方案下，对于源端的网络有一定的要求，需要源端同步代理节点能够同时访问源端同步代理及Ceph存储网络。
每次同步时，为了不破坏OpenStack自有的管理体系，每一次的快照要从OpenStack层面进行调度，之后再去Ceph层读取数据，这样就不会产生垃圾数据。待数据读出后，通过加密、压缩等手段传输到目标平台。
在目标平台上，我们需要利用云主机资源再建立一台同步代理，用于接收数据。接收的数据并不直接写入Ceph中，而是利用云主机直接写入Cinder的磁盘中，这样做的目的仍然是符合OpenStack管制的需求。
每次写入完成后，利用Cinder快照机制，固化时间点数据，这样我们可以在正式割接前，进行反复的迁移演练，保证业务系统割接后能够正常使用。
最后，在割接窗口期，将最后的增量补全后，利用HyperMotion与OpenStack API的深度对接，按照指定规格同时指定IP地址进行启动，完成割接。
一句话总结一下，通过无代理，渐进式迁移，解决OpenStack版本升级过程中的业务连续性问题，是我们在大量私有云迁移实践中总结的一条行之有效的路径，给大家分享。
总结
正如我在《云原生时代云迁移与云容灾的发展趋势》提到，基于云平台为底座的IT系统，数据流转将成为一种常态化需求，而这种灵活的方式也有效防止厂商锁定。
套用一句名人名言，“这世上原本没有路，走的人多了也就成了路”。正因为国内丰富的多云生态，使得我们在跨云平台数据流转上探索出一些新场景，解决了一部分厂商和客户都解决不了的痛点，在这里也欢迎更多的合作伙伴加入到我们的数据生态计划，共享混合云时代带给我们的红利。
孙琦 万博智云 联合创始人/ CTO
万博智云联合创始人/CTO，现任Ceph基金会亚太区大使，Ceph中国社区联合创始人,阿里云MVP、腾讯云TVP。
2011年开始从事云计算开源包括Cloud Foundry、OpenStack、Ceph等项目。2018年成功组织Ceph全球首次峰会，并帮助多家国内知名企业加入Linux Foundation旗下的Ceph基金会。
2016年孙琦先生带领团队研发国内首款全自动云原生迁移/容灾工具，覆盖20+云，并应用于金融，银行，能源，教育，医疗，政务等各行业大型迁移项目中。
Ecological cooperation link
Customer Service