先迁移,再调研——容灾渐进式迁移最佳实践


迁移通常是客户上云之前的最后一道门槛,对于集成商伙伴来说,云已经搭好了,最后上云一步往往难以跨越,这是为什么?

业务系统分散在不同平台,IT人员缺失,老旧系统无人维护等,碰到这样的甲方客户,集成商往往都很难办,不得不投入大量的现场运维人员做前期调研,甚至请迁移厂商驻场,但这也意味着过程中会消耗大量的人力财力,且周期难以预测。这样巨大的迁移成本,让集成商对于提供云迁移服务望而却步,身边没几个咨询顾问,你都不好意思跟客户打招呼?!

在对业务关联性没有充分调研的情况下,大干快上的迁上云,系统能不能跑,有什么风险?恐怕没有谁敢打包票。但如何解决迁移调研和验证的效率问题?结合我们的产品特点和多年的迁移实践,大胆的提出一个渐进式迁移的思路:先迁移后验证,只需要明确业务系统组成范围和相关责任人,其他复杂业务问题:包括业务关联性、系统变更等,则后置在迁移验证阶段完成,在仿真环境完成。

大量的实践案例证明,这种迁移思路行之有效且效率高,为上云最后一公里扫清了障碍,也让集成商自助实现云迁移的门槛更低,这种迁移思路我们称之为容灾渐进式迁移即充分利用云上虚拟网络隔离的特性,构建近似真实的仿真环境,而不影响正常的业务系统运行。通过构建与真实环境相同的网络地址段(与原有网络隔离,避免造成数据污染),将业务系统按照原有IP地址恢复至该网段内,这样仿真环境就真正的建立好了。业务系统的运维方在仿真环境中进行业务变更验证,并将步骤记录,而业务系统负责人在仿真环境从业务维度进一步验证。这使得我们通过验证过程发现问题完成调研,也让业务方能够安心进行验证后迁移。

当然并不是所有的迁移工具都可以实现“容灾渐进式迁移”,产品与云的亲和程度决定了一切。万博智云的HyperMotion云迁移工具,通过与云原生接口和资源的深度对接,实现了业务系统在云上高度自动化构建“仿真”环境。

之所以可以采用这种“容灾渐进式迁移”,也取决于我们的产品设计框架,万博的HyperMotion云迁移工具,是支持多次增量验证的迁移工具,即使迁移验证失败,也不需要全量数据重新迁移,只需要根据验证情况完善系统信息,再选择迁移增量数据即可。

这里我们演示一下,以HyperMotion实现OpenStack迁移且验证的过程为例:一个OA业务系统,占用1台主机。

1.选择待迁移主机,点击启动主机 


2.系统自动跳出提示框,选择确认无误后点击【确定】


这里演示的是OpenStack平台,除了对接常规的启动主机接口外,我们还深度对接了卷转移(Volume Transfer)接口,这样用户可以使用一个租户进行数据同步,而启动到另外一个租户内。

另外通过对接Cinder Backup接口,实现了Ceph存储的解除链式关系的问题。


在启动主机时,除了常规的规格、网络选项外,还特别针对迁移后不改变IP的问题,增加了指定启动主机IP的功能。

3.系统提示‘开始启动主机’,等待启动主机,系统提示“启动系统完成”。

完成主机迁移后,即可在目标云平台启动OA系统,验证迁移成功情况,而源端系统仍然可以运行。在业务负责人验证迁移成功情况下,再考虑清理源端主机上的信息。

除了采用容灾渐进式迁移模式外,为了将迁移前期调研的工作进一步简化,让集成商伙伴更易上手,我们通过大量实践的总结,形成了标准化的技术调研方案,进而将该方案形成研发需求,开发出调研及分析工具。调研工具的原理非常简单,主要分为三个主要功能:

功能一,通过网络扫描所有存活的主机,通过对nmap的封装,能够对用户局域网内存活的所有主机进行针对性扫描,同时扫描出开放的端口等信息。该步骤作为详细采集前的准备数据。

功能二,基于第一步扫描的结果,由用户业务方提供主机和密码等信息,如果是VMWare,则只需要提供vCenter或ESXi的用户名和密码,程序执行后将自动获取必要的主机详细信息,为进一步分析提供依据。

功能三,基于功能二的详细输出,根据迁移工具的特点进行详细分析,最终得出准确的技术调研报告,其中包含迁移方法及预估的数据同步时间。

通过以上方式,在技术调研部分我们逐步形成了标准化和工具化,而上述调研工具我们也将逐步开源(github.com/hostminer)。关于这个工具,我们下回分解。


本文参考《容灾渐进式云迁移》 作者 老孙正经胡说 发表于云计算部落

老孙,万博智云CTO&联合创始人,阿里云MVP,腾讯云TVP,Ceph中国社区联合创始人之一,Ceph基金会中国区大使。专注于云原生迁移与容灾产品研发工作。


立即体验OnePro产品,开启上云新体验
马上开始
联系客服