迁移通常是客户上云之前的最后一道门槛,对于集成商伙伴来说,云已经搭好了,最后上云一步往往难以跨越,这是为什么?
业务系统分散在不同平台,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)。关于这个工具,我们下回分解。